One of the things I learnt from the "Thinking in Systems: A Primer" book by Donella Meadows is a thing called suboptimization. I choose to call this an anti-pattern as it's a behavior you can frequently observe in systems, and one I think more people should be aware of.
So what is suboptimization? The book states the following while discussing hierarchies: "When a subsystem's goals dominate at the expense of the total system's goal, the resulting behavior is called suboptimization." Does this sound familiar to you?
One example that many developers might be able to relate to is the concept of team velocity. While measuring team velocity might sound like a good idea in theory, in practice, it unfortunately often has unintended consequences (turns out organizations are complex systems!)
What will often happen is that velocity ends up being a measurement for productivity. So every team is interested in maximizing their velocity. Well, what happens if another team needs some help to finish their important tasks? Well, unfortunately, that will reduce your team's velocity, so this turns out to be against your own interest. So the other team might have to wait for you to finish your existing work before you can help them, even if their work was way more valuable for the company as a whole. So trying to optimize the local team ended up hurting the company as a whole.
However, you will probably find this anti-pattern manifest itself other places in your organization, and even in the society around you!
However, that is not to say we don't need hierarchies. There's a very good reason why hierarchies emerge everywhere. You are more closely connected to your friends and family than to your co-workers and community than to the rest of society. You are more closely connected to your team than to your department than to the rest of your organization. The cells in your liver are more closely connected to other cells in your liver than the cells in your heart. There's a limit to how many people we can relate to and how much information we can process. We need hierarchies to be able to deal with the complex structures we interact with every single day.
So if hierarchy is good, but suboptimization is bad, what do we do? We need to find ways to facilitate hierarchical structures where we get the benefits we want and reduce the negative impact it has. It's also important to realise the benefits you want might not be the same as what other organizations wants, and you should really consider what you wish to achieve.
This makes it hard to create universal rules for how to reduce suboptimization. I do have some good heuristics I believe you should keep in mind though:
- Make people aware of the whole. People might not even be aware of the fact that there are things more valuable for the organization than what they are doing now. Make people feel like they belong to the whole, not their separate part.
- Try to focus on actual business outcomes instead of effort. Often the total business outcome will include several teams, and it will be easier for them to cooperate when their goals align, and they all see their role in it. While I have never tried it myself, I see many people sharing good experiences using OKRs
- Build a generative culture where the focus is on learning, building trust and helping eachother. This will lead to people naturally being more willing to work together. It will also reduce people trying to seek personal glory over helping the community.
- Be careful with providing monetary rewards like bonuses or overtime, especially for local outcomes. This can quickly have more unintended consequences (often called perverse incentives, this might warrant it's own post).
- Regularly reflect over how your hierarchy is organized and if it's currently the best way to structure it. Allow some way for your hierarchy to organically change, as it's likely the optimal way for it to organize will change over time. Letting the hierarchy emerge instead of trying to design it top-down is often the best way to make sure the hierarchy fits the ecosystem.