The following idea popped into my head after discussions with some colleagues. They bear no responsibility for it. If it’s a bad idea, neither do I.
The problem
It’s hard enough to reach full-throttle agility in a small software company with a single development team. Large organizations make it much harder, because they tend to:
- Require coordinating across teams
- Require convincing more people
- Incentivize counterproductive behavior (albeit unintentionally)
- Organize around components and projects (not products)
- Treat IT as a cost center (not a value provider)
- Specialize in something other than software development
- Control decision-making
Agility can only happen if the team is empowered to make decisions for themselves and their product. Big companies are afraid to unleash that power because they have much longer risk tails and are much fatter lawsuit targets; not only could one wrong move be extremely costly, but also wrong moves are extremely easy to make. Out of justifiable fear, then, big companies tend to prioritize risk reduction over nearly everything else, up to and including the appearance of common sense.
The priorities of a company — particularly the mistakes it wants to avoid — tend to become policies. The priorities of a self-organizing team may not always coincide with company policy. The more policies exist, the more likely a self-organizing team finds itself forced to decide whether to ignore or fight. If they’re lucky, maybe they’ll be granted blanket exceptions for particular policies.
Best-case scenario: given a relatively enlightened large organization, a team can perhaps hope that someday, relatively few of their decisions won’t be theirs to make.
Wait, that’s the best-case scenario?
The idea
If big organizations truly want the benefits of Agile, they need to provide the preconditions for Agile. But they don’t believe they can vest full decision-making power in product teams, because they’re afraid that one sufficiently bad decision could sink the whole company.
What if it couldn’t?
What if we could limit decision-making liability to the teams, so that we could safely delegate decision-making authority to the teams?
Why not spin off every team as its own very small subsidiary company?
The (presumed) benefits
Worst-case scenario: a subsidiary team makes a terrible decision, they lose all their money and/or assets (perhaps as a result of losing a lawsuit), they lay everyone off and close up shop, and whatever’s left maybe rolls up to the parent company, which was never itself at risk.
Best-case scenario: subsidiary teams make their own decisions — who are our customers? who can be on our team? how does our work work? which software licenses can we accept? which security tradeoffs are we comfortable with? etc. — and they’re sensible, effective, and profitable.
In any case, we might expect to see:
- Value-delivering teams turning a profit
- Underperforming teams netting a loss
- Team performance being easier to appraise (and improve)
- Annual budgets being simpler to prepare (and adjust)
The drawbacks
IANAL (I Am Not A Lawyer), and I haven’t tried to search for and study existing corporate structures that may be similar, but I feel certain this can’t be an original idea. AYMIAL (Are You Maybe Is A Lawyer)?
Even if you’re also not a lawyer, do you think this scheme could possibly work? What might prevent it from working? If it could work, what might be suboptimal about it?
One possibility: it’s expensive and risky to restructure a large organization. But for sufficiently large organizations sufficiently averse to risk, restructuring in this way might well be less expensive and risky than doing nothing.
Other possibilities?
The upshot
If this approach to delegating risk through legal means can work, then it promises to remove BigCo-induced accidental complexity, leaving only the essential complexity faced by any self-organizing team.
Perhaps the most effective way to scale Agile up is to scale risk down.
Wholly agreed. BigCo structures and behavioral incentives typically stymie Agile by obfuscating cause-and-effect feedback, BigCo budgets tend to reflect that, and nobody is forced to (or even able to) learn much about how to steer the work as they go. Making teams responsible for their own budgets, in a real and market-driven way, would clarify and tighten these learning loops that make Agile go. After all, that’s how small companies with a single dev team do it.
This seems a reasonable “strangler pattern” for “doing a rewrite” of an old corporation. https://www.martinfowler.com/bliki/StranglerFigApplication.html
Another version is taking a stake in a startup, then if said NewCo does well, buy it and operate it as an arms-length subsidiary with real autonomy. The risk is always tying them to BigCo too tightly.