In the previous post, I wrote about innovation and consolidation and the importance of balancing the two. In this post, I write about how Indeed fosters initiative through autonomy.

Most compensation systems reward for business impact

Engineers get better bonuses when their impact on the business is greater. Fair, right? No, it is not. Engineers are not salespeople. There are probably not two of them in your company who are executing the same tasks (and when it happens, they try to write a library or something, because they just can’t help it…).

Rewarding by impact cannot be a fair system, can it?

Rewarding by impact cannot be a fair system if, in reality, individuals are assigned tasks. If you still reward for business impact, you will create and fuel a system where the well-intended will do their work and hope for the best, while the less-so-well-intended can train their skills into political back-stabbing games, trying to grab the juiciest projects, as they already have figured out that is how you have defined they will move up the ladder. Guess who you’ll find at the top in a few years, and what it does to your enterprise culture.

The other option, which Indeed fosters, is to let individuals pick their own tasks. They can’t complain about their project, the product or their boss, because they chose what they wanted to work on. You would think that this does not make sense at all. A company is not a democracy or an entertainment park. If we let people decide their tasks, they’ll pick the easiest or safest, not the most important or most urgent, and most importantly it’s going to be completely disorganized and the product won’t make sense.

Employees in a company, as it turns out, are people with common sense. They can understand that there are times for high-business impact work, and times for washing dishes. They need complex tasks and great challenges, but they also need to rest from them and execute less challenging, yet still productive work. I observed that giving more autonomy does not change much what eventually gets done; but it greatly changes the energy and passion put to the task.

At Indeed, we strive to measure business impact and recognize initiative as key components of the quarterly performance review process. By doing so, we give our engineers the right incentives to balance their work in ways that are best for Indeed’s mission: to help people get jobs.

What’s next?

In the next post in the series, I’ll describe why I think stack ranking is a bad idea.

 IndeedEng Culture: Encourage Autonomy, Measure Impact cross-posted on Medium.

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.