7 ms·

A PM's guide to communicate effectively with software engineers

101 points by hydrakai 5y ago

TameAntelope 5y ago
I almost agree with all of this, with the caveat of "leave developers alone". A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. If you're on the development team (and you should be), you should not think of yourself as "bothering" the other members of the team when you need to discuss something with them. Doors should be open, and lost coding productivity gets made up for by making extremely sure the code that does get written is the right code. I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. If you're not on the development team, fine. Leave the development team alone. But a team who doesn't have a person dedicated to figuring out what to work on next (often called the "PM"), is not going to be autonomous, and will suffer as a result.
- ianbutler 5y ago
  > Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are. Heavy disagree, there is deep work that requires working a lone. Anything actually technically complex requires both enormous communication AND execution time. Ive worked in companies with pairing all the time and solo execution. By far solo execution of different parts with communal design and heavy communication produced the best outcomes.
- Clubber 5y ago
  >A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. If I worked at a company where devs were poking me 50% of my day, I'd leave screaming.
  - brimble 5y ago
    > I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. Shit, I have—but if you count only productive hours, it's more like 10-20% are talking :-)
- btown 5y ago
  It's also strange that this is written as if there's no option other than "have a meeting" or "save it until tomorrow." That's what Slack is for! Start a thread, notify the right folks, but also ensure you share context about time urgency e.g. "I'd like to respond to $stakeholder today" or "Can you share thoughts sometime before standup tomorrow?" - and importantly, especially for engineers who might take things literally, make sure you share whether or not any coding action (EDIT: including digging into existing code) is requested as part of that effort. Engineers also appreciate that their opinions are valued. Be a buffer so they don't feel like they're getting the full force of the stakeholder, but package the requests in realtime, and build a rapport so that you'll know if you're over-asking!
- mkl95 5y ago
  > I almost agree with all of this, with the caveat of "leave developers alone". > A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I have been part of several Agile teams, starting as a junior engineer at a small startup, and eventually becoming a tech lead at a wannabe unicorn. There's something common to all those places, and it's that spending a significant amount of time discussing things is just not possible. Spending 50% of your time discussing stuff will put a target on your back. The pressure to deliver moderate to unrealistic amounts of work is always there. In that sense, POs and BAs never leave developers alone. Most of their time is spent making product's kitsch dreams come true.
- DoingIsLearning 5y ago
  > about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. On a first pass, I thought this was a typo. I genuinely cannot think of single scenario where discussion is even close to 50% percent of developer time, bar the exception of on-boarding and mentoring a recent graduate in the first month or so. Do you mean discussion among PMs?
  - TameAntelope 5y ago
    Between discussing what to build next with your PM, discussing how to build the next thing with the experts on your team (architects, UX, devs), collaborating with other devs (pair and mob programming), figuring out how to improve the way you work as a team, not to mention the many other shared decisions a team makes, there's no way to jam all of that into anything less than 50% of your time. Honestly, I'd expect all of that to take up your entire work day, and really to do very little else (except overhead, like filling out timesheets or training), but I understand that people are so used to working alone, it's probably not actually possible to get folks to break those (bad) habits. Software development is done best as a team sport. I just don't see how anyone could do the prioritizations listed out in the Agile Manifesto without talking to one another, a lot: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan [0] Every single one of these promotes communication ("talking to one another") and pushes aside "alone time". There's a reason for that. [0] https://agilemanifesto.org/ https://agilemanifesto.org/
    - kungito 5y ago
      Half my company has this much talky talky time and its horrible for efficiency. I work on internal tooling so requirements are more clear, I spend 2-3 hours a week in meetings and I'm 3x more productive than them. My feeling is the biggest issue for the engineers spending time in meetings is that PMs are very bad at seeing technical challenges in what they are selling so there needs to be a lot of time wasted of more technical people helping them finalize the spec. In Micosoft PMs had a lot more technical background/former programmers so way less dev time was wasted in meetings
- gashmol 5y ago
  50% of the time talking sounds like a nightmare. I don't think you can build anything nontrivial if you get interrupted all the time.
  - TameAntelope 5y ago
    I would argue that the only way to build something meaningful to someone other than you is to talk about it approximately half of the time you work on it.
    - stitched2gethr 5y ago
      I believe many highly successful products would contradict this claim.
    - zeroonetwothree 5y ago
      Well you would be wrong. I’ve built many such things spending far less time discussing them.
- 908B64B197 5y ago
  > I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. As Carl Sagan said, extraordinary claims require extraordinary evidence. Have you attempted this in your organization? And measured tangible results? > Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. I have to be honest here: it depends a lot on the market you are hiring from and the caliber of programmers you employ. Sure, if you offshore or go for “best cost” programmers or bootcamp grads you should probably try pairing them up or at least expect to do quite a lot of handholding. But if you hire real engineers you won’t need to do that. Anyways, if you do try it… good luck keeping them in your org for more than a month!
- sanderjd 5y ago
  Communication is important but 50% seems really high to me. I would feel very hassled and would before long quit a team structured the way you describe here. Diff'rent strokes for diff'rent folks I guess.
beckingz 5y ago
And what should a PM do when their engineers are not effective at shipping?
- Clubber 5y ago
  I really depends on why they're having trouble shipping, so that should be the first task: find out why. The first thing to try most of the time is to create well written tasks that can be completed in less than a couple of days, preferably a day. This is an attempt to solve these issues: - Tasks that are too vague. - Developers that get stuck in the weeds. - Developers that aren't that great. - Identifying where the friction is.
  - cudgy 5y ago
    Good point that it depends. What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks.
    - Clubber 5y ago
      >What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks. >due to project scope and/or lack of resources The product scope will at least be clearer with well written tasks. If it's a scope thing, then it will force the biz to be precise in what they want, lowering the back and forth between dev and the pm and biz. If it's a lack of resource thing, the biz needs to learn to prioritize and come to the realization that they want way more than they have the manpower to produce. Once this becomes evident, it will get bounced to a higher level. >number of developer hours and/or expertise level of developers These are two different things. The first is a resource availability problem and was addressed (see above). The second is a resource ability problem. This is where the smaller tasks come in. "Build a queueing system with grids that sort and search" is a lot bigger than "Create these tables," "Create this grid," "Add sorting," "Add searching." It's the divide and conquer strategy. A lower ability developer might get stuck understanding the task as a whole, but if you break it up into bite sized chunks, they might be able to accomplish each individually, or at least show better progress on some of them. You also have to understand, you might have someone who isn't up to the task for a particular subset of skills (say database design, backend design, or UI design, etc). This will at least show you where your devs have holes in their ability/toolset. You can then decide to train them up, or just put a different developer who has that skillset on that particular task, or replace some of them. Say you have one developer that is good at database modeling and backend and one dev that is good at UI. That's easy. Have the first do the backend / db modeling stuff and the second do the UI stuff. This allows devs to do what they are good at and ship times should improve.
thenerdhead 5y ago
I've generally followed a single piece of advice. "Work the people, then the problem." > Avoid becoming the bottleneck that everything has to go through. The problem with this is that it's inevitable with any talented individual. People will look to you for answers to their questions. To help get things done because you have a track record of doing so. There becomes a point where it doesn't scale and you need to now delegate and empower individuals to find answers on their own or make decisions without always seeking approval. > Your job is not to make managers happy. It is to make the team’s work impact the business. The biggest challenge here is playing the TPM/EM role when your engineering counterparts are not empowered. To make them happy, you have to step on toes and stir the pot sometimes when process is tedious, team dynamics / morale is low, or the respective EM does not run the team how the team wants to run. This is a great article for anyone interested in "leading with influence" and applies to all disciplines, not just PM.
cudgy 5y ago
“Get them involved early” From a project manager viewpoint and to gain “buy-in” from developers, this is the most important goal. Unfortunately, from a developer’s career perspective, attempts to involve them early can be a huge time suck.
- nine_zeros 5y ago
  > from a developer’s career perspective, attempts to involve them early can be a huge time suck. Most developers appreciate bringing them in early. What they don't appreciate is the PM bringing them in early without having done any homework. Such PMs don't earn any developer trust and will never be able to launch things on time.
banana-19 5y ago
I had a TPM that did the opposite of all of these... It was a complete shit-show. Then an even worse thing happened, they turned into an SDM.
websap 5y ago
"Your engineers" => Engineers aren't "yours". As an engineer I've never reported to product and don't ever plan to. Engineering requires hours of careful deliberation between choices when building large and complex systems. Product managers are incentivized to deliver features faster. If you're a PM who actually understands engineering, try to understand the actual operational burden your engineers are facing.
- neosat 5y ago
  >> Product managers are incentivized to deliver features faster. This is a misconception. Product managers are/should be (depending on your organization) incentivized to maximize value. Sometimes it may mean being faster to market to validate a hypothesis, other times it may mean pausing on launches for a month or two to make sure you've built a strong enough foundation to set up for the future. Often, it means balancing of your team's portfolio to take on "execution wins", invest in tech for the future, and explore some big bets. Agree 100% that every PM needs to understand the operational burden the engineering team is facing as well as other blockers in their way, and proactively ensure that they focus on the work with utmost clarity and without unnecessary interruptions.
- joebob42 5y ago
  For whatever reason I read it as sort of affectionate rather than really expressing "ownership." I would have been perfectly happy to be one of this person's engineers.
sophrocyne 5y ago
I've led product teams at early stage and through growth into unicorn valuations. The unfortunate truth is that communication challenges are often not the result of any one single PM. A couple of larger "failure modes" drive bad communication in the broader system: - Executive leadership pushing down poor decisions through Product - The "middle-man" problem. - Product teams who are judged by output vs. outcomes - The "SHIP IT" problem - Hiring Product Managers who got into the position to be "CEO of the product" - The egotistical asshole problem. - Engineers who prioritize clocking-in/clocking-out over building a quality product - The "jaded but I get paid well" problem. Being a PM is an incredibly challenging role, often made more difficult by the environment - If you find yourself in a position where you want to do good work, but are constrained by the above (or similar) issues, fix them. Influence up, take ownership of explaining why the processes aren't delivering the outcomes leadership wants, and find ways to prove a better way to do things. Motivate your team - Help them understand why the work matters, and chart a path for them to do something awesome together. Advocate for better, and help it happen. If your response to that advice is "ugh, yeah right - that'll never happen here", you're either right (and need to leave), or you're the problem PM that is accepting failure as a given. If you want to be great, make sure everyone on the team can do their job well, and that the product team is set up to make a meaningful impact on your customers.
- freedomben 5y ago
  There's one thing I think you left out: A great PM will defend their team from management. When management wants to do things like pivot from X to Y, or focus on Z to the neglect of W, a great PM will point out that engineers are not fungible, and that such things can hinder motivation, increase frustration, and lead to lower output. When management decides to do it anyway, and get frustrated with the team's lack of progress (especially on product W which management expected would magically stay up and stable), a great PM (in a professional way) reminds them of the history and that decisions have consequences. Unfortunately a "great PM" will sooner or later have to choose between doing the right thing for their team or the right thing for their career (management does not like to be told no or blamed for any failure). The great PM usually doesn't climb the management chain, so if you are a software engineer with a great PM, please tell them, it may be the only thanks they get.
awillen 5y ago
As a former PM, I kinda hate posts like this, because they imply that there's a single way to deal with engineers. It turns out, though, that engineers are human beings and thus are each very different! They have unique preferences and desires, and the best way to deal with them (which also happens to be the best way to deal with non-engineers) is to learn about those preferences and respect them. You can see the problem in the fact that two back to back section headings are "Don’t isolate them from the outside world" and "Respect their time". Respecting engineers' time often means leaving them alone to work. This can also be construed as isolating them from the outside world, because it means you're not pulling them into meetings and spending lots of time giving them background. Some engineers really want a lot of context on what they're doing. They'd love to join you in meetings with customers and other stakeholders so they can get a feel for the bigger picture. As a PM, I love this - engineers who get the big picture are incredibly valuable in providing feedback beyond the nitty-gritty. On the other hand, many engineers loathe customer meetings! They want the PM to do the research and provide a clear spec on what needs to be built, so they can focus on the engineering side of things. If you put them into a bunch of meetings so they can get broader context, they will be unhappy because this is not what they want. So yeah - deal with engineers like you'd deal with other people. Respect them, get to know them, and interact with them in a way that enables everyone to get their jobs done in the most efficient, pleasant way possible. I know that doesn't make for much of an article, but I think it's much better advice than what's presented here.
- rramadass 5y ago
  You have hit the Nail right on the Head! >deal with engineers like you'd deal with other people. Respect them, get to know them, and interact with them in a way that enables everyone to get their jobs done in the most efficient, pleasant way possible That is all there is. I always say "People are NOT Resources". Each of them is unique and it is upto you to understand their wants and then craft a plan accordingly. I am coming to the conclusion that a PM's job needs; 1) Read up/Train on a little bit of Behavioural Psychology/Applied Behaviour Analysis/Organizational Politics/Communication Skills so you have an idea of how to read, manage and interact with people. 2) People, Time and Resources(inanimate things) are to be managed separately. The latter two always take second place to the first. 3) Every known process is just a template and thus needs to be customized to the situation at hand. Nothing is written in stone. 4) For every person on your Team create a "Spider Graph" identifying and ranking any measurable traits that you are interested in managing. 5) Delegate and give them their Autonomy for execution but within well understood and agreed upon parameters/deliverables. 6) Don't be a "paper-pusher" but understand the problem domain well so that you can have intelligent conversations with your Engineers. This is the only way to earn their respect and have them listen to you. 7) Practice "brinkmanship" when it comes to defending your Team members.
nine_zeros 5y ago
The worst PMs are those that get something vague into an OKR, then disappear for 6 months and then check in, only to find ways to distance themselves from the delivery of the project. The second worse PMs are those that need 80% of project time to research on button shapes and colors, leaving only 20% of engineering time to do research and building the feature.
deleted 5y ago
[deleted]
sherifmansour 5y ago
A very old, but hopefully more amusing version of this: https://youtu.be/wU-ZgG_B1JE https://youtu.be/wU-ZgG_B1JE

101 points by hydrakai 5y ago

I almost agree with all of this, with the caveat of "leave developers alone". A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. If you're on the development team (and you should be), you should not think of yourself as "bothering" the other members of the team when you need to discuss something with them. Doors should be open, and lost coding productivity gets made up for by making extremely sure the code that does get written is the right code. I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. If you're not on the development team, fine. Leave the development team alone. But a team who doesn't have a person dedicated to figuring out what to work on next (often called the "PM"), is not going to be autonomous, and will suffer as a result.

ianbutler 5y ago
> Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are. Heavy disagree, there is deep work that requires working a lone. Anything actually technically complex requires both enormous communication AND execution time. Ive worked in companies with pairing all the time and solo execution. By far solo execution of different parts with communal design and heavy communication produced the best outcomes.
Clubber 5y ago
>A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. If I worked at a company where devs were poking me 50% of my day, I'd leave screaming.
- brimble 5y ago
  > I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. Shit, I have—but if you count only productive hours, it's more like 10-20% are talking :-)
btown 5y ago
It's also strange that this is written as if there's no option other than "have a meeting" or "save it until tomorrow." That's what Slack is for! Start a thread, notify the right folks, but also ensure you share context about time urgency e.g. "I'd like to respond to $stakeholder today" or "Can you share thoughts sometime before standup tomorrow?" - and importantly, especially for engineers who might take things literally, make sure you share whether or not any coding action (EDIT: including digging into existing code) is requested as part of that effort. Engineers also appreciate that their opinions are valued. Be a buffer so they don't feel like they're getting the full force of the stakeholder, but package the requests in realtime, and build a rapport so that you'll know if you're over-asking!
mkl95 5y ago
> I almost agree with all of this, with the caveat of "leave developers alone". > A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I have been part of several Agile teams, starting as a junior engineer at a small startup, and eventually becoming a tech lead at a wannabe unicorn. There's something common to all those places, and it's that spending a significant amount of time discussing things is just not possible. Spending 50% of your time discussing stuff will put a target on your back. The pressure to deliver moderate to unrealistic amounts of work is always there. In that sense, POs and BAs never leave developers alone. Most of their time is spent making product's kitsch dreams come true.
DoingIsLearning 5y ago
> about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. On a first pass, I thought this was a typo. I genuinely cannot think of single scenario where discussion is even close to 50% percent of developer time, bar the exception of on-boarding and mentoring a recent graduate in the first month or so. Do you mean discussion among PMs?
- TameAntelope 5y ago
  Between discussing what to build next with your PM, discussing how to build the next thing with the experts on your team (architects, UX, devs), collaborating with other devs (pair and mob programming), figuring out how to improve the way you work as a team, not to mention the many other shared decisions a team makes, there's no way to jam all of that into anything less than 50% of your time. Honestly, I'd expect all of that to take up your entire work day, and really to do very little else (except overhead, like filling out timesheets or training), but I understand that people are so used to working alone, it's probably not actually possible to get folks to break those (bad) habits. Software development is done best as a team sport. I just don't see how anyone could do the prioritizations listed out in the Agile Manifesto without talking to one another, a lot: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan [0] Every single one of these promotes communication ("talking to one another") and pushes aside "alone time". There's a reason for that. [0] https://agilemanifesto.org/ https://agilemanifesto.org/
  - kungito 5y ago
    Half my company has this much talky talky time and its horrible for efficiency. I work on internal tooling so requirements are more clear, I spend 2-3 hours a week in meetings and I'm 3x more productive than them. My feeling is the biggest issue for the engineers spending time in meetings is that PMs are very bad at seeing technical challenges in what they are selling so there needs to be a lot of time wasted of more technical people helping them finalize the spec. In Micosoft PMs had a lot more technical background/former programmers so way less dev time was wasted in meetings
gashmol 5y ago
50% of the time talking sounds like a nightmare. I don't think you can build anything nontrivial if you get interrupted all the time.
- TameAntelope 5y ago
  I would argue that the only way to build something meaningful to someone other than you is to talk about it approximately half of the time you work on it.
  - stitched2gethr 5y ago
    I believe many highly successful products would contradict this claim.
  - zeroonetwothree 5y ago
    Well you would be wrong. I’ve built many such things spending far less time discussing them.
908B64B197 5y ago
> I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. As Carl Sagan said, extraordinary claims require extraordinary evidence. Have you attempted this in your organization? And measured tangible results? > Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. I have to be honest here: it depends a lot on the market you are hiring from and the caliber of programmers you employ. Sure, if you offshore or go for “best cost” programmers or bootcamp grads you should probably try pairing them up or at least expect to do quite a lot of handholding. But if you hire real engineers you won’t need to do that. Anyways, if you do try it… good luck keeping them in your org for more than a month!
sanderjd 5y ago
Communication is important but 50% seems really high to me. I would feel very hassled and would before long quit a team structured the way you describe here. Diff'rent strokes for diff'rent folks I guess.

beckingz 5y ago

And what should a PM do when their engineers are not effective at shipping?

Clubber 5y ago
I really depends on why they're having trouble shipping, so that should be the first task: find out why. The first thing to try most of the time is to create well written tasks that can be completed in less than a couple of days, preferably a day. This is an attempt to solve these issues: - Tasks that are too vague. - Developers that get stuck in the weeds. - Developers that aren't that great. - Identifying where the friction is.
- cudgy 5y ago
  Good point that it depends. What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks.
  - Clubber 5y ago
    >What if reason developers aren’t “shipping” is due to project scope and/or lack of resources (e.g. number of developer hours and/or expertise level of developers)? From my experience, this is the most likely issue. Difficult for developers to resolve that by increasing the granularity of tasks. >due to project scope and/or lack of resources The product scope will at least be clearer with well written tasks. If it's a scope thing, then it will force the biz to be precise in what they want, lowering the back and forth between dev and the pm and biz. If it's a lack of resource thing, the biz needs to learn to prioritize and come to the realization that they want way more than they have the manpower to produce. Once this becomes evident, it will get bounced to a higher level. >number of developer hours and/or expertise level of developers These are two different things. The first is a resource availability problem and was addressed (see above). The second is a resource ability problem. This is where the smaller tasks come in. "Build a queueing system with grids that sort and search" is a lot bigger than "Create these tables," "Create this grid," "Add sorting," "Add searching." It's the divide and conquer strategy. A lower ability developer might get stuck understanding the task as a whole, but if you break it up into bite sized chunks, they might be able to accomplish each individually, or at least show better progress on some of them. You also have to understand, you might have someone who isn't up to the task for a particular subset of skills (say database design, backend design, or UI design, etc). This will at least show you where your devs have holes in their ability/toolset. You can then decide to train them up, or just put a different developer who has that skillset on that particular task, or replace some of them. Say you have one developer that is good at database modeling and backend and one dev that is good at UI. That's easy. Have the first do the backend / db modeling stuff and the second do the UI stuff. This allows devs to do what they are good at and ship times should improve.

thenerdhead 5y ago

I've generally followed a single piece of advice. "Work the people, then the problem." > Avoid becoming the bottleneck that everything has to go through. The problem with this is that it's inevitable with any talented individual. People will look to you for answers to their questions. To help get things done because you have a track record of doing so. There becomes a point where it doesn't scale and you need to now delegate and empower individuals to find answers on their own or make decisions without always seeking approval. > Your job is not to make managers happy. It is to make the team’s work impact the business. The biggest challenge here is playing the TPM/EM role when your engineering counterparts are not empowered. To make them happy, you have to step on toes and stir the pot sometimes when process is tedious, team dynamics / morale is low, or the respective EM does not run the team how the team wants to run. This is a great article for anyone interested in "leading with influence" and applies to all disciplines, not just PM.

cudgy 5y ago

“Get them involved early” From a project manager viewpoint and to gain “buy-in” from developers, this is the most important goal. Unfortunately, from a developer’s career perspective, attempts to involve them early can be a huge time suck.

nine_zeros 5y ago
> from a developer’s career perspective, attempts to involve them early can be a huge time suck. Most developers appreciate bringing them in early. What they don't appreciate is the PM bringing them in early without having done any homework. Such PMs don't earn any developer trust and will never be able to launch things on time.

banana-19 5y ago

I had a TPM that did the opposite of all of these... It was a complete shit-show. Then an even worse thing happened, they turned into an SDM.

websap 5y ago

"Your engineers" => Engineers aren't "yours". As an engineer I've never reported to product and don't ever plan to. Engineering requires hours of careful deliberation between choices when building large and complex systems. Product managers are incentivized to deliver features faster. If you're a PM who actually understands engineering, try to understand the actual operational burden your engineers are facing.

neosat 5y ago
>> Product managers are incentivized to deliver features faster. This is a misconception. Product managers are/should be (depending on your organization) incentivized to maximize value. Sometimes it may mean being faster to market to validate a hypothesis, other times it may mean pausing on launches for a month or two to make sure you've built a strong enough foundation to set up for the future. Often, it means balancing of your team's portfolio to take on "execution wins", invest in tech for the future, and explore some big bets. Agree 100% that every PM needs to understand the operational burden the engineering team is facing as well as other blockers in their way, and proactively ensure that they focus on the work with utmost clarity and without unnecessary interruptions.
joebob42 5y ago
For whatever reason I read it as sort of affectionate rather than really expressing "ownership." I would have been perfectly happy to be one of this person's engineers.

sophrocyne 5y ago

I've led product teams at early stage and through growth into unicorn valuations. The unfortunate truth is that communication challenges are often not the result of any one single PM. A couple of larger "failure modes" drive bad communication in the broader system: - Executive leadership pushing down poor decisions through Product - The "middle-man" problem. - Product teams who are judged by output vs. outcomes - The "SHIP IT" problem - Hiring Product Managers who got into the position to be "CEO of the product" - The egotistical asshole problem. - Engineers who prioritize clocking-in/clocking-out over building a quality product - The "jaded but I get paid well" problem. Being a PM is an incredibly challenging role, often made more difficult by the environment - If you find yourself in a position where you want to do good work, but are constrained by the above (or similar) issues, fix them. Influence up, take ownership of explaining why the processes aren't delivering the outcomes leadership wants, and find ways to prove a better way to do things. Motivate your team - Help them understand why the work matters, and chart a path for them to do something awesome together. Advocate for better, and help it happen. If your response to that advice is "ugh, yeah right - that'll never happen here", you're either right (and need to leave), or you're the problem PM that is accepting failure as a given. If you want to be great, make sure everyone on the team can do their job well, and that the product team is set up to make a meaningful impact on your customers.

freedomben 5y ago
There's one thing I think you left out: A great PM will defend their team from management. When management wants to do things like pivot from X to Y, or focus on Z to the neglect of W, a great PM will point out that engineers are not fungible, and that such things can hinder motivation, increase frustration, and lead to lower output. When management decides to do it anyway, and get frustrated with the team's lack of progress (especially on product W which management expected would magically stay up and stable), a great PM (in a professional way) reminds them of the history and that decisions have consequences. Unfortunately a "great PM" will sooner or later have to choose between doing the right thing for their team or the right thing for their career (management does not like to be told no or blamed for any failure). The great PM usually doesn't climb the management chain, so if you are a software engineer with a great PM, please tell them, it may be the only thanks they get.

awillen 5y ago

As a former PM, I kinda hate posts like this, because they imply that there's a single way to deal with engineers. It turns out, though, that engineers are human beings and thus are each very different! They have unique preferences and desires, and the best way to deal with them (which also happens to be the best way to deal with non-engineers) is to learn about those preferences and respect them. You can see the problem in the fact that two back to back section headings are "Don’t isolate them from the outside world" and "Respect their time". Respecting engineers' time often means leaving them alone to work. This can also be construed as isolating them from the outside world, because it means you're not pulling them into meetings and spending lots of time giving them background. Some engineers really want a lot of context on what they're doing. They'd love to join you in meetings with customers and other stakeholders so they can get a feel for the bigger picture. As a PM, I love this - engineers who get the big picture are incredibly valuable in providing feedback beyond the nitty-gritty. On the other hand, many engineers loathe customer meetings! They want the PM to do the research and provide a clear spec on what needs to be built, so they can focus on the engineering side of things. If you put them into a bunch of meetings so they can get broader context, they will be unhappy because this is not what they want. So yeah - deal with engineers like you'd deal with other people. Respect them, get to know them, and interact with them in a way that enables everyone to get their jobs done in the most efficient, pleasant way possible. I know that doesn't make for much of an article, but I think it's much better advice than what's presented here.

rramadass 5y ago
You have hit the Nail right on the Head! >deal with engineers like you'd deal with other people. Respect them, get to know them, and interact with them in a way that enables everyone to get their jobs done in the most efficient, pleasant way possible That is all there is. I always say "People are NOT Resources". Each of them is unique and it is upto you to understand their wants and then craft a plan accordingly. I am coming to the conclusion that a PM's job needs; 1) Read up/Train on a little bit of Behavioural Psychology/Applied Behaviour Analysis/Organizational Politics/Communication Skills so you have an idea of how to read, manage and interact with people. 2) People, Time and Resources(inanimate things) are to be managed separately. The latter two always take second place to the first. 3) Every known process is just a template and thus needs to be customized to the situation at hand. Nothing is written in stone. 4) For every person on your Team create a "Spider Graph" identifying and ranking any measurable traits that you are interested in managing. 5) Delegate and give them their Autonomy for execution but within well understood and agreed upon parameters/deliverables. 6) Don't be a "paper-pusher" but understand the problem domain well so that you can have intelligent conversations with your Engineers. This is the only way to earn their respect and have them listen to you. 7) Practice "brinkmanship" when it comes to defending your Team members.

nine_zeros 5y ago

The worst PMs are those that get something vague into an OKR, then disappear for 6 months and then check in, only to find ways to distance themselves from the delivery of the project. The second worse PMs are those that need 80% of project time to research on button shapes and colors, leaving only 20% of engineering time to do research and building the feature.

deleted 5y ago

[deleted]

sherifmansour 5y ago

A very old, but hopefully more amusing version of this: https://youtu.be/wU-ZgG_B1JE https://youtu.be/wU-ZgG_B1JE