How a company spends its money has an effect on its ability to deliver. That’s obvious, right? What I really mean is that a company needs to consider a change responsiveness strategy before making a decision on how to spend its money. Pause and think for a moment; how much are you willing to spend to change on a dime?
Change is unforgiving
Motorola knew a thing or two about quality and efficiency (see Six Sigma). Not long ago they built the best mobile phones at the lowest prices and were very popular with consumers. However, Motorola underestimated how quickly consumer preferences can change and a once popular mobile phone manufacturer has become the subject in a CIO article about how not to run your business.
Change is a big issue for companies looking to compete and grow locally and globally. If we know as business owners what we’re doing today won’t likely be relevant tomorrow, what can we do? Accenture’s Paul F. Nunes, Samuel Yardley, and Mark Spelman have some answers and wrote an intriguing paper on how growth opportunities in the future will not come from emerging markets, but from capitalizing on changing consumer preferences such as car sharing services, products produced using sustainable methods, and digital everything.
If the world is changing so fast, why are so many still thinking about economies of scale and efficiency rather than effectiveness and adaptability? To be fair, optimizing for economies of scale makes a lot of sense if:
- The business is stable
- Customers don’t change
- Customer preferences don’t change
- You can predict the future.
Okay, yes, there are genuinely stable business examples. If you have a monopoly like a public utility or you have a government contract to buy your goods or services for the foreseeable future you’re probably fine. However, the rest of us need to put in effort to bake in to our businesses flexibility and change responsiveness.
Need an example?
Here’s an obvious example where you would want to consider the probability of change before making a decision: Lets say you just started a new COBOL consulting business and decide to purchase business cards. Your favorite local printer offers a 30% discount if you purchase 100,000 cards up-front. Would you do it? You’re likely thinking that’s a lot of business cards with the same logo, same contact information, same design, and for a service that might not be needed forever. You’re right! A better solution would be to pay more per card for fewer cards and see how your business evolves over time. You may move offices, you may change that black and white design to something with more zing, you might decide .NET is where the need is and distance yourself from ever talking about COBOL, which is now stamped on all of the business cards you printed.
Applied to software development team formation
I see a similar ‘maximize efficiency’ scenario playing out over and over again. Too often managers maximize efficiency by 100% utilizing their software developers. Will 100% efficiency make your team 100% effective? That depends on how you structure your teams. Let me offer another example: You’re building the next version of Microsoft Word, which I’m shamefully using to write this draft in a suburban Starbucks. Word requires a lot of people with a lot of skills working together. You split the teams up based on specialty. It looks like this:
- The”Visual Team” is filled with user experience and visual design experts. They will be building the user interface for the new features customers requested.
- The “Architecture Team” composed of senior software engineers and architects will be upgrading the frameworks and tools your developers use to build Word in a consistent Office 20XX way.
- The “Text Processing Team” is a mix bag of hard-core developers and entry level coders writing the software that makes your word processor function.
What happens when the Architecture Team completes their work ahead of schedule? The Architecture Team will go off and work on the next architecture project and stay 100% efficient building architecture. If their new work is less important than your release, you will be less effective as whole. Keeping a separate architecture backlog was a local optimization that made your architecture team look like rock stars, but didn’t do much for your release.
What can you do differently? Look carefully for false efficiencies. Watch out for economies-of-scale that prevent change responsiveness and focus only on local optimizations. Think of the big picture. Organize your teams to build fully-functioning features instead of dependent components. Yes, this might make individual specialists less efficient and teams harder to staff, but it will improve your ability to respond to change and help you be more effective delivering something your customers are willing to buy.
- Motorola – Requiem for a Heavyweight [Time to Get Agile and Responsive]
- How to stay a step ahead of changing consumer behavior
- Six Sigma