I’ve recently written about the role of Product Managers in technology organizations. In that article, I looked at what PM’s SHOULD do. I’d like to discuss the subject of one personal pet peeve of mine around what many perceive to be a part of the PM’s role: babysitting engineers.
Let’s imagine the following setup: a 10-engineer technology startup. A single product manager, responsible for the roadmap (what will our agile shop produce – and in what order). They also have commitments to the CEO and the board of directors around business timelines – for example, external partnerships lighting up by certain dates. The PM is also a Scrum Master.
Let’s look at an issue: an engineer frequently forgets to report the remaining/completed hours for their work items. There are several possible interpretations of the issue, and thus, several possible solutions. Let’s look at each of them in detail.
Scenario 1: I “just forget”
The engineer is, presumably, simply forgetful. Someone needs to remind them – and that someone is the PM, as they’re the scrum master. The PM essentially then becomes a walking-talking alarm clock – “Did you update your hours?” – “How about you, did you update your hours?..” Why are you paying a HUNDRED GRAND PLUS to a babysitter?
Allow me to doubt the feasibility of this root cause. Does the engineer forget to put their pants on? Usually not. Do they forget to run unit tests before the checkin? No. When was the last time they forgot to check in a file and broke the build? Never really happened. Hmm. I guess they aren’t a very forgetful person, in general…
Scenario 2: I don’t see the value
The engineer simply doesn’t see the value of reporting their hours. They see it as process for the sake of process. The annoying PM keeps printing the stupid report, and there wasn’t a single time when anything useful came out of following this dance yet.
1) Your organization might not need daily stand-ups and up-to-the-day updates on remaining work.
WHAT? DID YOU JUST SAY THAT WE DON’T NEED SCRUM? I’m closing this page right now and unsubscribing from your stupid blog!
Yes, I did say that. Scrum is not a silver bullet. Following the book to the dot will get you nowhere. If your next release is 2-years out, if there are no ambiguity in what you’re building, if you don’t have any budgetary/business/technology interruptions (this does happen!), you can go with a good old waterfall. Or you can change scrum to reduce the amount of daily overhead.
2) Your developer doesn’t have the knowledge that will help them understand the value.
Who uses the roll-up reports? Just the management team, to make prioritization decisions? And you’re wondering why the individual contributor dev has no idea why they should keep updating it? Because they see no value for THEMSELVES. Help connect the dots for them: what you do every day helps us make better business decisions this way and that way, which in turn moves the odds of our business succeeding – and you cashing in on your stock options.
Scenario 3: I don’t give a damn
You’re convinced that the engineer truly understands the value? You talked to them a couple times about it? They still don’t do it?
There’s only one explanation left. They are a lazy ass and don’t give a damn. They simply aren’t hungry – they are coasting along without really caring for success. Get rid of them. They aren’t pulling their weight and are negatively contributing to the morale of others.
In parting, I’d like to once again state – your engineers don’t need babysitting. They need motivation. Treat them like adults, like your partners – and they will pay you back with frenzied dedication and an amazing product.