It really bothers me when I hear leaders talk about their "top priorities" in the plural. The contradiction is plain to see. Teams already juggling competing demands don't respond well to being told that everything is the top priority; it causes confusion and risks burnout. A lack of proper prioritisation is more than messy language; it's a sign of deeper organisational dysfunction. In practice, multiple priorities can make sense when framed with clarity, perspective, and an understanding of the trade-offs.

By exploring this discomfort, I've developed a more practical perspective: that prioritisation is about understanding the lenses through which we perceive value, urgency, and risk. Just like my prescription glasses differ from someone else's, different lenses bring different focus. This metaphor helps teams navigate complexity with greater clarity and intent.

Is Priority Singular?

Priority, coming from 'prior', meaning before - implies being a singular term: this before that. In Greg McKeown's book Essentialism, he argues this historically:

"The word priority came into the English language in the 1400s. It was singular. It meant the very first or prior thing. It stayed singular for the next five hundred years. Only in the 1900s did we pluralise the term and start talking about priorities."

Google's N-Gram data data backs this up: "priorities" didn't appear in the literature record until the mid-20th century. That definition logically makes sense; there can only be one most important thing, right?

Why did priority become a plural concept? McKeown argues:

"Illogically we reasoned that by changing the word we could bend reality. Somehow we would now be able to have multiple 'first' things."

Sure, when the office fire alarm sounds, I don't stop in the stairwell to spend some time on other priorities.

However, I am unconvinced this semantic diffusion is a deliberate attempt to "bend reality" against the workers. Instead, it is an evolution of language that reflects the complexity of the world and the need to juggle competing goals. Even in the Agile Manifesto, the first principle refers to a team's "highest priority".

Language matters as it shapes decision-making and how the teams perceive direction. There is a difference between having multiple priorities and a lack of prioritisation. So, what happens when everything is the top priority?

Anti-Pattern: Too Many Priorities, Not Enough Focus

The adage is that "if everything is top priority, then nothing really is", which frustrates me most about the drift in language. Priority has clarity and decisiveness, with intentional actionability.

Deciding to act is also a decision to defer, delay or drop other work. Prioritising everything bypasses the latter component: saying "not now". That may provide political cover in an organisation ("it's still a priority"), but it comes at the expense of clear focus for the team. It's deciding not to decide.

Over-prioritisation risks team members' welfare and the team's success. Instead of a clear focus, there is ambiguity. Uncertainty creates anxiety, leading to burnout, over-commitment, failure to deliver, and spending time on the wrong work.

The Reality of Competing Demands

It is often impractical - and even unhelpful - to cling to the singular meaning of "priority" in environments shaped by interdependencies and time-sensitive needs. Insisting on a single priority risks flattening the nuance and complexity into absolutes. While everything cannot be the top priority, that doesn't mean there aren't multiple urgent and valuable threads deserving attention. We need better language.

People say "priorities" in common parlance because they have sensed and named their work's complexity. Let's find a different framing that recognises this reality and gives us a working language without the semantic dissonance.

Lenses as a Focusing Mechanism

Reality is complex. Customer needs, compliance, future readiness, and operations all compete for a team's attention. Stakeholders view the team's work from their unique perspective, shaped by their goals, needs, and organisational responsibilities.

These perspectives act like lenses. Each one sharpens focus on a different aspect of the team's work. It's through these lenses that competing demands emerge, shaped by what matters most to those looking through them.

Lenses are a powerful addition to a team's vocabulary. They reveal what drives decision-making and make the trade-offs in prioritisation visible. A single lens clarifies a particular concern; stepping back to consider multiple lenses helps us see where the focus is over-applied and where it's missing.

Find Your Lenses

When we explicitly name these lenses, we better understand why prioritisation is difficult and how to do it better.

Can you identify what lenses bring clarity to your team's work?

I recommend using the following template to record lenses:

Lens Name

Value question

Focus areas

Lens Name

A good lens name succinctly captures a thematic concern. If the name is too long, it becomes cumbersome to use in conversation. Aim to capture the intent or value at play - something broad enough to surface meaningful discussion but focused enough to stay actionable.

Avoid naming a lens directly after a department, single stakeholder or user persona, as this risks unintentionally embedding and amplifying silos. Name the concern, not the claimant!

Value Question

Each lens has some notion of value. What is it? Phrasing this value proposition as an open question is essential. The purpose is to invite dialogue by expressing the intended outcomes and creating the space for self-evaluation. Prioritisation is situational; a value question guides that activity. If the value proposition was a closed statement, fostering that thinking environment would be much more difficult. Closed statements impose doctrine and tend to be output-focused.

Focus Areas

If the value question is the 'why', then the focus areas section is the 'how'. In two or three sentences, it contextualises how that lens shows up in practice through the team's work. This section grounds the lens in the day-to-day reality by detailing the scope and responsibility and the typical kinds of work or activities it includes.

Lenses may change as an organisation evolves or as new customer personas emerge. They may even overlap! Expect some tension between lenses - this is key to why prioritisation is necessary. Lenses are ultimately an exercise in sense-making: a way of surfacing what matters, why it matters, and to whom.

The lenses that you choose will emerge from your context and your analysis. They're subjective, but their value lies in being useful and communicable.

Example Lenses: An AWS Platform Team

To illustrate how this works in a real-world setting, here are the lenses I currently use with my team.

I work in a Bank, overseeing the AWS Platform Engineering team. The team is primarily operational but performs capability development that the Bank's engineers can leverage to build customer- and colleague-facing solutions - the team's customers are the company's application engineers.

The number of lenses I've chosen is deliberately small. 5-7 is the sweet spot: equivalent to a hand of cards. The more lenses there are, the more trade-offs there are to juggle.

Operational

Are we maintaining a stable, secure, and reliable platform for the engineers who rely on us?

This lens prioritises uptime, incident response, service availability, performance, and meeting SLAs. It captures the platform's day-to-day functioning, including on-call responsibilities, monitoring, and managing critical infrastructure.

Sustainability

Are we investing in long-term maintainability and efficiency and reducing operational burden?

The sustainability lens looks at long-term health, including technical debt reduction, automation of toil, and complexity reduction for future maintainers. It's about avoiding team burnout and system fragility.

Governance

Are we meeting our regulatory, security, and audit obligations in a provable and scalable way?

This lens covers compliance, access control, audit readiness, policy enforcement, risk management, and secure-by-design principles. We operate in an environment with high regulatory scrutiny, necessitating strict control adherence.

Strategy and Innovation

Are we aligning with the Bank's broader technology strategy and enabling future direction?

The Strategy and Innovation lens captures alignment to high-level initiatives such as cloud adoption, architectural patterns, and standards. It focuses on discovery spikes, PoCs, or low-risk experimentation with emerging technologies, helping us orient towards being proactive enablers rather than being stuck in reactive support.

Customer

Are we improving the experience, speed, and safety of engineers building on our platform?

Engineers are our customers, so this lens focuses on engineer enablement: how easy it is to consume platform services, get started, deploy securely, and debug issues. It includes internal documentation, onboarding, developer self-service, and platform UX, directly influencing developer productivity and satisfaction.

Putting Lenses into Practice

Lenses are not a replacement for prioritisation; they are a framing mechanism to guide it. This model doesn't mean that a team should prioritise lenses rather than features. Most meaningful initiatives will deliver value when viewed through multiple lenses.

That said, at any given time, a particular lens may come into a sharper focus. Even so, lenses aren't a queue of work. Mapping features to lenses builds a clearer picture of the portfolio of work, revealing patterns, gaps, or a skewed focus.

Lenses give teams a consistent, shared language to communicate value. You can express the purpose of a piece of work with greater clarity:

"AWS Backup is a key gap our customers are experiencing. It assists with our compliance requirements, reduces our operational overhead, simplifies our governance model and aligns with our self-service strategic approach."

You can also explain what makes something a priority at this moment:

“We are receiving lots of incidents at the moment regarding backup failures. This is our operational priority. Let's make sure application owners can backup and restore their apps."

Framing work this way helps to align stakeholders without relying on who shouts the loudest. It connects the dots between goals and action.

Conclusion

Prioritisation is a matter of directing focus. When teams consider the different lenses at play, they're better equipped to make deliberate trade-offs and form a shared understanding of what matters now and why.