Working as an independent consultant gives you a strange advantage: you get to watch the same organisational patterns repeat across completely different industries. New leadership arrives. A new strategy deck appears. A familiar set of “transformations” roll through. And somewhere in the noise, the security team is expected to keep the lights on, keep the auditors happy, and somehow also “be more proactive” against a threat landscape that changes faster than most businesses can plan.

This came up recently in a catch-up with a mentee. Their organisation was going through leadership change, and the security function was feeling the same gravitational pull it always does in those moments: everything becomes urgent, everything becomes visible, and everything becomes a priority.

Which brings us to a syndrome that turns up again and again, especially with new managers trying to prove they’re decisive: “Everything is Priority One”.

The appeal of that approach is obvious. It sounds comprehensive. It sounds hard-charging. It sounds like you’re taking security seriously. In fast-scaling startups, where you don’t yet have clear ownership split across security engineering, operations, GRC, and architecture, it can even feel unavoidable. If the team is small, every risk looks like it’s heading straight for the front door.

But “everything is priority one” isn’t a strategy. It’s a misunderstanding of what prioritisation is supposed to do.

A priority only has meaning if it creates ordering. If everything is top priority, nothing is. The result isn’t a stronger team. It’s decision paralysis disguised as urgency. People start context-switching constantly, scattering effort across tasks that all feel critical, then finishing fewer of them. You get a backlog of half-progress. You get exhausted engineers who feel like they’re always behind. And, quietly, you get a more fragile security posture—because the work that actually reduces risk tends to be the work that requires focus.

The problem gets worse when a team is expected to deliver project outcomes while also handling operational reality. If someone is mid-sprint on a security improvement and an alert fires, what’s the “right” choice when both have been labelled top priority? Investigate and risk missing a project deadline, or stick to the plan and risk missing a real incident? When leadership doesn’t create a clear order of operations, engineers are forced to invent one under pressure. That’s not empowerment. That’s abdication.

A more balanced approach doesn’t mean ignoring lower-priority items. It means being honest about sequencing. Immediate threats and active incidents come first. Work that reduces the likelihood or impact of future incidents follows, shaped by what actually matters to the business. Everything else becomes planned work, scheduled work, or deliberately deferred work. The aim is not to do everything. The aim is to ensure the highest-risk work gets sustained attention rather than occasional panic.

This is also where security leaders can do a better job of protecting their teams from impossible delivery expectations. It’s not fair to commit a security team to fixed project timelines as if they were a feature delivery squad, when part of their job is to respond to unpredictable events. You can run sprints, you can plan, you can ship improvements—but you need a model that acknowledges interruption as a first-class reality, not a failure of discipline.

Once priorities are clearer, the next shift is cultural: you want a team that stays engaged instead of burnt out. New managers often make a second mistake here, which is assuming leadership is about having all the answers. In security, especially, it rarely is. The best leaders I’ve worked with are obsessive listeners. They translate organisational pressure into a workable plan. They create clarity and then get out of the way.

One useful lens for thinking about this is the SCARF model—Status, Certainty, Autonomy, Relatedness, and Fairness. It’s not a magic framework, but it maps well to what security teams actually need in high-pressure environments. People want to know their work is valued. They want to know what matters and why. They need the autonomy to make decisions without being second-guessed to death. They need relationships that make it safe to ask questions and raise concerns early. And they need fairness in workload and opportunity, because unfairness is the fastest route to disengagement.

Communication is where this either holds together or collapses. When a security function is overwhelmed, the issue is rarely that people don’t care. It’s that the system they’re working in doesn’t let them succeed. The fix often starts with a direct conversation about trade-offs: if everything is urgent, what is the team allowed to stop doing? If leadership wants faster progress, what work is being deprioritised, and what risks are being accepted as a result?

That’s also where simple prioritisation tools can help—not as bureaucratic process, but as shared language. A matrix that distinguishes urgent from important can be enough to force a conversation leadership has been avoiding: not “can we do it?”, but “what gives?”

Cybersecurity will always have urgency baked into it. The work is adversarial, the stakes are real, and the next incident rarely arrives on a schedule that respects your roadmap. But urgency isn’t the same thing as priority, and treating them as the same is how teams burn out while risk quietly accumulates.

The strongest line of defence isn’t your tooling stack. It’s a security team that understands what matters, feels trusted to act, and isn’t being dragged in five directions at once.