A PM's guide to communicate effectively with software engineers
mindtheproduct.com
mindtheproduct.com
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.
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.
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!
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.
Shit, I have—but if you count only productive hours, it's more like 10-20% are talking :-)
> 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.
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?
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.
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.
I've worked on teams with all senior developers where the dev collaboration was mostly covered within that 20%, and minimal synchronisation was needed because we were all on the same page. I've also worked on teams with lots of junior developers, and that did require a lot more detailed planning and discussion that probably did take us close to 50% discussions overall. It was probably a necessary evil, but I wouldn't call it efficient, and it certainly isn't necessary in all cases.
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.
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"?
> 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)
"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.
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.
Waterfall's issue was that it stipulated there shalt be process from stage 1 before anyone even understands WTF anyone is doing. FrAgile(TM) is notorious for just cutting people loose and winging it, with no regard to system design, architecture and maintaining a cohesive whole over the entire process that keeps your business functioning.
You can't just NOT make SOP's you can't have an onboarding process that can't ne negotiated by the average person. Doing so is a recipe for burnout/churnout and failure.
>Every single one of these promotes communication
It promotes adaptation. It doesn't specify whether it should take half your workday or just 30 minutes, that's for individuals to figure out and progressively adapt to.
Outside of that, yeah it's hard to imagine more than 10%, even for me.
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!
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.
>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.
- 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.
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.
There are hundreds of companies who will happily have you be a great PM or leader at their company if your current leadership team is more concerned with promoting sycophants.
A PM without the support of his team is dead. But if he doesn't get along with management, he and his team are also dead.
In one case I actually saw a great engineer destroy his company by basically doing what he wanted to do rather than what management wanted. He was so irreplaceable that they had little choice but to allow it. In the end he turned the codebase into a nightmare of half-baked untested crap that not even he wanted to work on it. That has stuck in my mind for years as something I want to avoid.
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.
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.
"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.
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.
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.
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.
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.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.
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.
What do you think the other possibilities are?