My last two blog entries, and some recent reading (I’ll write about it soon) have given me a lot of food for thought about business strategy and how it relates to software development. Fundamentally strategy is about knowing what you are doing, articulating what you are trying to do and using this understanding to drive what you do.
All companies have a strategy whether they realise it or not. I don’t expect many local shop owners spend their time thinking about strategy but they have one. For them strategy is mostly location, location, location. Open a shop in a good location and you will get trade. OK there is a little bit more to it, does the shop sell newspapers? fruit? ethnic foods? In the abstract these are issues of strategy but I expect each one is considered without the need to use the s-word.
This is what I think off as implicit strategy, these businesses have a strategy but it is not spoken about. This approach works - well it mostly works, provided little else changes they can carry on as it. However most of these business are small, one shop, maybe two. But, the more these business grows the greater the need to make the strategy explicit.
An explicit strategy is one that is stated and articulated. This means it can be shared and communicated. If you are going to expand beyond the ideas on the owner’s head then it is necessary to communicate so everyone can pursue the same aims.
Moving from implicit strategy to explicit strategy allows three things (at least) to happen:
• Strategy can be communicated and therefore shared so more people can be involved in the business
• Strategy can be analysed, therefore problems can be spotted and new opportunities can be found
• Strategy can be used to drive execution; so structures, processes and products can all be built to ensure the strategy is successful.
In other words strategy is about scale, it is about creating the conditions to grow.
Now we can return to software development... where exactly the same process happens occurs.
A programmer can have a great idea for a program, and like the shop owner, they can build it. They can stick it on the net and may even sell a few copies. As success grows they may want to hire more developers, thats where the software requires design, architecture and so on. Its about scaling. Once again it is about sharing the ideas and communicating them. It is about analysing the design, finding problems and creating the support infrastructure.
Just to be clear, I’ve said it before in other words: Software Design is equivalent to business strategy. It is about scaling up.
And as this software is success, and more programmers work on it money generation becomes more important. The first program sold because, like the local shop, it was in the right place at the right time, but to sell more copies, to pay for more programmers, you have to know what you are trying to do.
So the software is no longer just software, it is a business, and like all businesses it needs a strategy. And since this business is growing it needs to move from an implicit strategy to an explicit strategy - for all the reasons above and more. The software industry is highly competitive and international, things are always changing. If you don’t consider the changes, and how you will responded you won’t survive long.
Strategy matters more for software companies than to many others. This is because software, indeed all IT, is about change. You use IT (and therefore software) to create change. Either in your organisation or in your customers. You need to understand what kind of change you are creating, how you are creating it and why you are creating it. Organisations are in greatest need of strategy when change is in the air.
There are actually two strategy tracks in a software company, one embedded in the software design, and one stated as business strategy. The two are interlinked and can hinder each other. You cannot pursue a business strategy that your software architecture will not support, and you cannot expect a software design to work well if it runs against business strategy. We’re back to Conway’s Law but that is not my primary point here.
There are two problems I want to highlight. The first concerns strategy itself.
The trouble with strategy is that it is grand, it sounds grand and as the economist John Kay puts it strategy is a synonym for expensive. Consequently all too often strategy formulation becomes the work of ‘big brains’ in the company, or even outside consultants.
This excludes the bulk of the employees and this itself has two problems. First you miss out on their thinking and thus potentially miss out on new ideas and emergent strategies. Second once you have decided your strategy you need to communicate it. This isn’t trivial. Communicating a strategy means you have to be able to communicate it, then you need to actually communicate it, then you need to re-inforce the message and keep re-inforcing it. This takes time.
The second problem with strategy is that it doesn’t happen. Maybe we continue thinking like a small shop keeper: people keep buying our products so we don’t seen the need to rethink anything we do. Or perhaps we do rethink our strategy but perhaps we fail to communicate it. Perhaps only the ‘big brains’ know or understand the strategy.
And these problems are important when you are developing software. Because product requirements derive from the company strategy. If you don’t have a strategy, or you don’t have an strategy people know about and understand then you stand little chance of understanding what your software products should do.
All companies have a strategy whether they realise it or not. I don’t expect many local shop owners spend their time thinking about strategy but they have one. For them strategy is mostly location, location, location. Open a shop in a good location and you will get trade. OK there is a little bit more to it, does the shop sell newspapers? fruit? ethnic foods? In the abstract these are issues of strategy but I expect each one is considered without the need to use the s-word.
This is what I think off as implicit strategy, these businesses have a strategy but it is not spoken about. This approach works - well it mostly works, provided little else changes they can carry on as it. However most of these business are small, one shop, maybe two. But, the more these business grows the greater the need to make the strategy explicit.
An explicit strategy is one that is stated and articulated. This means it can be shared and communicated. If you are going to expand beyond the ideas on the owner’s head then it is necessary to communicate so everyone can pursue the same aims.
Moving from implicit strategy to explicit strategy allows three things (at least) to happen:
• Strategy can be communicated and therefore shared so more people can be involved in the business
• Strategy can be analysed, therefore problems can be spotted and new opportunities can be found
• Strategy can be used to drive execution; so structures, processes and products can all be built to ensure the strategy is successful.
In other words strategy is about scale, it is about creating the conditions to grow.
Now we can return to software development... where exactly the same process happens occurs.
A programmer can have a great idea for a program, and like the shop owner, they can build it. They can stick it on the net and may even sell a few copies. As success grows they may want to hire more developers, thats where the software requires design, architecture and so on. Its about scaling. Once again it is about sharing the ideas and communicating them. It is about analysing the design, finding problems and creating the support infrastructure.
Just to be clear, I’ve said it before in other words: Software Design is equivalent to business strategy. It is about scaling up.
And as this software is success, and more programmers work on it money generation becomes more important. The first program sold because, like the local shop, it was in the right place at the right time, but to sell more copies, to pay for more programmers, you have to know what you are trying to do.
So the software is no longer just software, it is a business, and like all businesses it needs a strategy. And since this business is growing it needs to move from an implicit strategy to an explicit strategy - for all the reasons above and more. The software industry is highly competitive and international, things are always changing. If you don’t consider the changes, and how you will responded you won’t survive long.
Strategy matters more for software companies than to many others. This is because software, indeed all IT, is about change. You use IT (and therefore software) to create change. Either in your organisation or in your customers. You need to understand what kind of change you are creating, how you are creating it and why you are creating it. Organisations are in greatest need of strategy when change is in the air.
There are actually two strategy tracks in a software company, one embedded in the software design, and one stated as business strategy. The two are interlinked and can hinder each other. You cannot pursue a business strategy that your software architecture will not support, and you cannot expect a software design to work well if it runs against business strategy. We’re back to Conway’s Law but that is not my primary point here.
There are two problems I want to highlight. The first concerns strategy itself.
The trouble with strategy is that it is grand, it sounds grand and as the economist John Kay puts it strategy is a synonym for expensive. Consequently all too often strategy formulation becomes the work of ‘big brains’ in the company, or even outside consultants.
This excludes the bulk of the employees and this itself has two problems. First you miss out on their thinking and thus potentially miss out on new ideas and emergent strategies. Second once you have decided your strategy you need to communicate it. This isn’t trivial. Communicating a strategy means you have to be able to communicate it, then you need to actually communicate it, then you need to re-inforce the message and keep re-inforcing it. This takes time.
The second problem with strategy is that it doesn’t happen. Maybe we continue thinking like a small shop keeper: people keep buying our products so we don’t seen the need to rethink anything we do. Or perhaps we do rethink our strategy but perhaps we fail to communicate it. Perhaps only the ‘big brains’ know or understand the strategy.
And these problems are important when you are developing software. Because product requirements derive from the company strategy. If you don’t have a strategy, or you don’t have an strategy people know about and understand then you stand little chance of understanding what your software products should do.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.