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.

Never Tell The Reason

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.

Always Commit For Them

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.

Be Ambiguous And Vague

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.

How to Work With Software Engineers: Deflect Blame

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.

Engineers Are Always Lying

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.

Involve Engineers Late In The Timeline

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.

Don’t Bother With The Details

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.

Interrupt Any Time

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.

How to Work With Software Engineers: Absorbing Praise

The best way to demonstrate your value to the team is by introducing processes. 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.

Adding Processes

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. Strive for the opposite and chances are you’ll succeed as a PM.  <ul><li>Deflect praise</li><li>Absorb blame</li><li>Sweat the details</li><li>Involve them early</li><li>Streamline process</li><li>Always tell the reasons</li><li>Never commit without them</li><li>Respect their time</li><li>Be specific</li><li>Trust them</li></ul>

The Bottomline Of This Satire

Best Practices to Align Stakeholders, Guide Development Teams, and Create Value Together

books

Books

teamwork

Teamwork

product

Product & Design

leadershipandmanagement

Leadership & Management

communication

Communication

Leading in Product Management 

A satirical take at handling a product team.

How can product managers learn to work effectively with engineers? In this tongue-in-cheek essay, Ken Norton tells you how.