The most difficult thing about being a PM is having a plan that reflects reality. In order to get that you need honesty from your devs. To gain their trust you need to not be a dick. It’s that simple.
Here is a quick guide about how to not be a dick as a PM.
Your planning tool should not be used as efficiency appraisal tool
The problem with date deadlines is that they can be directly connected with whether someone is good at their job. If you tell me that something will be done in 10 days and it’s actually done in 20 days, then I have a measurable way of saying “your efficiency is at 50%”.
The moment you do that, it’s over. Devs will just tell you what you want to hear.
This is what I like about Story Points. It’s a way for me to say “I am a Product Manager, my job is to manage the product and plan things, not to decide whether you are good at your job”. I need to do planning, just tell me in oranges how long it will take you to do something. All I need is
- How many oranges it will take to finish this work item
- How many oranges you can output per block of time.
Essentially, I am obfuscating the precious data that I have about your efficiency. Why? Because the moment devs realise that I can use this data to decide their promotions and raises and what not they will change their input to cover their asses and I will not be able to do my job. When they ask me whether the devs are good my response is “that’s not my job, now fuck off”.
I am here to plan, NOT to ascertain whether you are good at your job. That’s someone else’s problem.
Deadlines are not the dev’s problem
“I don’t care about deadlines, but seriously how long it will take you to do something”. Facepalm.
Okay, from the top: We PMs do care about deadlines. That’s what I am paid to do. However, deadlines are not the dev’s problem. They are my problem.
The moment I am asking you “I need to get this done, by then”, I have fixed both the time and the scope of the question. Some people call that planning, I call it making my problems the devs’ problems. And being a dick.
I consciously don’t tell devs about my deadlines. I just ask them how long it will take to do something. In oranges. Because, I don’t want devs to tell me what I want to hear. I want honesty and a plan that reflects reality. Based on what they tell me, then I will make my plan. Worrying about deadlines it’s not the devs job, it’s my job, so in theory they don’t even need to know about deadlines.
Writing code is not a deterministic task
I write it like that, because the “embrace uncertainty” trope is so overused that it has become a platitude.
Listen up and keep notes: Devs don’t really know how long it will take to do something. If writing code was a deterministic and we knew exactly how long it would take, we would have had state machines to do the job. But we are not there yet, we are stuck with people, so buckle up.
Asking a dev exactly how long it will take something, is a one way ticket to getting bloated estimates. And being a shitty PM. This is why I like Fibonacci estimates. It has embedded in their design that we don’t really know everything. Some things will take longer, others will take shorter. And that’s fine.
If you cannot communicate uncertainty as a PM and manage expectations to the higher ups, then you are a shitty PM. And a dick.
Your fancy methodologies are probably shit
Look at this diagram. Just look at it
What the hell is? I have lost count about the things that I have read about “how to deliver software”. They are all fluffy waste, designed to make people look smart in interviews. Then happy PMs get to their teams after having read the a blog post titled “here is the latest trend in product managing” and bloat them with tons of terminology that no one understands or gives a fuck.
Listen up and keep notes:
“Are you confident that you will get everything right on the first try? If not, take that into account in your planning”
There. Done. That’s all there is to it. Waterfall, lean, agile, scrum , FLOW or whatever the fuck people call their process these days. Just throw it out of the window. And here is a thought: How about you form the process with your team? I usually tell my interviews “if there was a silver bullet to get everything right, I would have been replaced by an AI by now.”. Maybe this will happen one day, maybe it won’t, but for now here we are having to work with other people, so maybe we should take them into account.
You don’t look smart by impressing everyone with words. You look smart when you deliver software. So focus on the things that matter.
Your optimistic plan doesn’t make people work faster
“I am being optimistic in my plans and this will make people work harder”. Yeah, right…, that’s why 90% of the projects finish late. It’s a simple strategy really.
- You tell the higher-ups what they want to hear for 5 months
- When the project eventually gets delayed you only appear to be wrong for 1 day when you report the delay and ask for a new deadline.
- You tell the higher-ups what they want to hear for 5 months
- Repeat…
You can cover you ass with that method. But you will also be a dick. If you think everything will go well, then you don’t need me. I am too expensive for that. Just hire a university student or a floating temp. They will give you the BESTEST news and they will do it with a better smile.
As a PM your job is not to assume the best nor the worse. Is to make a fucking plan that reflects reality. Plans don’t change how people work. It’s the other way around. The fact that I put a nice estimate in writing on a powerpoint doesn’t make it true. That’s how Santa Claus work. And that’s easy which is why Santa Claus doesn’t get paid. But you do, so just get your job done properly.
If there is no mutual trust, then you are a shitty PM
The quintessence of being a good PM is having the trust of your devs and you trusting them. However, you are the one that has to start this cycle of trust. Not the devs. Why?
- A dev’s job is to write good code and there is no need for mutual trust to get this done.
- Mutual trust is needed however, to deliver a good product and guess who’s getting paid to get this done.
Don’t get me wrong, some devs are also dicks. And difficult to work with. I am not saying that lack of trust is always the PMs fault. I am saying that it’s your responsibility to fix it.
So, don’t ask them every day about how things are going. Just trust them. And, yeah, you will have some bad weeks and some shitty milestones. We all had them. Just operate on the basis that no one is getting out of bed every morning to consciously make your life miserable and you will be surprised by the common ground you will find.
Let me be clear: Mutual trust is not translated into a democracy. In democracy we all worry about the same things as citizens and we have an equal voice. Nope, that’s not how dev teams are being run. I will worry about my problems, you will worry about yours and we will trust each other that we will get the job done.
See you next time!