If there’s one thing I’ve taken away from my time as an engineering manager, and later as a product manager, it’s this: Talking about difficult topics is scary, and generally also actually the best thing.
If you’re a line manager, maybe you’ve done some poking around in GitHub and Jira data, and you think there are places where your team is doing work in a way that leads to unnecessarily slow delivery. Or maybe someone up your leadership chain has raised some broad concerns about things feeling slower than they used to, and asked line managers to talk to their teams to gather ideas for improvement.
In either case, the conversation you need to have with your team can feel intimidating, and you’re right to approach it with care: it’s easy to make it sound like the team isn’t working hard enough, isn’t collaborative enough, or is being specifically targeted as a problem area.
Your goal instead should be to establish yourself as a trusted teammate in the conversation, to highlight the individual benefits of working in a more productive environment, and to ensure that any changes are, ultimately, healthy ones.
Unlike many potentially fraught conversations, you know this one is going to happen ahead of time, which is a big advantage: you have time to prep. Here’s a roadmap you can start from for a successful conversation with your team on the topic of developer productivity.
Identify shared goals
A conversation about productivity concerns can turn complicated quickly if it doesn’t start from a shared understanding of the goals of the conversation, and what is and isn’t on the table. Make clear that this is not about working more hours and it’s not about counting PRs or lines of code. Emphasize that no one wants burnout, and that’s often a side effect of an unproductive environment. This could also be a time to point out that this is a high-profile topic across the software industry right now — $company isn’t alone in thinking about this, and a lot of leaders are seeing productivity as a differentiator in their ability to win over competitors.
If this conversation has been inspired from above, don’t discredit yourself by pointing the finger elsewhere: see above, you don’t want your team members to burn out, and that’s one of the most likely outcomes of an environment where people feel like they can’t do their best work. If your engineering leaders have shared particularly compelling content about why this is important, highlight it, but the closer you can bring the conversation to your team, the better.
Acknowledge the current state of the team
Part of your job as a manager is to have an informed answer to the question “How is your team doing?” You probably know how to tell that story to your peers and to your manager; now it’s time to reflect that back to the team in a way that builds trust and, again, establishes a shared understanding.
If there are cases where the team has worked together really well, this is a time to celebrate them and highlight them as the model for what you want more of. Even if the examples are small, they’re useful: they can help turn an ambiguous topic into a more defined one. This part doesn’t need to be all that data-driven — you want to emphasize times when individuals acted in the interest of the team’s goals, times when people collaborated together particularly well, projects that went particularly smoothly.
At the same time, if the team has recently gone through any big challenges — a change in manager, the cancellation of a project, the departure of a beloved colleague, or layoffs that landed a little too close to home — don’t pretend those challenges don’t exist. SPACE reminds us that satisfaction and well-being are key components of productivity, and you do yourself no favors by pretending the team is operating at full, distraction-free cognitive strength if that’s not the case.
Lead with questions, not answers
You have your own ideas about how the team could be more productive and effective, but set those aside for a minute. In a team conversation, your role is to be visibly curious, to be open to new ideas (even if they seem bad) by saying “Tell me more …” instead of “I’m not sure that would work.” Most importantly, intentionally make room for divergent thinking — allow lots of things to be on the table, even if you think they won’t work. One person’s “bad” idea could inspire another teammate’s transformative idea.
Similarly, don’t initially limit what kinds of changes are in scope — step-change improvements can come from questioning assumptions like “every change to the app must require a code change.”
“How can we be more productive?” is a question, but not a particularly great one. Come prepared with offbeat, open-ended questions such as:
- What’s a missing tool that would change how we deliver software?
- If we had to skip a step in our current process, what’s the least risky one to skip? Why don’t we skip it today?
- Are there any PRs we could eliminate entirely with a new tool?
- It’s two years from now and we’re shipping faster than we ever have, and with fewer production issues to boot — what happened?
Bring a friend — and data, maybe
Some of the hardest team conversations I’ve had were made easier by the fact that I had a supportive buddy in the room. Maybe that’s your tech lead, maybe it’s your product manager or program manager. Your buddy should be someone who has the team’s trust, not someone who’s there solely to speak from a position of authority.
You may find yourself wanting to bring data to this conversation, and you’re probably right, but remember to focus on data that centers the team, not any individual. You may be inclined to talk about throughput of tickets or tasks or PRs, but activity-focused metrics like this can be really hard to have a nuanced conversation about, and your team members may be quick to argue that you are comparing apples and oranges. There’s an argument to be made that each of these things are eventually effectively equal to all of the others, but now may not be the time.
If you want “good” metrics to talk about, DORA is a good place to start — again, at the team level. If you can assemble the data, a multi-year view of the median time it takes for a ticket to go from In Progress to Done can be a compelling view of a productivity opportunity. Lean on that friend of yours to come up with other ways to tell the story — and to help you look for or anticipate conflicting data.
Anticipate hard questions
Depending on your relationship with your team, your team’s engineering culture, and your company’s relationship to the current macroeconomic environment, you can anticipate some questions that will come up if you ask your team to think about how to improve its productivity. Among them:
- Will this be connected to performance evaluations? Healthy engineering organizations can incentivize good outcomes in this space without punishing bad ones. The ideal answer here is that yes, improvements will be rewarded, but no one will be punished. If this effort is being driven by senior leaders, make sure it’s true before you say it, of course.
- Is this going to involve looking at productivity at an individual level? Engineers on a team can learn a lot from looking at how other engineers on that team spend their time, and a manager on a team can perhaps coach an individual based on their individual data, but that should be the end of it. No one outside the team itself should be scrutinizing individuals.
- Is our team above or below average? If there’s an org-wide productivity improvement initiative, it’s very reasonable to inquire whether your team is “bringing down the average”: the answer can inform how much you invest in improvement. The reality is that comparing teams a) requires a mature and somewhat standardized process, and b) even then, different teams work in different ways that work for them. If there’s any inter-team competition you want your team to be winning, it’s the competition to show the biggest improvement — no one should be competing on absolute numbers.
- Is this going to be used to target layoffs? Remember when this question seemed unthinkable, not so long ago? Today it’s very present on engineers’ minds, whether you think it should be or not. Again, the answer should be a resounding no — productivity issues are usually issues with the **system**, not with any individual operating in that system. There are other reasons to have a different set of difficult conversations with under-performers, but this is not about that.
To the extent you can, try to put yourself in the shoes of the engineers on your team — many of whom likely have less industry experience than you, many of whom have never been asked to think about such a meta topic — and think of, well, the reasons this conversation might be uncomfortable if you were them.
Share a plan to follow up
This should be the first of many conversations, with the team as a whole and in 1:1s, about improvement opportunities. Set that expectation with the team now so they can hold you accountable to it.
Use these further conversations to dig deeper into ideas that came up in the initial conversation, to connect the work to broader company priorities, to assure your team that they have the air cover to focus on this as needed. Make sure that air cover exists, through conversations with your leaders. Challenge the team to make concrete monthly or quarterly progress toward an objectively impressive goal, and plan to celebrate even small wins to help drive ongoing improvement.
Summing it all up
In the best of cases, you and I are both overestimating the feelings that might come with a conversation about productivity, and your team will act collaboratively and creatively based on the trust you’ve built up with them in spite of adversity.
Otherwise, the roadmap outlined above should help you ensure that the conversation is human-centered, team-oriented, data-informed, and focused on identifying opportunities — even unlikely ones — to make things a little bit better and then a little bit better on top of that, rinse and repeat.
More reading on difficult conversations
Two frameworks — and a lot of surprisingly useful manager trainings — have shaped how I think about having any potentially difficult conversation. If you aren’t familiar with these or haven’t visited them in a while, I highly recommend Crucial Conversations (the book is decent, but a live training is especially powerful, if you can swing it — I’m thankful a former employer made this available) and BICEPS (the Paloma Medina version).
In addition to reading about the BICEPS framework, Lara Hogan — a leadership coach with a particular focus on healthy, human-centered teams — has two great posts about using BICEPS to navigate surprising emotions:
