Posts Tagged ‘strategy’
I get involved with (sucked into?) strategy quite a lot and one thing that’s become clear to me over the years is that strategy can be as big a job as you want it to be. You need a strategy because you need a decision making framework that will help you prioritize what your resources tackle, choose from proposed options and spot opportunities. Some companies have whole teams dedicated to it, other companies spend vast quantities of time and money on external consultants and offsite sessions but at the most basic level you only really need to know two things; what you [personally] actually do and what your organization really does.
What you actually do
Knowing what you are there to do is perhaps the most commonly ignored aspect of how individuals interpret strategy in a decision making process. The answer might seem very obvious; for example you might say you’re here to manage a team of engineers or project managers or support technicians. I’d tell you that’s just your job, it isn’t why you’re here. Why you’re here might be to grow margin, expand the business, reduce operating costs, launch a series of new product suits etc and of course anyone at any level contributes to those goals in their own unique way. If you know what they are you can start delivering on them but if you’re just “here to manage a team” then you are kind of just living for the moment.
What your company really does
Now we come to what most people traditionally associate with strategy; what your organization does. This is a larger topic but also one of those ‘90% of the benefit is in 10% of the work’ things – you really need to state the obvious first and foremost. “We make widgets” is a nice start but you can give people a lot more focus by talking about who you make widgets for (and who you chose not to), where you’ll sell these widgets and, quite importantly, why. Why is a good one as it let’s you evaluate new opportunities; if a potential plan meets all the same justifications used for a current product [and there is ROI in it] then why not take it forward?
Here’s how you’d reach a practical decision by blending these two perspectives; let’s say why you’re here is to grow margin and what your organization really does is supply price data to city trading floors in the UK. You could easily determine that manufacturing cars is unlikely to meet widespread approval at board level but perhaps extending the supply of price to Chinese traders is where it’s at; or maybe with the same resources you could package your feeds for the consumer market in the UK? Given you supply UK traders because the market is mature and well regulated, the language barrier is low (hey they’re traders so it’s still there!) and you’re capitalized by some common investors then the Chinese option looks like it’s starting with a handicap. Add to this the fact that you’re there to grow the margin – reusing an existing asset is efficient, you could get something to the local consumer market quite quickly, deliver it with the same infrastructure and support it with the same operational staff. Looks like productising for private users is a winner – but what would you have done if you were there to help expand the business into foreign markets? Or de-risk the organizations cash flow by diversifying the product set?
Clearly there are many more inputs to decisions like this but we’re only really talking about the role strategy plays. The above scenario is also predicated on the assumption you’ve determined there was ROI in both options – strategy is about making the choice most relevant to your organization; I don’t think anyone seriously expects you to pursue ideas that never pay back…
You can pursue strategy as relentlessly as you have the time for. The more time you spend on it the more you’re likely to be talking about how you execute your strategy rather than defining the strategy itself – that’s OK though; you need to work that out eventually but as a decision making reference you can never beat knowing what you and your company are really there for. Everyone in an effective organization should know these basics.
Is it next week already? Well I guess I did make a promise so here goes:
The most important thing here is simply to be aware of the position you’re in and make conscious decisions about what you will focus on and what, as a consequence, you won’t. There isn’t really a right and wrong answer to this – a good friend of mine sent me this post by Werner Vogels, Amazon.com’s CTO which I think is one of the best summaries I’ve seen of the various manifestations technical leadership can have.
No matter which quadrant you deliver the best value by focusing on the one thing they all have in common is a degree of technical leadership – the proportion of which and where it sits on the strategy curve differing in each role. Now we’re close to a conclusion; if you’re in a senior engineering role you can’t dodge technical leadership no matter what else you have in your portfolio.
What works for me is setting the technical philosophy – influencing how people think and the approach they take to their work. This affords you a very light-touch management style because you can trust your people to make the same decisions you’d make and you can stay out of individual projects. You’re all working from a common set of core values and you’re constantly exploring the very best ways to implement them in every product. Obviously there are many ways to get these messages across; my current favorite is epic user stories mostly because it’s a familiar format to developers and it contains all the right information – who I am [as the CTO…], the results I’m looking for [I want to look out across a highly secure suite of products…], the key business benefit [so that we earn our customers trust and confidence…] and how I know you’ve done it well [as proven by insert tons of guidance on secure coding, test driven development, penetration testing etc]. Oh and don’t forget repetition. Oh and don’t forget repetition.
That wasn’t so hard; probably would have fitted in a single post – but to be honest some episodic kind of suspense appealed to me…
I didn’t know whether to call this post it’s given title or something more like “the dangers of promotion” because that’s kind of what it’s about. Or perhaps this is just a story about one man’s struggle with time management?
For a lot of years my career was based on my own effort (now it’s based on the efforts of others) and during these early times I encountered a lot of problems, worked smart, then arrived at a lot of solutions. No matter how satisfying that was there were always plenty of times I had to compromise or take a shortcut or be governed by decisions I didn’t quite understand – essentially implementing something less elegant that I had wanted. I uttered those often repeated but seldom achieved words “if I was in charge this would all be different…”
So down the path to management we go – initially it seems to be going well, you get a bit more senior and then you’ve got some technical authority, a bit more senior and you influence the design. And then you hit the beginning of the end – they give you some people – but that’s OK, you’re still doing the architecture right? Then you get a bit more senior and you get another team, then another and before you know it you’re delegating all the things you wanted to control in the first place. You [hopefully] realise that you need to do that for the team to scale but that’s not all; your time is taken up with a whole lot of other responsibilities – suddenly budgets, reports, stakeholders, recruiting, contract negotiations, KPIs, HR and a whole lot of other stuff creeps up. Man, are you busy now. I guess those guys you’ve got should take care of all the technical stuff now. Uh oh.
With all these interesting and challenging new duties it can be easy to forget why we’re here in the first place – engineering – and if I’m not going to set the standards I want for my guys who will? The good news is I think there is a way to influence the quality of your products without having to do all the work yourself and still get all your nice new managerial stuff done – tell you next week.
Recently I struck out across the globe to set up an offshore development center for my company. It was a whirlwind of travel and expense accounts (those who have done this know it isn’t as glamorous as it sounds) but I think I did it well under the benchmark set by our friend Phileas Fogg. Who’d have thought a jumbo jet would be quicker than a hot air balloon? Our [carefully selected] final resting place was Romania and lately a lot of people have been asking me why…
To properly answer this question it is necessary to understand the business problem that called us to action in the first place; delivery bandwidth. Our product people were having to delay (or worse still not do!) good projects with qualified revenue streams because we simply had more ideas than we could deliver – we needed to cost effectively scale our engineering organization to match this appetite.
People often equate ‘cost effective’ with ‘cheap’ but this isn’t really what it means to me – cost effectiveness is a measure of value for money. You need to consider the quality of what’s being delivered compared with the investment you’re putting in and quality was where it was at for us. You see, we have some hard problems to solve in our system:
- over a million users spread around the globe (scale)
- processing more transactions per day than all European stock exchanges combined (TPS)
- serving over 3 billion page requests per week (performance)
- continuous product innovation with tight time-to-market (feature velocity)
- 24x7x365 demand with a 1-second transaction SLA (quality)
We couldn’t meet challenges like these using the tried and tested corporate approach [insert favorite offshore location here] as these high-churn environments don’t tend to foster the kind of creative talent we need or give us the foundation of domain expertise only experience can yield. That said, the old school works extremely well for building good quality commodity software – our problem is we’re anything but off-the-shelf!
Romania provides an excellent pool of talent with favorable economics, it isn’t the cheapest place but it does have the best balance of cost vs quality. Developers (even recent graduates) have a base of solid skill to build on, show ingenuity, potential and a strong desire to learn. They tend to be passionate about technology and unafraid to challenge themselves; not just wanting to deliver systems and functionality but to do so by employing new technology and practices – this last one is particularly important for technology companies as it gives you the edge.
So far our theory is sound and we have some impressive results to look back on but, as they say, watch this space.