In a previous post, I described the importance of keeping teams independent. Is there a downside to this approach?
One drawback of fostering independent teams is that the product can look inconsistent or even somewhat messy to the end-user. It does not necessarily mean the product or feature will be of poor quality, but it might not be perfect. The fonts will not be the same on all web pages. A credit card that we saved in one section of the website cannot be reused in another section. Keeping teams independent so they can innovate more will generate a consolidation debt.
Consistency is a key component of engineering and user experience quality; but requiring consistency at the earliest stages might be just what kills a good idea. Allowing some consolidation debt can be a necessary evil.
Managing consolidation debt
Consolidation debt is a type of technical debt. Consolidation debt expresses itself as redundancies and inconsistencies across your products. It is why you have three logging libraries and two payment systems. It is also a source of misunderstanding between what the business thinks the company can do, and what the company is really prepared for and can leverage.
Similar to technical debt, business rarely develops without accruing consolidation debt; so there is nothing to worry about. But let it grow too much, and it will attach itself to and hide your product and business, much like the ivy will mask the trunk.
"We have too many of X! Let’s build a single Super-X so all our services can use it!"
You probably have seen this many times. Sometimes it succeeds brilliantly, sometimes it fails miserably, some other times the end result is moderate and not much better than the original situation. Undoubtedly, your teams have gained a little in delegation, but they lost a lot of their autonomy because now, any new feature they want to ship has to involve another team. The team that has resolved its consolidation debt is now worse off. After some time, it will have surrendered all of its innovative power, and you can’t expect it to move the business forward, but only to support it.
A consolidation project has to be a brilliant success, and nothing short of that. The benefit in consolidation has to vastly overcome the sacrifice in autonomy.
Succeeding in a consolidation debt project
Consolidation can fail or be insufficient when in turn, it gets embedded into too many objectives, and the team created to solve the problem is entangled with commitments from day one. Because the company wants to solve this problem, the company forces other teams to adopt the product of the infrastructure team, whether this makes sense or not.
An infrastructure team has to be created in the same spirit of independence as a product team: it has to get its own success metric, conquer its own customers, face honest criticism and competition with the ad-hoc solutions it is trying to replace.
At Indeed, our Engineering Capabilities group focuses on building internal tools and services that reduce redundancy, increase velocity, and maintain quality. We address these problems with the same data- and metrics-driven approaches that we apply when developing our public-facing services.
In the next post, I ask the question: What happens if you let engineers decide what tasks they’ll work on?