All Posts in Organizational Design

|In: Leadership|Last Updated:

We need more sex in the workplace.

In some cases, much more.

Not among co-workers, for heaven’s sake. That’s their business, and if you’re very lucky they won’t make it your business.

No, this column is about sex in its biological sense — as a dramatic accelerator of adaptive evolution.

To understand the significance of sex, compare it to evolution in asexual populations. Imagine the offspring of an asexual creature contains a random, beneficial mutation. If it’s beneficial enough, eventually the population will consist entirely of that organism’s descendants. Then, a member of that future generation might have an offspring that contains another random, beneficial mutation. The process repeats, and with excruciating slowness the population will evolve.

Compare that to sexually reproducing organisms. Two parents give rise to an offspring containing a random, beneficial mutation. More of its offspring survive to reproduce than average, so the beneficial gene spreads.

Meanwhile, in another part of town, another beneficial mutation occurs elsewhere in the population. Among asexual organisms, the two beneficial mutations would compete. But these organisms reproduce sexually, which means two organisms, each having one of the mutations, can mate, giving rise to offspring that have both. The word is recombination. It’s what lets sexual evolution take place at a vastly faster pace.

Now, imagine a business with branch offices — maybe it’s an insurance company with agencies, a retailer with stores across the country, or a manufacturer with a number of local distribution warehouses.

The company could plan all innovations at headquarters. This is neither sexual nor asexual. It’s an attempt at divine creation. As few business leaders are divine, the odds of anything useful happening are limited, proportional to the number of former branch employees working at headquarters.

The company could, instead, encourage each branch office to innovate — to run itself as an independent business. This will encourage innovation, and innovation that fits local circumstances. But if that’s all the company does, it’s asexual. The branch offices will diverge, and because each will have to reinvent each others innovations, progress will be slow. Another disadvantage is that IT gets the miserable job of supporting as many different ways of doing business as there are branch offices.

Add sex. On a regular basis, bring the independently innovating branches together to compare notes and spread the best innovations back among the remaining branches. It’s recombination. But it isn’t as easy to accomplish as it sounds.

Among the barriers: It’s natural for the people in each branch to think their circumstances are unique, allowing them to ignore what the others do. Another: Designing an incentive system that, with the best of intentions, creates a barrier to adoption. If for example, you give a bonus to managers whose innovations are used elsewhere, everyone will focus on selling the benefits of their great ideas while denigrating those of the others.

This misses the point entirely. You want your managers to be the brokers of great ideas, not their originators. Give bonuses to the employees who suggest the successful innovations, and to the managers who adopt and implement as many innovations as possible, wherever they come from.

IT’s role in all of this is difficult. Not as difficult as supporting diverse ways of doing business, but still more difficult than if all innovations are designed at headquarters. You’ll need to create a systems architecture that supports multiple parallel innovation. Version control, change management and regression testing become challenges as well.

One solution: Create an environment that encourages IT innovation through end-user tools that link to the standard core systems. For those that spread sexually (DON’T SAY IT!), institutionalize them by rebuilding them into the core applications using enterprise-grade tools.

This isn’t a solved problem, by the way, which is just one of the aspects to branch innovation that makes it fun.

If you compare the benefits of branch innovation coupled with recombination to any of the alternatives, the advantages are clear: The business gets to try lots of experiments. It finds out which ones work and which ones don’t at modest risk, never betting the whole company.

It’s how nature works, and while evolution did give us the platypus, it has also led to a tremendous panoply of amazingly diverse creatures, each exquisitely adapted to its particular set of circumstances.

It’s a very sexy way to run your business.

Comments

|In: Industry Commentary|Last Updated:

eXtreme programming is a shame.

Understand, there’s a lot to be said for it. I have nothing against it. Smart people have extolled its benefits in print, and in person. It undoubtedly works very well.

But it’s still a shame, because it was carefully packaged to scare the living daylights out of a typical CIO.

When you think of eXtreme programming, what comes to mind first? See? A CIO’s first thought is almost certainly, “Two programmers at one keyboard? There’s no way on earth I can afford to literally cut programmer productivity in half. What’s next on the agenda?”

Or, the CIO will hear the word “extreme” and immediately tune out everything else, because extreme means risk and risk means waiting until other companies make it mainstream.

But doubling up programmers is, while interesting, a nit. Here’s why eXtreme programming, or some other “adaptive methodology,” should be an easy sell:

If you ask business executives what IT does worst, the most common answer is probably project completion. Ask them what IT does best, and you hear about application maintenance and small enhancements — responsibilities most IT organizations address with great competence.

What adaptive methodologies have done is to turn big-bang application development into development by continuous enhancement. They start by building something small that works and adding to it until there’s something big that works. They play, that is, to IT’s greatest strength. That should make sense to even the most curmudgeonly of CIOs.

As with everything else on this planet, the great strength of adaptive methodologies is the cause of their biggest weaknesses, ones they also share with old-fashioned application enhancement.

The first is the risk of accidental architecture. To address this issue, adaptive methodologies rely heavily on “refactoring,” which sounds an awful lot like changing the plumbing after you’ve finished the building.

By beginning with a “functional design” effort that publishes an architectural view of the business as well as the overall technology plan you can reduce the need for refactoring. It’s also important to make sure the development effort starts with the components that constitute a logical architectural hub, as opposed to (for example) taping a list of the functional modules on a wall and throwing a dart at it.

The second risk is colliding requirements. With ongoing enhancements to more stable applications there’s a risk that this month’s enhancement is logically inconsistent with a different enhancement put into production three years ago. With adaptive methodologies, the time frame is closer to three weeks ago but the same potential exists: To a certain extent they replace up-front requirements and specifications with features-as-they-occur-to-someone. It’s efficient, but not a sure route to consistency.

How can you deal with colliding requirements? Once again, take a page from how you handle (or should be handling) system enhancements. In most situations, you’re better off bundling enhancements into scheduled releases than putting them into production one at a time. This gives you a fighting chance of spotting colliding requirements. As a fringe benefit it amortizes the cost of your change control process across a collection of enhancements. (Here’s an off-the-topic tip: If your developers like your change control process you need to improve your change control process. But I digress.)

The same principle applies to adaptive methodologies. As a very smart application development manager explained it to me, “My goal isn’t to have frequent releases. The business couldn’t handle that anyway. What I want is to have frequent releasable builds.”

Yeah, but who cares? As last week’s column argued so persuasively (how’s that for being humble?) most IT shops purchase and integrate, rarely developing internal applications, and integration methodologies aren’t the same as development methodologies. Are there adaptive integration methodologies?

It’s a good question for which the answer is still emerging. Right now, it’s “kinda.” The starting point is so obvious it’s barely worth printing: Implement big packages one module at a time. If the package isn’t organized into modules, buy a competing package that is.

Which leads to the question of which module to implement first. The wrong answer is to implement the module with the biggest business benefit. The right answer is to start with the application’s architectural hub. That will minimize the need to build ad hoc interfaces.

Taking these steps doesn’t make your integration methodology adaptive. The chunks are still too big for that.

But it’s a start.

Comments