Be The Lorax

I am the Lorax. I speak for the trees.

“The Lorax”, 1971

This was Dr. Seuss’ favorite of his books. If you haven’t come across it, it’s a great fable about a woodland creature who keeps warning an industrialist to stop cutting down all the Truffula trees; but the guy doesn’t listen and proceeds to destroy the ecosystem.

From time to time I feel like the Lorax, but instead of the trees, I speak for the developers, who are every software company’s most precious resource1. And I think this is a crucial, but often overlooked part of the software manager’s job: litigation.

At times the plaintiff, other times the defendant, but usually in opposition to someone named Taylor from another department, like finance or HR, who doesn’t understand engineers. Sometimes Leslie is someone very high up, who used to be an engineer a lifetime ago, but they’ve forgotten what it’s like, now that their days are filled with meetings about sales projections and synergy. And here you come, Sr. Cat Herder, with a request to change the new dress code policy.

“You might not have heard, but we had a bit of a problem in Marketing, so we had to institute the dress code. We didn’t want to, but you know Legal.”

You see, Taylor’s not a villain. Almost nobody is. They’re just trying to do their best, and one thing people outside of Engineering are pretty bad at doing is putting themselves in an engineer’s shoes. It would be easier for most people to pretend they were a parakeet. But this is where you come in — you who have knowledge of the way of life in the dark cave of Engineering.

So you use your nerdy charm and wit to show that having a policy is fine, but that it just needs to be tweaked, because while the developers have no intention of causing problems, roughly half of them will quit before dressing “professionally” at work. And a third of those, have not worn long pants or closed toed shoes in years — and won’t start now. Not when they can get a good job by just whispering the words “I’m looking for a change” into the ether that’s continuously monitored by eager recruiters. Because as it turns out, those developers are a lot of the best ones we have, and they’re past putting up with well-intentioned policies. And if even one of them leaves, it’ll cost us a ton in recruiting, on-boarding, shipping delay, and general business risk, which is surely worth tweaking the policy to allow cargo shorts and sandals.

“But it’s 45°F outside!”, Taylor exclaims.
“It doesn’t matter, because they’re almost never outside,” you whisper, “and they’re really stubborn.”

If you do this well, the policy will get tweaked before the developers are even told what was in the policy email they deleted, and the builds go on without a blip.

Sometimes you have to be the change you want to see in the company, which is a bit harder. Convincing the powers that be to allow flexible hours, or to get Engineering more expensive laptops, or that the savings were not worth switching to Microsoft Teams — these are the kinds of things that might need a Powerpoint. A beautiful, well-researched, entertaining Powerpoint, which will take a lot of your precious little coding time.

But these are the things you have to do as a good manager and the sacrifices you have to make, because you are the Lorax, and you speak for the devs. Though… hopefully better than the Lorax, in that you actually succeed in preventing the collapse of the ecosystem.

Footnote

  1. Just to be clear: I was using “resource” metaphorically. As much as nature abhors a vacuum, I abhor calling people resources. Trees and laptops and StackOverflow articles are resources — people are not.

Bonuses Don’t Motivate Developers

First, let me reassure you that they don’t: 50 years of research have shown us that if anything, incentives demotivate employees. And not just developers, but any job that requires some thought beyond mechanistic, rote work like the assembly line.

This is succinctly explained in the most popular RSA Animate video so far (you can watch it below) — a speech given by Dan Pink, who literally wrote the book on motivation. In it, he explains how an experiment funded by the Federal Reserve and conducted by MIT, Carnegie Mellon and the University of Chicago showed that bonuses led to poorer performance for any tasks that required anything above “rudimentary cognitive skill”.

Increasing the bonuses didn’t just not do anything, it actually made people perform worse, and it held true for populations both in the US and in rural India. But this hugely valuable research is mostly ignored, despite being basically ancient by now:

  • Herbert Mayer wrote in a 1975 paper that

    “…  merit pay emphasizes the direct relationship between job performance and dollar rewards, thereby detracting from intrinsic motivation in the work itself. A system that would switch the emphasis to rewards for self-development and opportunities for greater responsibility would seem to serve both individual and organizational goals in a more effective manner.”

  • Alfie Kohn, author of another book on motivation, wrote in a Harvard Business Review article in 1993:

    “As for productivity, at least two dozen studies over the last three decades have conclusively shown that people who expect to receive a reward for completing a task or for doing that task successfully simply do not perform as well as those who expect no reward at all. “

  • Joel Spolsky, after quoting the above, wrote in 2000:

    “… any kind of workplace competition, any scheme of rewards and punishments, and even the old fashion trick of ‘catching people doing something right and rewarding them,’ all do more harm than good. Giving somebody positive reinforcement (such as stupid company ceremonies where people get plaques) implies that they only did it for the lucite plaque; it implies that they are not independent enough to work unless they are going to get a cookie; and it’s insulting and demeaning.”

  • Joel again, in 2006, writing about what he calls the “Econ 101 Management Method“:

    “But when you offer people money to do things that they wanted to do, anyway, they suffer from something called the Overjustification Effect. “I must be writing bug-free code because I like the money I get for it,” they think, and the extrinsic motivation displaces the intrinsic motivation. Since extrinsic motivation is a much weaker effect, the net result is that you’ve actually reduced their desire to do a good job. When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care about bug free code.”

So the rule is that money does not motivate, with two caveats:

  1. Rote, mechanistic tasks: more money works beautifully in that specific case. Which is why we have bonuses at all, because it worked so well in the factories where Henry Ford pioneered the concept of paying workers a better wage for better performance.
  2. Too little money: if workers think they’re not being paid fairly, it becomes a sticking point and all they think about is how they’re being screwed, which obviously prevents them from performing at their full potential.

Joel had another article in 2006, called “Identity Management Method“, in which he described how to create intrinsic motivation:

“To be an Identity Method manager, you have to summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.”

Fast forward to Dan Pink’s 2009 book and 2010 RSA Animate, and he continues the same idea, breaking it down into three factors that do increase performance:

  1. Autonomy: as a manager, giving your employees autonomy is the best way to get them engaged in the work. He mentions Atlassian’s ShipIt Days as an example of how autonomy leads to great things, and should’ve mentioned Google’s 20% time as well.
  2. Mastery: “the urge to get better at stuff”. This is a big reason why the open source movement exists.
  3. Purpose: an important reason to do what you’re doing. The open source movement ties in here, and also crowd sourced efforts like Wikipedia, but increasingly, companies: Apple, Google, Facebook all have self-invented lofty purposes for their existence, and this inspires their employees.

Bonuses are related to none of those. The only reason to ever dangle bonuses in front of developers, is maybe as compensation for the rare big push requiring lots of overtime; and in that case, it’s just to prevent them from feeling exploited. Otherwise, bonuses will actually hurt productivity. And that’s a scientific fact. To get better performance out of your employees, hire smart people and let them be smart. Tell them the company story and why the job is important, then simply get out of the way and help them when they need it.