Saying no.

Some years back, I was sitting in a room with my manager, our CTO and a crisis. An engineer on my team had mishandled two alerts, which had cascaded into plausibly the worst production incident the company had experienced to date. There were three root causes: alert fatigue, a lack of velocity context for out-of-diskspace alerts, and relying on a centralized database with little support for vertical scaling. At that moment, though, we were no longer talking about root causes. We were discussing whether to fire the oncall engineer, and I was saying no.

It was in that era of my career that I came to view management as, at its core, a moral profession. We have the opportunity to create an environment for those around us to be their best, in a fair environment. For me, that’s both an opportunity and an obligation for managers, and saying “no” in that room with my manager and CTO was in part my decision to hold the line on what’s right.

However, there was a second “no” in that room, and it’s one you’ll use routinely even under the best of circumstances, and that “no” is an expression of what is possible for the team you lead to do. I felt the decision would be wrong, but also that the precedent of firing folks for oncall mistakes would irreparably damage the morale of a team that already saw their phone batteries drained before the end of a twelve hour on-call shift.

This “no” is explaining your team’s constraints to folks outside the team, and it’s one of the most important activities you undertake as an engineering leader.

Constraints

Folks who communicate “no” effectively are not the firmest speakers nor do they make frequent use of the word itself. They are able to convincingly explain their team’s constraints and articulate why the proposed path is either unattainable or undesirable.

Articulating your constraints depends on the particulars of the issue at hand, but I find that two topics are frequent venues of disagreement. The first is velocity: why is this taking so long when it should take a couple of hours? The other is prioritization: why can’t you work on this other, more important, project?

Let’s dig into how to have those conversations constructively.

Velocity

When folks want you to commit to more work than you believe you can deliver, your goal is to provide a compelling explanation of how your team finishes work. Finishes is particularly important, as opposed to does, because partial work has no value, and your team’s defining constraints are often in the finishing stages.

The most effective approach I’ve found for explaining your team’s delivery process is to build a kanban board describing the steps that work goes through, and documenting who performs which steps. You don’t have to switch to using kanban, although I’ve found it very effective for debugging team performance, just populate the board once to expose your current constraints.

Using this board, you’ll be able to explain to folks what the current constraints are for execution, and help them narrow suggestions for improvement down to areas that will actually help. If you don’t provide this framework, I find that folks start making suggestions everywhere across your process, which at best means many ideas won’t reduce load on you core constraint, and at worst may inadvertently increase load there.

Once you’re focused the conversation on your core constraint, the next step is explaining what’s preventing you from solving for it. At many technology companies this comes down to technical debt or toil. However, the specter of technical debt and toil have been used to shirk so much responsibility, that simply naming them tends to be unconvincing.

Instead, you have to translate the problem into something resembling data. If you’re following a consistent project management methodology, this can be as easy as explaining how you decide the number of story points for each sprint, along with how that number has trended over time. If not, I’ve found it useful to borrow the approach of a sampling profiler: for a week, check what your team is working on at a few random moments across the day, and use that as an approximation of where time is being spent.

Once you’re able to explain your constraints and where time is being spent, then you’re having a useful conversation about whether you can shift time from other behaviors towards your constraints. The final stage comes next, which is the discussion around adding capacity.

There are two ways to add capacity: move existing resources to the team (away from what they’re currently doing) or create new resources (typically through hiring). Neither are a panacea, and they are explored in A case against top-down global optimization and Productivity in the age of hypergrowth, respectively.

Putting it all together, the best outcome of a discussion on velocity is to identify a reality-based approach that will support your core constraint. The second best outcome is for folks to agree you’re properly allocated against your your constraints and shift the conversion to prioritization. (Those are the only good outcomes.)

Priorities

Although shifting from a discussion about velocity to one about prioritization is a good outcome, expressing your priorities convincingly can be a difficult, daunting task. I recommend breaking it down into three discrete steps: document all your incoming asks, develop guiding principles for how work is selected, and then share subset of tasks you’ve selected based on those guiding principles.

Hopefully documenting your incoming asks is as straightforward as auditing your team’s tickets, but it’s pretty common for some of the most important asks to be undocumented. What I’ve found effective is to blend existing planning artifacts (typically quarterly/annual plans) and your tickets into a list, and then test it against your most important stakeholders. Keep asking “Does this seem like the right list of asks?” to folks that routinely have dependencies on your team, and it’ll turn into a fairly accurate artifact.

From there, you have to pick the guiding principles you’ll use for selecting tasks. How you’ll do that will depend on your team and company, infrastructure teams will pick different guides than product teams, but likely they’ll be grounded in your company’s top-level plans and intersected with your team’s mission. (The most controversial guides tend to be statements about the value of current work versus future work, for example doing investment work today that will pay off in two years but limit value in the short term. One technique I’ve found useful for this particular scenario is specifying quotas for both immediate and long-term work.)

The last step is sitting down with your team and applying your guiding principles to the universe of incoming asks and finding the subset to prioritize. You’ll continuously get more requests to do work, so it’s important that this process is lightweight enough that you can rerun it periodically.

Which, it so happens, is exactly what you should do when a stakeholder disagrees with your priorities. Understand their requests, and sit down with them to test their ask against your guiding principles and your currently prioritized work. If it’s more important than your current work, shift priorities at your next planning session. (To limit churn created by shifting priorities, it’s useful to wait for the next planning session instead of making these changes immediately. This does mean that you’ll need to be refreshing your plan at least monthly.)

Relationships

If you’ve poured time into explaining both your velocity and priorities, but your perspective still isn’t resonating, then it’s fairly likely that you have a relationship problem to address. In that case, the next step isn’t investing more energy in explaining your constraints, but instead to work on how you partner with your individual stakeholders.