Everyone Did a Great Job. What Did the Business Gain?

At one meeting, we were reviewing employee ratings. There were plenty of high scores. The explanations sounded familiar: this person works independently, handles a heavy workload, and solves difficult problems well. Yet we expected much stronger results from the team.

An uncomfortable question came up: if everyone is so good individually, why isn't that translating into team success?

Technology companies can easily fall into this trap. We're good at discussing expertise, complexity, and effort. It's harder to explain what the company actually gained.

Imagine a developer builds something technically excellent. An elegant solution, well-written code, everything works. But it brings the business no benefit.

Can we praise the developer? For the specific engineering work, yes. Call the whole effort a success? That's harder. The quality of the execution doesn't yet prove that we spent our time and money well.

For me, putting the business first starts with that question. Individual results need to be assessed by how they contribute to the shared goal.

In Dropbox's engineering career framework, business impact is the main measure of an engineer's success. That can mean customers using the product, lower costs, reliable infrastructure, or safe data storage.

Of course, there are different ways to explain your contribution. In an old joke, a man keeps hitting the water to scare away crocodiles. Someone tells him there are no crocodiles around. He's pleased: “Then I'm doing a good job of scaring them away.”

The same logic sometimes appears in work reports. We're very busy, and everything still works, so everything we're busy doing must be necessary.

The absence of incidents really can be the result of a great deal of work. But we need to understand which risk we're reducing, what evidence shows that our safeguards work, and why they're worth the cost. Otherwise, useful work becomes indistinguishable from scaring away crocodiles.

In another work conversation, we discussed a familiar situation: someone had sent a request to another team and considered their part done. The request had been sent. The problem remained.

For me, responsibility continues after the message is sent. It means reaching an agreement, finding help, suggesting another approach, or raising the problem in time. Sometimes it means stopping work that no longer makes sense. Doing everything yourself isn't necessary. Caring about the result is.

Imagine two developers. The first finishes their own tasks but leaves a colleague stuck on work needed for the release, even though they could help. The second agrees with the team to postpone some of their own tasks, helps the colleague, and gets the product released. If we assess only individual task lists, the first looks better. That system rewards behaviour that holds the business back.

Contributing to the shared result is part of each person's job. Helping colleagues, reaching agreements, and removing obstacles need to count in the assessment.

That applies just as much to managers.

Managers are responsible for choosing useful work and giving teams the resources and authority to do it. The more authority someone has to set direction and allocate resources, the greater their responsibility for the outcome.

Still, responsibility for the business doesn't mean a poor performance rating for every hypothesis that turns out to be wrong. Otherwise, people would quickly learn to choose only safe tasks.

I can respect strong work on an unsuccessful experiment: the team used resources sensibly, tested an assumption, and stopped in time. It's much harder to accept a situation where nobody even intended to find out whether the work was useful.

I want the conversation to continue after a release. What changed for customers? What did we earn or save? Which risks did we reduce? Should we keep going?

An uncomfortable question remains: “I did good work, but the team fell short. Why should that affect my rating?”

Because we assess both the quality of the work and what it helped achieve. We cannot set the team's failure aside, but we need to examine each person's contribution. Strong work may have reduced losses or helped stop a misguided project in time. A successful team may also have concealed someone's weak contribution. Neither “I did everything assigned to me” nor “we made money” explains an individual's results on its own.

If team results directly affect the overall rating or bonus, people need to know that in advance. Shared success must count just as consistently as failure. At the same time, a lower payout because of team results does not by itself establish a weak individual contribution.

People contribute in different ways, but their work needs to add up to a shared result.

“I've done my part” is too small an ambition for a strong team.