At some companies, you might overhear this conversation:
“The client asked for an API.”
“Have we considered a data feed instead?”
“The client asked for an API, and the customer is always right, so that's what we have to build."
There’s a pretty good chance that the client then had their own team build an API integration that — once a month — requests each record in a loop, and then dumps it into a monthly Excel report that it uploads to a file share.
Both the client and your own company would have saved time and money if you’d just built a data feed, and the kicker — neither of the conversation’s participants ever know!
How did we get here?
In that more traditional structure, the PM hands a spec to the engineer, and the engineer codes it up. If a project fails, the first thing that happens is that the PM says “you didn’t code X to spec” and the engineer says “you didn’t put Y in the spec.”
That’s not what you want — senior management has to step in often to sort things out, which is wasteful and unpleasant, and it’s a bad culture. Starting a project not knowing who to blame if something goes wrong is asking for trouble. When you do know who to blame from the outset, you rarely have to — and you can move on to more positive things.
That’s why I like to have both engineer and PM explicitly share a single business goal — success or failure is defined by whether or not the software solves the objective. The spec becomes just an intermediate step.
Traditional Engineer’s Goal: “build a machine that matches this drawing.”
Traditional PM’s Goal: “make a drawing that looks good and keep the engineer on schedule.”
New goal for both: “Make a cup of coffee.”
Wait, so then who’s to blame if something goes wrong?
Both of them. If the PM forgot to put “cup” in the spec, the engineer doesn’t get to pour coffee on the user and pass the blame. If the engineer doesn’t have the time, budget, or expertise to build a robot arm that puts the cup under the dispenser, the PM needs to make sure the user knows where to put the cup.
Always both? What about problem employees?
What about them? Don’t keep pairing the same people together if they don’t work well together; that’s Management Negative-101. When there’s one person that can’t work with anyone, it’s obvious.
Unless/until you’re ready to fire the weak engineer, it’s absolutely the PM’s job to make sure they’re not given a feature that’s too complex for them, and to make sure they get additional training.
Unless/until you’re ready to fire the weak PM, it’s absolutely the engineer’s job to triple-check their specs, and guide them in the right direction.
If, between the two of them, they can’t get the project done, they’re both responsible for asking for more resources well in advance of the due date.
Wait, so when does not hiring PMs come in? And engineers? Where’s the code even come from?
It’s kind of clickbait. Sorry, not sorry —
It comes in because this aligning of incentives becomes trivial when the engineer and PM are the same individual.
Something like this segues naturally to people wanting to learn and do both, which I’d absolutely encourage. Maybe you have someone PM on one project and code another. Some of the best PMs I’ve worked with are engineers who need a break from coding; some of the best engineers I’ve hired are PMs who learned how to code.
But filling those roles with separate individuals doesn’t make it terribly difficult to manage. The important factor is the conceptual equivalence. If you want people to be on the same team, it helps to not draw a battle line for them.