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.
> 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.
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.
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.
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.
> 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)
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.
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.
I'll second the concerns at touting FrAgile (TM). Too many teams woefully underestimate the level of work yhat goes into maintaining the full delivery of product, and the fact that as you scale up, process has to be in place to keep people working independently without running into issues.
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.
So when you see, "Individuals and interactions over processes and tools." and, "Working software over comprehensive documentation." how do you square that with, "You can't just NOT make SOP's"?
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
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.
I totally agree that aligning with customer need is more than worth the time taken, but that shouldn't be taking 50% of developers time. More like 20% in my opinion. Internal collaboration between devs can take another large chunk of time, but that depends on how experienced (and how good) the developers are.
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.
This feels like a huge leap to justify "quantity of communication = quality of communication", while disregarding the effects it has on individuals, or the product. It also pushes people further into constant synchronous communication.
>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.
Fortunately I do not require your help. If you would instead highlight where exactly the manifesto requires a quantity of communication as large as half a day if not more, or prove that this is so valuable it warrants bypassing individual needs, I'm all ears.
> 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.
> 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.
>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.
> 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 :-)
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.
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!
> 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!
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.
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.
>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.
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.
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.
I agree with you largely, except for one thing - Doing the right thing for their team is the right thing for their career, whether current management sees it or not.
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.
I would say that the PM needs to do the best for the company, which sometimes is defending their team, but others is making their team understand a recent company pivot/shift.
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.
Yes I totally agree with you. For clarity when I said "defending their team" I didn't necessarily mean act as a representative to argue their views to management. I've seen many times when what a team wanted would have been really bad for business, which in the end serves nobody.
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 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.
> 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.
"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.
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.
>> 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.
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.
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.
>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.
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.
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.