Championship

Engineering and product managers often talk about “ownership” of features, when what we want is championship. When we orient ourselves around assignment of tasks, we ship a worse product.

We should want individuals to choose projects that they will champion, i.e., for which they are advocates. This is better for the individual, better for the user, better for the company – and it keeps us managers accountable.

Intrinsic motivation

We do better work when we are intrinsically motivated. In engineering, this means better correctness, better performance, more edge cases discovered and addressed. We incentivise craftsmanship: when the implementer cares, the user gets a better product.

My (decidedly unscientific) heuristic is that championed work ships product that is 2× better than assigned work.

And it makes for happier, more invested developers, who stick around.

Keeping managers accountable

When deciding priorities, we managers are more hand-wavy than we’d like to think. Championship provides an empirical test for our hypotheses.

What if we’ve proposed a project and declared its priority, and yet found no takers? The absence of a champion is an opportunity to debug our beliefs.

• Did our idea just fail its first market test – with a friendly audience, no less?
• Did we fail to persuade? Persuasion is an obligation of leadership.
• Did we commit to other priorities, therefore making this new priority…not?

This all sounds idealistic, I know! What about unglamorous projects like tech debt and compliance? Up next, how it worked on my team at Stack Overflow.