Four Forces of DevSecOps: Embracing the Unknown
“Jack of all trades, master of none”
We’ve all heard the phrase. I’m sure some people use it as an insult, implying that you are too diluted, unfocused or lacking in deep expertise - but I see it as a powerful force for good. Just look at some of the roles that are being recruited for - they look for a whole range of skills, asking to be an expert in multiple fields, looking for unicorns - the mythical engineers who are experts in everything from deep security analysis to React hooks to building complex networks. They don’t exist. Instead, they should be looking for engineers who love the unknown, who can adapt quickly and who can balance the competing pressures of our reality.
The reality of running a DevSecOps team is that the “jack of all trades” isn’t a nice-to-have - it’s a survival requirement. When you step into a DevSecOps role, you aren’t just “doing security”.
You are standing in the middle of four powerful, conflicting strategic forces.
The Four Forces
If you try to plan your roadmap based solely on security risks, you will, in all likelihood, fail. A modern DevSecOps team has to balance four distinct sources of work. If you ignore any of them - the platform or the team - breaks.
1. The Business (Top-Down)
This is the keep the lights on and make money work. It’s the non-negotiables. We need to release the new Payments API by Q3. We need to pass our external audit to gain X certification, so that we can close an enterprise deal. It comes from the top, and allows the business to continue revenue generation and expand.
2. The Developers (Market Pull)
These are our internal customers. This is enablement work. They need access to manage their own secrets in production. They need a Terraform module to spin up an S3 bucket without reading a 50-page policy doc. If we fail here, we become the “Department of No”, and they start working around us.
3. Strategic Initiatives (Internal Push)
This is the work we want to do. It’s how we mature. This isn’t just fixing bugs; it’s implementing frameworks like DSOMM (DevSecOps Maturity Model). It’s the deliberate decision to move from “ad-hoc scanning” to “orchestrated policy-as-code.” It’s the work that moves the needle on quality, but often gets pushed aside by the urgent demands of the Business or the Developers.
4. The Unknowns (The Reality)
This is the chaotic nature of security. The sudden zero-day vulnerability or incident (of any severity!). The “hunch” that something looks weird in the legacy auth service. The support that developers need on an ad-hoc basis. The tech debt we need to pay down before it bankrupts us.
The Myth of the Specialist
To service just one of these areas requires a specialist. To service all four, you need a Generalist. If you specialise too much in just one area, you drop the ball on the others. A pure researcher might chase the unknowns but ignore the business deadline. A pure developer might build great tools for enablement but miss the strategic initiative of compliance.
We cannot have static specialisation - we need to have dynamic specialisation.
Today, an engineer on my team might not know much about a service mesh. But if our strategic initiative requires it, that becomes their world for the next 3 months. They become the specialist. They learn it, implement it, document it and share the knowledge. Then the next quarter, they pivot to whatever the next project requires.
The team is based around the idea of T-shaped people, where the vertical bar, the depth of knowledge, moves depending on the project. I rely on the team to self-organise. The person most comfortable with software engineering might lead the tooling project, while the person strongest in networking leads the scanning outbound egress project.
The “Open Door” Investment
There is a difficult tension in this role. We want to focus on our roadmap (The Business) and our maturity (Strategic Initiatives), but while also being simultaneously responsive to the immediate, day-to-day needs of the developers.
It is tempting to say, “That’s not my job. Go ask X squad.”
But we can’t.
You are standing in the middle of four powerful, conflicting strategic forces. Keeping the “Security Door” open is not a tax on our time; it is an investment.
The moment a developer feels uncomfortable asking for help is the moment they stop reporting security issues. We answer the questions - even the ones that aren’t strictly within our realm - because we want them to keep coming back. We want to be the first port of call, not the last.
We pay the cost of interruption to buy the asset of visibility and trust.
Safeguarding the Team
However, this creates a risk. Engineers who are constantly context-switching - jumping from a compliance audit to debugging a developer’s pipeline to investigating an alert - are at high risk of burnout.
The mental toll of “alert fatigue” combined with the pressure to deliver roadmap items can lead to a feeling of constantly “batting things away” rather than doing meaningful work. When you are fighting on all fronts, things start to get missed.
As a manager, my job isn’t just to drive the roadmap; it’s to act as the umbrella. I have to do what I can to shield the team from the “Business As Usual” noise and administrative tasks so they can focus on the work that matters.
Don’t Over-Promise
If you plan for 100% capacity, you have already failed. The unknowns and the “Open Door” interruptions are guaranteed to happen. Incidents do not check your Jira backlog before they strike. I try to keep planned roadmap work to a realistic percentage (often ~60%), leaving a substantial buffer for the reality of the job.
Spotting the Fatigue
You’re not a mind reader - so don’t try and guess how people are feeling. You can watch the work. How they interact. When support and quick questions start fragmenting not only the day, but the weeks, this takes a toll. The engineer who used to ask multiple questions, now asks none. They stop experimenting, they don’t consider the whole system, as they just don’t have the headspace to do so. When that happens, I don’t tell them to take ownership, I change the workload.
The Mirror
Finally, there is one person we often forget to safeguard: ourselves. You absorb the stress from the business and the frustration from the team. But you cannot protect the team if you are burnt out. You have to watch your own energy levels as closely as you watch theirs. If you aren’t modelling healthy boundaries, you can’t expect your team to follow them.
The Generalist’s Advantage
Being a “Jack of All Trades” isn’t a bad thing - in DevSecOps - it’s the only way to function.
We balance the demands of the business, the needs of our developers, and our own drive to mature our systems. It’s a chaotic, high-pressure environment. But with a team that loves to learn and a culture that values progress over perfection, it’s also one of the most rewarding places to be.
These images are 100% handcrafted, artisan, policy-compliant pixels. Any resemblance to Gemini’s logo is purely coincidental, not an endorsement, and should be logged as a low-severity finding 😛