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.

What’s next?

In the next post, I ask the question: What happens if you let engineers decide what tasks they’ll work on?

---

 IndeedEng Culture: Balance Innovation and Consolidation cross-posted on Medium.

In the previous post, I described the importance of keeping teams independent. In this post, I talk about how Indeed encourages teams to turn mistakes into learning.

In most organizations, mistakes are never part of the plan. Plans are always designed to succeed. Plans never contain a chapter for “what if we are totally wrong about this or that.” Most of the time, by sheer force of habit; and sometimes, out of someone’s ego.

This idea is so brilliant that it cannot fail. Let’s rally everybody around it and celebrate how awesome it is. If it fails, let’s blame the project owner; it is certainly their fault. Let’s blame the engineers; they were not smart enough to understand the requirements or solve their technical problems. Let’s blame marketing or sales; these people had the product that the competition wanted and they just blew it.

Look back at how many mistakes NASA made before sending someone on the moon. Look at how many rockets SpaceX lost before its first successful return. These organizations succeed not because they don’t make mistakes, but because they have defined a process on how to make them and learn from them.

At Indeed, we turn making mistakes into a process, so that they become learnings.

1. Identify the assumptions. Instead of residing in an echo chamber, discuss your idea with those who think it’s doomed to failure. Do not try to convince each other; it rarely happens. Instead, try to agree on the smallest experiment possible, which will scientifically demonstrate where the truth lies.
2. Use a test framework. Comparing before and after is usually what people do, but it has its flaws: what about external factors? How can we run several experiments at the same time? We use A/B testing for everything we ship (except high priority bugs).
3. Take single steps as much as possible. Change one thing at a time. Avoid having multiple assumptions or variables in the same experiment.
4. Do not blame. The only true mistake is to not have learned anything. When something does not work, draw the conclusions and move on to the next experiment. If you fail fast enough, the mistakes are not personal setbacks for careers.

What’s next?

In the next post, I describe how to manage consolidation debt, a type of technical debt that expresses itself as redundancies and inconsistencies across your products.

---

IndeedEng Culture: Make Better Mistakes cross-posted on Medium.

Editor’s note: Five years ago (see our first post) we launched this blog to talk about the technology we work on every day. Since then, we’ve grown more than ten times and continue to build the software that makes Indeed the #1 job site worldwide. To celebrate, we’re proud to host a week-long series of posts by Indeed Engineering Manager James Dingle. These posts highlight some core aspects of what makes Indeed Engineering a great place to work.

During my year-and-a-half tenure at Indeed, I have discovered a new way to accomplish business goals with software. These principles and elements of Indeed’s culture are quite surprising; if you didn’t see them in action, you might believe any company trying them would be doomed to failure. Quite the opposite is true. While some of these principles are deliberate, some of them happened organically. This series describes my perspective on the principles of our engineering culture at Indeed.

Step One: Keep teams independent

Usually, in large organizations, the company defines a grand vision and then breaks it down into products, stories, features, and tasks. These tasks are transverse, and teams commit to other teams on deliverable dates.

When too many teams depend on each other, hitting dates becomes more important than the actual value delivered. As the deadline approaches, teams start to cut out pieces of their planned work, until the product attractiveness becomes lukewarm, its features unbalanced, and its user experience confusing.

The enterprise culture suffers, too. When teams slip on their due dates, the org can drift to finger-pointing and defensive management. In most software products, these dates are not bound to any external event, but some managers still behave as if the project is date-driven.

Engineering new products means a great deal of uncertainty about the difficulties ahead and how much time it will take to overcome them. Beyond a certain size, adding a buffer to estimates does not guarantee success. This is why smaller, independent teams are so important.

Independent teams (and uncertain dates) may frighten executives who like big milestones on a calendar. They might believe milestones are a source of clarity, motivation, and accountability, internally and externally. They might think that if the product turns into a flow of sand of features, they will not control it. They might think that if there are no dates, people will become lazy, wander eternally and never ship anything. But in reality, employees have multiple reasons to stay realistic.

Independent teams are beneficial for the team and for managers.

For the team, independence ensures:

• less friction
• more identification with the product by contributors, which in turn triggers more motivation and initiative
• most decisions by the team, where context is better understood

For executive management, an independent team:

• is accountable for the true business impact it delivers
• diminishes the risk of a global impact on the company’s strategy if the team fails or is delayed
• can take more risks

What you need to keep teams independent:

1. An efficient deployment pipeline so teams can push or roll back their bits as they please.
2. Goals and metrics only they can move.
3. A test framework to evaluate the impact of new features and experiments.
4. An efficient data collection and analysis pipeline.

Indeed has focused on developing the four abilities above while growing rapidly. Goals come top-down, and innovation rises bottom-up.

What’s next?

In the next post, I’ll explore the importance of making better mistakes.

---

IndeedEng Culture: Keep Teams Independent cross-posted on Medium.