Any programmer worth their salt is willing to help team members out when they’re in a pinch. Software development is a team sport, after all. Unfortunately, management can often completely miss the point and create perverse incentives that wreck a team’s cooperation and communication. If you’re a software manager, here’s a quick self test:

Put together a list of all of your incentives, from compensation increases & promotion to “Who gets the new project”. Make sure to include things like a regular team lunch or a “Employee of the Month”. Now, go through that list and ask yourself the following question for each item:

“If Bob goes over to Alice and says ‘Do you have a minute? I need help with something.’, does this incentive move Alice towards helping Bob?”

Let’s go through some common management antipatterns and what impact they have on Alice’s answer.

The worst of the worst are programs that link cash or other bonuses to individual performance goals. Tying individual performance to comp means that the better financial decision for Alice is to make an excuse and focus on her own work metrics instead. Bob’s unhappy because he’s still blocked. Alice is also unhappy because she has to choose between focusing on her work or falling behind on her performance goals. Do you really think more cash will increase morale enough offset this massive break in teamwork?

On the other hand, some bonus programs reward engineers with bonuses that are dependent on company performance (the biggest team there is!). Alice earns more if the entire company does well, rather than focusing exclusively on Alice’s own objectives. Now Alice’s extrinsic and intrinsic incentives are aligned. She can help Bob, safe in the knowledge that the company wants them both to succeed.

Some companies (like my employer, Netflix) go a step further and do away with bonuses entirely, providing top-of-market pay instead, coupled with explicit trust in the employee to do what’s best for the company in any given situation. Netflix’s expense policy, “Act in Netflix’s best interests”, is the archetypical example.

Promotions can be another sticking point. If there’s an open req for a higher-level position that both Bob and Alice are hoping to get, they’re stuck in the same quandry. Google is infamous for only looking at feature development when making promotion decisions and leaving everything (and everyone) else to the wayside. Unsurprisingly, this means they’re launching another chat app while letting Google Reader die.

It may not be as direct as helping a coworker synchronously. There are many other ways engineers work for the betterment of the team/org/company: writing documentation, providing product feedback, sitting in for UX testing, giving internal talks, and more. One option is to sit down and create individual performance metrics for all of these activities. The better option is to remove perverse incentives and let the team do what they do best: build great products.

(Your interview process is filtering out the brilliant jerks, right?)