Sign up FAST! Login

How to Work with Software Engineers in 10 Easy Steps, by Kenneth Norton


I’ve worked in technology for twenty years, the past thirteen as a product manager. I’ve gained somewhat of a reputation for being effective at working with software engineers. This skill has earned me a place in history as one of the three greatest product managers of all time.[1] (On this exclusive list I am joined only by Steve Jobs and Niccolò Machiavelli.)

[Pyramid with YOU at top, YOUR CAREER in middle, ENGINEERS, USERS, ETC. at the bottom]For years I’ve kept my secrets close to the vest. But no longer: today I will share with you myTen-Step Plan for Working With Engineers. Or more to the point: how to make engineers do what you tell them to do.

Why should you listen to me, one of the three greatest product managers of all time? [2] Just consider the numbers. I estimate that I’ve worked with 3,875,000 engineers during my career. Of those men and women, more than 95% have done what I told them to do. That means that precisely 1,000,000 engineers have done what I told them to do [an estimate: PMs don’t have time for math]. That’s a lot of engineers, and a lot of experience you should heed.

https://www.kennethnorton.com/essays/how-to-work-with-software-engineers.html

1. Absorb praise2. Deflect blame3. Don’t bother with the details4. Involve them late5. Add process6. Never tell the reasons7. Commit for them8. Interrupt at any time9. Be ambiguous10. They’re always lying

Stashed in: Engineers!, Google FAIL

To save this post, select a stash from drop-down menu or type in a new one:

Hey Ayori -

Thanks for sharing these unique insights.  It's a good window into the subtler forms of human interaction and communication which may not be part of the typical business school curriculum.  

Very illuminating.

Ken Norton's speech is confusing and his tone is obnoxious.

He's pointing out what NOT to do but our brains aren't wired for negation.

This talk would have been better if it went through what TO do.

Instead that list is saved as a postscript at the end, which undermines his teaching since it's an afterthought.

Sincerity and authenticity are better tools for teaching than sarcasm and snark.

Hmm...I guess I took him to be serious, with a little bit of snark.

LMFAO. Not at the bait-and-switch, but because it gets to the heart of why software engineers don't trust product managers who don't bother to know and learn the details of what they are supposed to. 

The rules speak to the ego first which reacts to the pressures of wanting to climb the ladder in an aggressive environment full of closed door politics. These rules highlight the alienation that will be created in a team environment once you come out from behind "closed doors" with new shady or secretive agreements. Unfortunately there is a sense of bravado that gets respected behind these closed doors. Without that "loud mouth", the nice guy is frequently ignored. These pressures that occur behind closed doors bring out bad behaviors that don't work with teams, but the good manager is able to respond rather than react by doing the opposite of what is frequently exhibited behind closed doors by bringing the conversation in that room out to their team rather than making deals in the room. 

No matter what, it seems that understanding basic human nature is always a good start.

Agnes, that's true.

I expected Ken Norton's talk to be about working with engineers but his rules are so generic they're about working with anyone.

You May Also Like: