In the old days, before I became a PM, I was a developer. I wrote the code. HTML, CSS Javascript, PHP, the database underneath it all, the whole lot. I’m not leading with this because it’s impressive. I’m leading with it because it changes what you notice.
You know what “just” actually costs
‘Can you just move that button’ sounds like a little thing. It can turn into a whole big thing. Moving a button can mean you’re touching a whole layout, mucking about with breakpoints, totally nuking an A/B test that someone forgot was running, wiping out three lines of carefully crafted CSS that were holding up something completely unrelated by accident. Now, I’m not saying no to moving the button. I’m saying my spidey senses know what saying yes could actually involve.
This matters most of all at the point of quoting a timeline to your client. A PM without those spidey senses hears “just move it” and passes on what seems like an innocent small ask. A PM who’s done the work and whose spidey senses are tingling knows to ask the developer one more question before promising anything – and this isn’t because they don’t trust the team, it’s because they know there’s usually a version of the answer that’s ‘yep, give me five minutes’ and a version that’s ‘yep, but let me check these other three things first’ and your client deserves to know which one they’re getting
You stop translating badly between two room
In the midst of the glamour of PMing there’s a lot of relay – your client says something in a meeting or an email, you pass it on to the dev team, the dev team says something back, you pass that on to your client. Once you’ve done that for long enough without understanding either side and you’ve basically become a slightly lossy fax machine from the 1990’s. With my former dev head on, I know which bits of a request are actually technical constraints and which bits are just habit dressed up as a technical restraint.
The difference between them shows up most obviously in scoping conversations. Your client will say ‘we need this to be flexible.’ A developer can her one of a multitude of different meanings of flexible, each with wildly different estimates of effort. Being able to ask the client the right follow-up question ‘do you mean flexible as in editable by the team or flexible as in it’s going to work differently for different users?’ comes from having lived through building that kind of flexibility yourself, and knowing where the simple and the complex version diverge.
You know when “it’s nearly done” is true
Every developer (including me) has said ‘it’s nearly done’ and meant something different by that than the person who asked them. Sometimes it means an hour. Sometimes it means ‘it exists in my head’. Having been the person saying it, I’ve got a reasonable radar for which one I’m hearing.
The trick is to ask a slightly different question, not ‘is it nearly done?’ but ‘if we needed to ship exactly what exists right now, what would be missing?’. As that question is harder to answer vaguely, you’ll get a much better idea of where things are at.
You respect the work enough to protect it
None of what I’m writing about here is about micromanaging developers, or thinking I could do the job better than they can – I couldn’t, technology’s moved on and I was always, at best, a mediocre developer. It’ about knowing the work is real work, with a real cost in time and effort, so I don’t let a “just” turn into someone’s Friday evening.
That means pushing back before a deadline gets agreed, no after. It’s much easier to have the “this is going to take longer than you think” conversation up front than to explain later why the team’s working the weekend to hit a date that someone made up.
That’s the whole thin really. Not that I can still code and am a developer in disguise. That I know enough about what the “just” could mean, ask better questions, and push back when needed.