There’s a principle in Taoist philosophy called wu wei, often translated as “effortless action” or “non-doing.” It doesn’t mean passivity. It means acting in accordance with the natural shape of a system rather than fighting it, adding force only where force is actually needed. Marcus Aurelius wrote something adjacent to this in his own register: focus your energy on what is within your control, and let go of the rest with discipline rather than anxiety.
I think about both of these ideas constantly when I think about SecOps team structure, because the instinct in our industry runs in exactly the opposite direction. The default response to “we need better security operations” is to add headcount, add tools, add process. More analysts. More dashboards. More meetings to review the dashboards. We mistake motion for progress and accumulation for maturity.
After spending the better part of fifteen years building and rebuilding a security operations function, first as a practitioner in the trenches, later as the person responsible for the architecture and the people, I’ve come to believe the opposite is usually true. A lean SecOps team, deliberately shaped, outperforms a large one assembled by accretion. Not because lean is cheaper, though it often is. Because lean forces clarity that scale lets you avoid.
The Crown Jewels Problem
Every SecOps program eventually runs into the same wall: you cannot monitor everything equally, and pretending you can is how you end up monitoring nothing well. The instinct to treat all assets as equally critical is, ironically, a failure of discipline dressed up as thoroughness.
The Stoics had a name for the discipline of differentiating what truly matters from what merely demands attention. In practice, this means doing the unglamorous work of tiering your environment, identifying the handful of systems, data stores, and identity paths where a compromise is existential, and being honest that everything else is a lower tier of concern, however uncomfortable that hierarchy feels to the teams who own the lower-tier systems.
A lean team that has done this work well will outperform a large team that hasn’t, every time, because the lean team knows where to look first. I’ve watched well-resourced programs drown in alert volume from systems that, even fully compromised, wouldn’t materially harm the business, while the genuinely critical paths get the same cursory glance as everything else. In one environment I inherited, well over half of the daily alert volume was coming from a handful of systems that, even fully compromised, would have cost an afternoon of cleanup, while the identity path that actually controlled everything downstream generated a fraction of that traffic and got a fraction of the attention. That’s not a tooling problem. That’s a tiering problem, and no amount of headcount fixes it.
Relocate the Effort, Don’t Remove It
If I had to name the single highest-leverage decision in standing up a lean SecOps function, it’s this: invest disproportionately in the pipeline before you invest in people to staff it.
By pipeline, I mean the actual mechanical flow from signal to action, telemetry ingestion, detection logic, enrichment, case creation, ticketing, and closure, built so that the analyst’s job starts at “here is a contextualized issue requiring judgment” rather than “go figure out if this raw event means anything.” Most SecOps teams I’ve seen are oversized because the pipeline is undersized. The analysts are doing the triage work that automation should be doing, and the organization responds by hiring more analysts to absorb the load rather than fixing the load.
This is wu wei in its most literal operational sense: you are not removing effort from the system, you are relocating it to where it belongs. The effort of triage, correlation, and initial enrichment belongs in the pipeline, built once and running continuously, not repeated manually by every analyst on every shift. When the pipeline is doing its job, a smaller team can carry a larger surface area, because they are spending their attention on the judgment calls that actually require a human, not on the mechanical sorting that doesn’t.
What has changed in the last couple of years is how much of that pipeline can now run itself. Autonomous investigation has become good enough to handle first-pass triage, correlation, and enrichment at a speed and volume no human shift can match. I’ve stopped treating that as a threat to the team and started treating it as the pipeline finally doing what it was always meant to do. But there is a line I draw deliberately, and every security leader should draw it consciously rather than by default: a named person validates every high-impact action before it executes. Machine-speed autonomy earns its keep during investigation. It turns dangerous the moment it reaches an action with real consequences. The structural question is no longer whether to let the system act, it’s deciding precisely which actions a human must still own, and making sure that person carries the context to own them well. Agentic operations that no one is accountable for are not efficient, they are unmanaged risk with a faster clock. This is also where the harder cost of automation shows up, not in what it removes from today’s workload, but in the analysts it quietly stops training.
This is also, where most of the real engineering investment in a lean SecOps function should go. Not in adding another seat. In tightening the path between signal and decision until very little human attention is wasted on noise.
The Generalist Bench, Not the Specialist Roster
Lean teams cannot afford deep specialization the way large SOCs can, and I’ve stopped treating this as a constraint to apologize for. It’s a design feature.
A team of generalists who each carry breadth across detection, response, and a working knowledge of the underlying infrastructure is more resilient than a team of narrow specialists, because a lean team has no redundancy to spare. If your cloud security specialist is the only person who understands the cloud security tooling, you do not have a lean team, you have a single point of failure wearing a job title. The Stoic emphasis on self-sufficiency applies at the team level just as much as the individual level: a team that depends on one irreplaceable expert has built fragility into its own structure, however capable that expert is.
This means hiring and developing differently than a large SOC would. You are not looking for the deepest possible expertise in one narrow domain. You are looking for people with genuine intellectual curiosity and the discipline to go deep when a specific incident demands it, then come back up to breadth. I have had far more success developing this kind of analyst by deliberately handing direct reports problems slightly outside their comfort zone, under supervision, with the safety net intact, than by hiring someone whose resume already claims the expertise. Developed breadth, in my experience, holds up better under pressure than purchased depth.
There is a harder version of this problem coming, and it is worth naming plainly. Tier 1 triage has always been how people entered this field. You learned the trade by working the queue. As that work moves into the pipeline, the traditional on-ramp thins. If the machine handles the reps that used to season a junior analyst, judgment will no longer accrue as a byproduct of volume, and we have to develop it on purpose. For a lean team this is close to existential, because you cannot buy senior judgment at the scale a large SOC can. You have to grow it. On my own team we’ve baked this into how we run. Junior hires get scheduled stretch assignments during onboarding, and senior staff have protected teaching time instead of squeezing it in around the job. Development has to be treated as core infrastructure rather than a perk.
What You Let Go Of
The hardest part of running a lean team isn’t building it. It’s the ongoing discipline of not letting it become a large team by a thousand small additions: one more tool here because a vendor made a compelling pitch, one more process step there because an audit finding demanded a control nobody fully thought through, one more headcount request because last quarter was busy.
Each addition, in isolation, looks justified. The damage is cumulative and structural: every tool is something the team must maintain attention on, every process step is friction in the pipeline, every uncoordinated hire is one more person who needs onboarding into context the rest of the team already shares. A lean team stays lean only through active maintenance, the same way a disciplined mind stays disciplined only through ongoing practice rather than a single decision made once.
I’d rather say no to a tool that does something marginally useful than say yes and watch the team’s attention fragment another few percentage points. Attention, more than headcount or budget or tooling spend, is the real scarce resource in security operations. Every addition to the system draws it down, whether or not it shows up on a budget line.
Running lean comes down to the harder work: deciding, with discipline and some discomfort, what not to do, and holding that line long after the decision is made. That is the part no tool and no new hire can do for you. The work is knowing what is yours to control, giving that your full attention, and having the discipline to let the rest go.
Thomas M. Allen
