IndeedEng Culture: Don’t Stack Rank

In this post, I stand unabashedly against stack ranking. Evaluate how employees perform, not how they compare. Is this really controversial?

people cogs

If you assign to teams or divisions a fixed budget for bonuses, promotions or stocks, you create de facto a zero-sum game. You need losers to have winners. From that point, you can make lengthy speeches about the importance of being on a team, you will see people nod at you silently, but immediately after your all-hands meeting, they will go on competing with each other.

“But competition is good, right?”

Not when it turns into sabotaging each other’s work, by action or inaction, consciously or not. Teams accomplish much more when they combine their efforts. It won’t happen if peers do not have a genuine interest in helping each other, but have more interest in watching each other fail.

“Everything in the company is budgeted, why not compensation?”

Every budget item has unknowns, including compensation. In a small company, the absolute numbers do not really matter. As the company gets bigger, statistics kick in, and compensation becomes predictable enough without requiring comparing individuals.

“If there is no fixed budget, managers will be too generous.”

After all, it is not their money, so why not give it away. But that would quickly lower the productivity and incentive.  

At Indeed, we don’t stack rank or fit to an expected distribution. We have a process that aligns performance reviews across teams and offices, so the company keeps the same definition of what “good”, “better”, “best”, and “not enough” means. No manager decides alone an individual’s evaluation, and there is no competition between teams. This review process is probably the fairest I have ever seen.

What’s next?

In the next post, I conclude my series on Indeed’s culture with thoughts on the most striking trait of individuals at Indeed.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

IndeedEng Culture: Encourage Autonomy, Measure Impact

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.

measurement icon

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.


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

IndeedEng Culture: Balance Innovation and Consolidation

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.

balancing rocks

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?


Cross-posted on Medium.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone