Don't Blame The Engineer

I was talking to someone at a big company recently, and we talked about their retention problem. The person said something to the effect that "We have so many engineers that you just can't cover everyone. There's too many places to hide!" My reaction was: "Wait a minute, why is it a problem with the individual engineers! In an organization this size, your problem is not the 300 bad eggs hiding in your organization. Your problem is the 300 directors (and up) and VPs you have of whom 50% are corrupting your culture intentionally, and 90% wasn't even aware of what your original culture was because nearly every manager you have was hired from the outside!"

Here's the hard truth about organizations. It's almost never the problem of a few "bad egg" engineers that's the root of your culture problem. I've a number of very bright friends at Yahoo, and they keep telling me that Yahoo still has great people, but you couldn't tell that from the outside: the problem is that at the top, the organization is dysfunctional, and no amount of great engineering can save you when you can't get your act together: even if one engineer somewhere in the organization were to invent the next billion dollar idea, that person wouldn't get heard, and wouldn't get sufficient resources in order to execute and deliver it to the market in order to generate that value.

Yet engineers persist on blaming other engineers for the problem. I'll never forget sitting down with a very senior engineer at Google several years ago discussing G-Drive. "The tech lead wasn't any good. If he was more persistent or more forceful, G-Drive might have launched." My jaw dropped. Knowing what we now know about how G-Drive was originally killed (it's documented in great detail in Steve Levy's book, In The Plex), we now know there was no way any engineer, no matter how forceful or brilliant, could have kept the project from the chopping block no matter what. The kind of people who could have saved that project were the people who were politically savvy enough to have the ear of Larry Page. Most of them were not engineers, they were managers, directors or "executives." I have no idea why the engineers I talk to feel the need to blame the engineers: it could be that just like with family quarrels, it's easy to turn the anger on the people you know well rather than the strangers.

Yes, there are circumstances under which engineers can and should take the blame. If you chose to build an entire website on PHP, or tried to scale a web-site based on Ruby on Rails, you deserve all the derision you get from your engineering peers. But even such screw ups, by and large, do not tank the company. And as long as you don't screw up management big time, you'll get a chance to rectify those errors. And yes, if you're at a 3 person startup and the product sucks because of engineering decisions, then blame the engineer(s) involved. But seriously, at a large company (anything over 200 people), blaming the engineer simply means that the management sucks and won't take responsibility for its mistakes. If you're such an engineer in such a firm, go get yourself a new job. Waiting for management that sucks to admit its made a mistake could take a really long time.

In Startup Engineering Management, I note that peer based systems cannot scale past Dunbar's number. One of the unnoted pernicious side effects, however, is that peer based systems also make it easy for management to shirk the important management tasks: that of choosing new managers as well as promoting the right people.