How to Work With Software Engineers

My ten-step plan for working with engineers

By Ken Norton

5 min read • Nov 23, 2015

MOST POPULAR

Ken Norton

Executive Coaching for Product Leaders with Ken Norton

Get a product-minded executive coach in your corner to unlock your full capacities as a leader

Learn more »

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.)

For years I’ve kept my secrets close to the vest. But no longer: today I will share with you my Ten-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.

1. Absorb praise

As a PM, expect your successes to be recognized. Understand that executives will often attempt to spray accolades across the entire team. You must be vigilant: you are the one who is being celebrated, and you are the one who must take all of the glory. Credit is career currency, and you’re polishing your own LinkedIn profile, not theirs. Step up you ninja star, take the spotlight and bathe in the attention.

Product manager absorbing praise from executive

2. Deflect blame

Occasionally something will go wrong. In software development, the thing that goes wrong is usually software. When software fails, a software developer is to blame. That’s just logical. Make sure to redirect the accusations when they’re aimed at you, and to preemptively sow blame whenever possible. Always remember: there is no “we” in me.

3. Don’t bother with the details

Frivolous little technical details are for the engineers, and you have much better things to be doing. Like ideating. Comprehension only leads to disappointment and fosters a so-called “rational” view of what’s possible. You can’t change the world if you know what’s hard and what’s easy. Avoid minutiae at all costs. Anything you imagine can be done in ten lines of code. It hardly matters which ten.

4. Involve them late

Software engineers write code, that’s what they do. They’re always fretting about how stuff is distracting them from their hacking. So why would you waste their time involving them in a project before it’s ready for coding? You don’t see a bunch of construction workers kicking back in an architect’s office. Bring them in once all of the strategizing and synergizing is done and all that’s left is the programming.

5. Add process

The best way to demonstrate your value to the team is by introducing process. Rules grease the wheels of progress. Look for opportunities to schedule update meetings, daily briefings, and all-day reviews. Keep your engineers productive by requiring them to fill out tracking spreadsheets, status reports, and cross-functional executive update emails. If you don’t do it, nobody will. Get going: those voicemails aren’t going to “touch base” by themselves!

There is no WE in ME

6. Never tell the reasons

Engineers are highly analytical, which means they take a less-sophisticated approach to decision-making that often relies on “supporting data” or “rationales” rather than vision and blue sky thinking. Maintaining an air of mystery when decisions are made will keep them on their toes. They’ll complain regardless, there’s no reason to give them specific things to gripe about.

7. Commit for them

Your job as the product manager is to make assurances on behalf of your team. Leadership means setting the bar high and challenging everyone to teleport over it. Show your ambition by committing to project schedules without consulting your team. Being held accountable to somebody else’s promises builds character and brings out the best in people. Think of JFK. He picked a totally random date to land on the moon and NASA beat it, claiming the planet’s vast mineral reserves for Standard Oil.

8. Interrupt at any time

You’re a busy knowledge worker, and the last thing you need is to wait for an engineer to finish their current task. You need it ASAP (pronounced “AY-sap”). Whatever an engineer is working on is less important than what you need right now. Feel free to interrupt them at any time. Chat windows and phone calls can be effective, but nothing beats the good old shoulder tap for impact. What if they’re working on something you asked them to do an hour ago? No problem! This will serve as a good lesson in prioritization.

9. Be ambiguous

There are few things more dangerous to your career than being proven wrong. Ensure this never happens by aiming to be as vague and imprecise as possible. Feel free to change your mind at will. If you take every position imaginable, by definition you were right. Don’t record anything in writing, or better yet make documents so wordy and tedious nobody will bother reading them.

Pyramid with 'you' at the top and engineers, users at the bottom

10. They’re always lying

Engineers will sometimes say something is “impossible.” They’re lying. Nothing in engineering is impossible if you set your mind to it. The Wright Brothers never thought that flying across the Atlantic was impossible! Assume a software engineer is always deceiving you and act accordingly. So when you hear terms like “technical debt” or “working from home,” you’ll be ready to call their bluff.

There you have it. My Ten-Step Plan for Working With Engineers. Print this out and hang it in your workspace (consider keeping it hidden from view). If you follow my plan, you too can become a great product manager (if not one of the three greatest3. It’s that simple.


Afterword

If it’s not blindingly obvious by now, you should do exactly none of these things. Even the most conscientious PMs are occasionally guilty of less extreme infractions in each of these categories. I certainly am. Strive for the opposite and chances are you’ll succeed as a PM. Or at the very least, you’ll have engineering co-workers who’ll want you to.

  1. Deflect praise
  2. Absorb blame
  3. Sweat the details
  4. Involve them early
  5. Streamline process
  6. Always tell the reasons
  7. Never commit without them
  8. Respect their time
  9. Be specific
  10. Trust them
  11. (And finally…) Always bring the donuts

April 2013

This essay is derived from an ignite talk I gave at How to Build Great Products: Insights on April 12, 2013 in San Francisco. Here are the slides from that talk:

Special thanks to: Anand Rangarajan, Andrew Oplinger, Dylan Salisbury, Jordanna Chord, Joseph Smarr, Mike Carrato, Patrick Doyle, Philip Tucker, and Summer Bundy. They are all engineers. I got them to participate by convincing them my list would be tongue-in-cheek. Yet another example of how I can get engineers to do what I want, and why I am one of the three greatest product managers of all time.

  1.  James Byron, et al., Who’s Who in Product Management: Five Hundred Years of Ideating 1513-2013 (London: A&C Black, 2013), ISBN 4815162342 

  2. Ibid. 

  3. Ibid. 

Originally Published: November 23, 2015

Ken Norton is an executive coach who works with product leaders. He spent more than 14 years at Google where he built products used by more than 3 billion people.

  • MOST POPULAR
  • How to Hire a Product Manager: the Classic Essay

    The classic essay that defined the product manager role

    What is product management? What makes a great product manager, and how do you become one? This is Ken Norton's classic essay on the role of product management that launched thousands of PM careers.

  • 10x Not 10%: Bold Product Strategy and Vision

    Product management by orders of magnitude

    In this ambitious essay, Ken Norton looks at the history of innovation and challenges product managers and product leaders to think bigger, to aim for 10x, not 10%.

  • Please Make Yourself Uncomfortable: Jazz and PMs

    What product managers can learn from jazz musicians

    What can product managers and product leaders learn from jazz, an art form that is all about improvisation, collaboration, and being willing to take risks?

  • Best Books for Product Managers [2024]

    Essential product management reading

    Ken Norton shares his recommended books for product managers. The best books on product leadership, innovation, management, shipping winning products, and design thinking.

  • Building Products at Stripe

    Go deep, move fast, and build multi-decade abstractions

    What is Stripe's product culture like? Interview with a Stripe product leader demonstrate an embrace of going deep, moving fast, and maintaining a multi-decade perspective.

  • It’s Time to Fight for a Dual Product Management Career Path

    Companies should embrace multitrack job ladders for product managers who prefer product leadership to people management

    Companies should embrace multitrack job ladders for product managers who prefer product leadership to people management. A concrete proposal with sample career track is included.

  • Ants & Aliens: Long-Term Product Vision & Strategy

    Why you need a thirty-year product vision (yes, thirty)

    How do you plan for the future and deliver an innovative and compelling product vision that will inspire your team to deliver winning products?

  • Building Products at Airbnb

    Snow White, storytelling, and a relentless focus on experiences

    What is Airbnb's product culture like? Interviews with Airbnb PMs demonstrate an embrace of Snow White, storytelling, and a relentless focus on experiences.