In general, a time for generalists

Sometimes the news catches up.
In “Surgery vs injury,” (Keep the Joint Running, 10/13/2008) I warned against the “AIG mistake,” saying, “The bash AIG threw for its top salespeople was a rounding error given its size. The tone choices like this set, though, rationalize a thousand more decisions to be lavish.”
It appears this country’s top automotive executives don’t read KJR, because when they arrived in Washington to ask for money, it was in three separate private jets and without so much as a business plan among them.
When the CEOs can’t even economize to the extent of jet-sharing, their credibility when asking employees to tighten their belts is nonexistent. Their lack of a roadmap to future success sets an even worse tone, because uncertain times are when employees need leadership the most, and leadership starts with a clear direction.
That includes the employees who work for you. If, as CIO, you can’t provide a credible plan for IT you’ll feed their uncertainty instead of dealing with it.
When times call for serious cost-cutting, here are three bedrock principles you can use as the basis for your own plan:
1. Any schmuck can cut costs. Economizing … finding efficiencies that allow the organization to continue delivering as much service as possible while reducing costs … requires excellent management.
2. Don’t try to solve it in big, bold strokes. The best solutions usually come from nibbling away at the problem.
3. If everyone does everything the same old ways, all you’ll be able to do is cut costs — you won’t find any opportunities to economize.
Quite a few weeks back, in a list of possible ways to reduce costs without damaging your ability to deliver the goods, I recommended “de-specializing” — replacing specialists with generalists, or, better, redefining roles more broadly, and providing the support and coaching specialists might need to adapt to their new, generalist responsibilities (“De truth about cutting IT costs,” KJR, 10/20/2008).
Advocating generalists is a lovely generalization (don’t say it). What does it mean in practice?
Theory first. As just about everyone knows, spending comes in two major categories: Fixed (also known as overhead) costs, and marginal (also known as unit or incremental) costs. Fixed costs are what you have to spend to turn on the lights. Marginal costs are the increment required to deliver one more unit of production.
With few exceptions, to reduce unit costs you have to increase overhead and vice versa.
In good times, CIOs want scalability, which means accepting higher overhead so that when volume increases, costs don’t increase in proportion. That’s the point.
But in bad times volume decreases, and costs don’t decrease in proportion. That’s the trade-off.
The best-known example in IT is the trade-off between mainframes and distributed systems. Mainframes cost more and require more data center infrastructure for their care and feeding, but scale very nicely as you add processing load.
Distributed systems are the exact opposite. They don’t scale as well, but the overhead required to implement them is much lower, and if volume drops you can shed costs much more easily.
IT processes and practices work the same way. CIOs who want a highly scalable environment usually rely on high-overhead, structured processes built around specialists who are excellent at narrowly defined spheres of responsibility.
Waterfall software development methodologies are an excellent example. They divide responsibilities into narrow specialties — business analysts, application architects, developers, testers, and trainers, all coordinated by high-end project managers — that pass work from one to the next, assembly-line style to create “software factories, often with some stations located offshore.
Application shops built around waterfall methodologies don’t shed costs easily. With their big project orientation and dependence on multiple specialists, scaling back means eliminating whole projects.
Compare this to the family of iterative and incremental methodologies collectively known as Agile. They rely on generalists — programmer/analysts who might not be quite as good as business analysts are at talking to business users; as application architects are at software engineering; or as developers are at coding — but who are good enough at all three to get the job done without the overhead required for communication and coordination.
In an Agile environment each programmer/analyst is, in effect, an entire self-contained development team, so if need be you can shed capacity one at a time. Right about now, that’s a pretty good description of what most CIOs need to be able to do.
If you run a waterfall shop, now would be a very good time to make the change.