As engineering leaders, one of the highest leverage activities we can perform is helping our teams, colleagues, and organization effectively prioritize.

In this context, prioritization refers to taking a set of actions – requests, projects, and other day-to-day activities – and determining their importance and urgency relative to each other over a given time period of time.

It’s important to recognize that there will always be more projects than there is engineering capacity and time, and if everything is a priority then nothing is a priority. Given these two conflicting statements, prioritization can often feel impossible.

However, we can prioritize effectively and with less toil by:

• Doing the pre-work required to set the stage for prioritization
• Choosing a pragmatic prioritization framework
• Setting and managing expectations throughout the process

In this article, I will use the example of prioritizing a team’s roadmap for a quarter where there are many stakeholders involved. We will assume any prioritization is part of a strictly timeboxed planning period, but these concepts can apply within other situations, such as prioritizing features for a given project, or prioritization across tickets within a sprint.

Setting the stage

It’s important to define the pre-work necessary for prioritization. This helps build credibility both within our organization and intuition about our organization. Developing these attributes requires longer than our assigned planning period, and requires us to take action ahead of time.

Credibility

Credibility comes when others have trust about our decision-making capabilities. For leaders new to an organization or their role, this is especially precarious. Most of their colleagues are unlikely to have a good mental model or intuition about their abilities. With low credibility, our choices will likely be met with more skepticism, as manifested through pointed questions, or tedious demands for more data. Of course, a certain level of skepticism is healthy, but low credibility may lead to unproductive interrogation. It is possible to prioritize and plan without credibility, but it will be more difficult to get buy-in for our choices.

Regardless, credibility is an attribute we can obtain through healthy relationships with colleagues, our direct teams, managers, and skip-level managers. A proxy for credibility may be how effective we are at managing across, managing down, and managing above. A silver lining here is that prioritization is a repeated exercise. There is always an opportunity to be more effective in future quarters by investing in these relationships.

Intuition

In the way that credibility is outward facing, intuition is inward facing. As leaders, we need to acknowledge how deeply we understand our team’s problems and our organization’s goals. This context is important to help us determine what to prioritize and when. 

Without this intuition, we are likely missing the context necessary to make the right decisions. For example, standardizing deployments across services and adding observability tooling may both be reasonable projects on our team’s roadmap. If we know that the wider engineering team is having difficulty debugging during production incidents, we would prioritize adding observability tooling over standardizing deployments.

If we are low on intuition, we will need to compensate with a mix of qualitative and quantitative research. Using an internal platform team as an example, qualitative research can include activities like interviewing the engineering team about their needs, whereas quantitative research can include diving into metrics through specific observability tooling. 

Of course, even with intuition, we should do some research – the main factor is how much is required. With low intuition, we will likely need to devote time to extensive research. With high intuition, we can save time by aggressively limiting the amount of research performed. 

Choosing a pragmatic framework

Of the many prioritization frameworks available, I recommend choosing one your organization has already adopted or is most familiar with. Unless the framework is truly untenable, there is likely little value-add in adopting a new one. Adopting a new framework will likely add additional friction to the prioritization process by increasing the possibility that you will spend time litigating the framework itself, versus doing the hard work necessary to prioritize projects. 

If your organization doesn’t have an applicable framework, there are three that I’ve had success with in the past: the Eisenhower Matrix; Rocks, Pebbles, Sand; and RICE (Reach, Impact, Confidence, Effort). 

All three frameworks are relatively well-known and have readily available easily-shareable high-quality written and video explanations. In general, I would recommend choosing a framework that’s easy for you to explain and get buy-in for. At least initially, there is little value in rolling your own prioritization framework – it’s easier to borrow explanations and guidelines from existing ones. If desired, in later quarters, you can always tweak the framework to meet your team’s needs.

Of the three frameworks, the Eisenhower Matrix (above, or download it for yourself) is the easiest to explain and the most intuitive. Your team may already be following it intuitively. It involves dividing tasks along four quadrants – important and urgent; important and not urgent; not important and urgent; and not important and not urgent. Unfortunately, the important and urgent bucket may become too full to truly prioritize. In this case, we can use one of the two other frameworks to further refine this bucket.

The Rocks, Pebbles, Sand framework provides a more granular shared language within a team, and is good for generating discussions. In this framework, ‘rocks’ refers to longer-running projects with high impact, ‘pebbles’ to smaller projects, and ‘sand’ to small tasks. For example, adding automated deployments to a service is likely a ‘rock’ whereas upgrading a simple dependency is ‘sand’.

RICE (Reach, Impact, Confidence, Effort) is the most complex of the three frameworks. I would recommend exposing your team to the core concepts asynchronously, and then aligning synchronously within a meeting. RICE excels when there are many projects, and each has obtainable metrics. Note that you will need to spend time defining the metric. The resulting score from RICE makes it easier to stack-rank projects and develop an appropriate cutline for prioritization.

Setting and managing expectations

Prioritization is likely to feel uncomfortable for you, your team, and your organization. Even in mature organizations with experienced colleagues, there is always a possibility that there will be a strong reaction if a project falls below a cutline or is deprioritized until a later quarter. 

Therefore, during any prioritization exercise, it is important for us to set and manage expectations. That is, all parties involved should understand that their project may not get prioritized; the process itself may be contentious; and teammates may (respectfully) disagree with the plan. 

As leaders, it is our responsibility to understand why a teammate may feel strongly about a project, even if we don’t agree with their reasoning. Of course, their reasoning may be sound, but may not be feasible given other constraints on time and resources. 

Ideally, we are able to provide short-term solutions for any blockers alongside a plan for the long-term. For example, if a Platform team has a request for self-service Redis cluster creation, but is unable to prioritize it for the quarter, they can point to an existing archetypal Redis cluster and documentation for a short-term solution, while deferring truly self-service functionality until the next quarter.

Looking forward

Effective prioritization requires doing the pre-work to obtain credibility and intuition; choosing a pragmatic framework; and handling expectations.

Although it may feel uncomfortable in the moment, prioritization is a skill we can all improve. At the same time, there are benefits to bringing our teams and organizations along on this journey. Prioritization and planning are unlikely to ever be pleasant, but with alignment, we can certainly make it less painful.