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.

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.

That applies just as much to managers.

Managers are responsible for choosing useful work and giving teams the resources and authority to do it.

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?

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.