[HN Gopher] A PM's guide to communicate effectively with softwar...
___________________________________________________________________
A PM's guide to communicate effectively with software engineers
Author : hydrakai
Score : 55 points
Date : 2022-02-21 20:42 UTC (2 hours ago)
(HTM) web link (www.mindtheproduct.com)
(TXT) w3m dump (www.mindtheproduct.com)
| websap wrote:
| "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 wrote:
| >> 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.
| sophrocyne wrote:
| 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.
| TameAntelope wrote:
| 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.
| mkl95 wrote:
| > 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 wrote:
| > 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 wrote:
| 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/
| kungito wrote:
| 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
| TameAntelope wrote:
| I can imagine the time may seem wasted to a developer if
| your focus is on personal productivity (which seems to be
| the case since you cite your productivity rather than
| your team's productivity), but the lost value is in
| making sure what you're building is aligned with what
| your customers need.
|
| The fact that you're talking about "spec" here, in
| addition to your focus on individual productivity makes
| me wonder if what you're doing fits in with what's
| described in what I linked (the Agile Manifesto).
|
| Agile isn't for every team, and you can succeed despite
| not communicating, but there are risks and costs involved
| that, if made explicit, would not likely create costs you
| or your team would actually want to pay.
| losteric wrote:
| What you're describing sounds much closer to my experience
| on a waterfall development cycle. Huge commitments without
| any dev-input, leading to the dev team constantly churning
| around knowledge silos or poor tooling setup.
|
| My experience on agile was very different. Senior tech
| folks would, yes, spend up to and even more than 50% of
| their day in cross-team group discussions... but the junior
| ICs would typically spend 90%+ focusing on implementing
| tasks, except for the weekly sprint planning meeting.
|
| The Agile process we had was one were stories were well-
| defined prior to implementation - supplemented by great
| documentation and test coverage. A genuine new hire would
| typically be able to pick up and implement small stories
| with zero communication overhead in their first 2 weeks. I
| see _this_ as ultimate goal of an agile process - clean
| spec 's upfront, unambiguous implementation, acceptance of
| potential second iterations _instead of_ monolithic group
| decision making.
|
| On that team, product had an agile process in advance of
| the dev sprints which built mocks and got sign-offs for
| implementation (I've also been on teams where
| design+implementation fell under the same story).
|
| Even algorithmic or systems heavy work was still at least
| 60% independent work, with occasional meetings throughout
| the day to pass ideas by or brainstorm new areas of
| research.
| TameAntelope wrote:
| I'm not sure I know how to square "Working software over
| comprehensive documentation" with "well defined stories
| with great documentation" and "clean specs upfront".
|
| Those sounds incompatible, I'd even go so far as to say.
|
| Imagine throwing out every process you just described
| (minimal specs and plans, no contracts, no documentation,
| avoiding as many processes and tools as possible), and
| instead replacing them with conversations. You'd have
| those conversations (dev to dev, dev to PM, PM to
| customer, dev to customer), spend a few days building
| software, and then have those conversations all over
| again, continuously looping until the product is either
| "done" or something more important came up to work on.
|
| Would you call that team "agile" or "waterfall"?
| dijit wrote:
| I believe that's the definition of agile (as defined in
| the agile manifesto) but what is practiced as "Agile" is
| actually a weird waterfall pattern.
| losteric wrote:
| > Imagine throwing out every process you just described
| (minimal specs and plans, no contracts, no documentation,
| avoiding as many processes and tools as possible), and
| instead replacing them with conversations. You'd have
| those conversations (dev to dev, dev to PM, PM to
| customer, dev to customer), spend a few days building
| software, and then have those conversations all over
| again, continuously looping until the product is either
| "done" or something more important came up to work on.
|
| > Would you call that team "agile" or "waterfall"?
|
| Waterfall, 100%. I've been through that hell - management
| comes down with a date and brief elevator pitch. Then
| we're in constant talks over the next two weeks to hit a
| date no one really understands the requirements or
| rationales of, ironing out responsibilities between teams
| without any holistic long-term architectural vision
| (because there isn't even a product vision).
|
| > I'm not sure I know how to square "Working software
| over comprehensive documentation" with "well defined
| stories with great documentation" and "clean specs
| upfront".
|
| Comprehensive documentation literally means a very high
| coverage, perhaps 100% coverage of architecture docs,
| tutorials, design specs, etc. I said "well defined" and
| "great" :)
|
| Agile is not contrary to documentation. Instead, there is
| a recognition that documentation's value is the time
| saved on development/discussion. That balance point
| depends on the team, and should always be considered in
| retrospectives.
|
| If you're a team of 3 that all know how everything works,
| without immediate growth prospects... yeah, who needs
| docs? On the other hand, a FAANG team of 12 growing to 30
| over the next 3 months _will_ need documentation.
|
| My "right-level" of documentation is that a junior
| engineer can pick up a story and ship it alone. The story
| is not _fully-defined_ - implementer will have to learn
| some things from the docs, read through some of the code,
| decide on implementation strategy themselves... but they
| should be able to do so without meeting with others.
|
| Meetings are expensive for teams, and context switching
| is expensive for ICs. Meetings that require bringing in
| senior engineers[1] for story-level details is all but an
| organizational anti-pattern.
|
| [1] Generally, I'd regard having any single SME in the
| critical path of implementation is an antipattern
| (borrowing from kanban, this person invariably becomes a
| bottleneck on a large fast-paced team)
| TameAntelope wrote:
| So you understand that you're taking a literal primary
| tenet of agile and calling it "waterfall", yeah?
|
| "Working software over comprehensive documentation" is
| one of only 4 values of the Agile Manifesto, and it's in
| direct conflict with what you're calling Agile.
| losteric wrote:
| I feel like you're spouting Agile (TM) rather than
| https://en.wikipedia.org/wiki/Agile_software_development
| - Agile is not one thing, it's certainly not a checklist.
| There are general philosophies of software development.
|
| The core is really adaptive planning and
| acceptance/flexibility to uncertainty, biasing towards
| shipping first. There is no requirement to be spending
| all day in endless meetings, nor an opposition to
| documentation. If more documentation increases velocity,
| why would that be anti-agile?
|
| More importantly, what works for _you_ does not discredit
| another team 's agile approach. I lead large and growing
| teams rapidly releasing greenfield software. We are
| definitively agile, and documentation is _empirically_
| key to that process. Perhaps your experience differs. I
| don 't discredit that, merely provide my experience in
| contrast.
| gashmol wrote:
| 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.
| ianbutler wrote:
| > 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.
| btown wrote:
| 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!
| Clubber wrote:
| >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 wrote:
| > 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 :-)
| thenerdhead wrote:
| 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.
| beckingz wrote:
| And what should a PM do when their engineers are not effective at
| shipping?
| Clubber wrote:
| 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 wrote:
| 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.
| beckingz wrote:
| Agreed that getting more specific with tasks is helpful.
|
| Unfortunately, it's hard to leave the engineering approach
| for larger projects to the developers when their productivity
| (and apparent satisfaction) increases significantly with task
| specificity.
|
| Maybe this just indicates an issue with developer
| experience/seniority.
| booleandilemma wrote:
| Make smaller and smaller goals until they can ship.
| thenerdhead wrote:
| Plan an intervention with the EM or find another job if they
| are competent themselves.
| cudgy wrote:
| "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.
| banana-19 wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-21 23:01 UTC)