Engineering velocity is a competitive advantage in modern cybersecurity

In cybersecurity, engineering velocity has become a competitive advantage. Threats and vulnerabilities evolve quickly, customer security needs keep changing and organizations that respond faster are more likely to stay ahead. Across the engineering organizations I have led in cybersecurity, SaaS, mobility and insurance, I have seen how lengthy development cycles and unnecessary waiting make it harder for teams to keep pace.

Tooling can help, although in my experience it is rarely what makes the biggest difference. The pattern that consistently cut release cycles from weeks to days was giving teams end-to-end ownership of their services, including development, QA, operations and on-call responsibilities. Once the people writing the code carry the consequences of it in production, they invest in the automation, testing and observability that make frequent releases safe.

Look first at where work waits

In almost every organization I have assessed, the time spent actively working on a change is a small fraction of the time it takes to reach production. Work waits for review, for a test environment, for a decision or for another team’s dependency. That is why, when an organization tells me it needs to move faster, one of the first things I look at is where the work is waiting.

At one company I worked with, lead time on paper looked reasonable, but the gap between “code complete” and “in production” averaged around eleven days. The cause was a single shared staging environment that every team queued for, and we found it because we started measuring the wait time between stages rather than the work time inside them. Moving to ephemeral, per-change environments removed most of it, and it cost far less than the reorganization we had been considering.

In my experience, decision latency is another under-diagnosed constraint in engineering organizations. At one company where I was involved in modernizing a legacy platform, we cut deployment times by roughly 60%, with the biggest improvement coming when we retired the weekly release approval meeting and let teams ship behind feature flags. The engineering work had been ready for months, and decision latency was the bottleneck.

That experience is why I count approvals when I look at an engineering organization. I want to understand how many people must agree before a change reaches customers and what those approval steps are achieving. Once unnecessary waiting is removed, practices such as trunk-based development, automated testing that you trust, small changes and decoupling deployment from release can have a much greater effect.

Cybersecurity adds real pressure on both sides because the constraints are heavier, including audit evidence, customer security reviews, tenant isolation and the potential blast radius of a bad change. The urgency is also greater because when a new technique or vulnerability appears, customers expect products and content to reflect it within days. That combination makes engineering velocity part of how a cybersecurity organization competes.

For CIOs and CTOs, the starting point is quite practical. Map the path from idea to production and measure the time between steps, rather than focusing only on the time spent doing the work. In many of the organizations I have worked with, this has exposed problems that were far less expensive to fix than expected.

Give teams ownership and set clear guardrails

Across the organizations I have led, clear ownership has been essential to moving quickly. In practice, that means every service has a named team accountable for it in production, with the  authority to make decisions about its internal architecture, libraries, testing approach, sequencing and when to deploy.

Once the people writing the code also carry the consequences of it in production, they have a direct reason to invest in the automation, testing and observability that make frequent releases safe. This is one of the reasons I believe production ownership matters so much when an organization is trying to increase engineering velocity.

Cybersecurity still requires clear boundaries, and I keep a small set of areas non-negotiable and centrally owned. These include identity and access, data classification and handling, tenant isolation, contracts between services and anything carrying a compliance obligation. That list should be short enough that every engineer can recite it.

The mechanism matters as much as the policy. I prefer guardrails that are built into the way teams already work, including pipelines with security scanning, infrastructure modules that are secure by default and templates that make the compliant path easy to follow.

When deciding how much process a particular change needs, I start by looking at how reversible it is. I also consider the potential blast radius, whether the change touches identity, tenant isolation or customer data, and whether we would see a failure before it became visible to a customer. In cybersecurity, those factors can determine how quickly a change can responsibly move.

I saw this work with a new discovery and recommendation surface in a learning product. We shipped three variants behind flags to a small percentage of traffic and killed two of them within a fortnight. The cost of being wrong was a mediocre experience for a few hundred users for a few days, and the change was fully reversible.

Authentication and multi-tenant isolation require more care because mistakes in those areas can result in a breach. In the organizations I have led, that kind of work gets threat modelling, design review, a staged rollout and a written rollback plan before implementation proceeds. Taking additional time makes sense when the potential impact is that high.

Reversibility and blast radius help teams decide how much process a change needs. This allows teams to increase engineering velocity while maintaining the quality and trust customers expect.

Measure whether faster delivery is producing better outcomes

I never look at speed on its own. Throughput measures such as deployment frequency and lead time for change only mean something next to stability measures such as change failure rate and time to restore. If throughput rises while failure rate and restore time hold or improve, the system is genuinely getting better.

The DORA research program has had the most influence on how I think about this. Its research over the years has reinforced the connection between the practices that allow teams to deploy frequently and those that help them operate reliable systems. The 2025 State of AI-assisted Software Development report sharpened that thinking further by describing AI as an amplifier of the strengths and weaknesses already present in an organization.

That finding matches what I see in engineering organizations today, and it reflects a broader challenge around why faster coding does not necessarily translate into faster delivery. AI accelerates the writing of software. An organization still needs the platform, testing, ownership and delivery practices required to absorb that additional change.

This is why I am also cautious about AI code-acceptance rates as a measure of engineering productivity. Story points, sprint velocity, lines of code and pull request counts can be equally misleading when used in isolation because they measure activity and can easily become targets themselves. Individual developer dashboards can be especially damaging because they encourage people to protect their numbers, while much of the value I have seen engineering teams create comes from how people work together.

The SPACE framework developed by Nicole Forsgren, Margaret-Anne Storey and their co-authors is a useful corrective to single-metric thinking about developer productivity. It considers satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. That multidimensional view is much closer to how I have seen productive engineering organizations actually work.

Beyond throughput and stability, there are two outcome signals. The first is the time from a customer or threat signal to a shipped change because that is the number the business actually feels. In cybersecurity, a new threat, vulnerability or customer security requirement can create an immediate need to respond. The second is whether the outcomes we expected the work to influence have actually changed. Shipping more of the wrong thing faster is still the most expensive form of velocity.

For CIOs and CTOs looking to increase engineering velocity, my advice is to look first at where work waits. Map the path from idea to production and measure the time between steps. Buying tooling before removing those queues can simply automate the wait, and individual speed targets can make teamwork harder.

I would also protect the investments that make speed sustainable, including testing, observability and production ownership, and avoid starting with a reorganization. In my experience, a reorganization is an expensive response to what is often a queueing problem, and it can reset the trust an organization needs to move quickly.

Engineering velocity in cybersecurity comes from reducing unnecessary waiting, giving teams clear ownership, applying governance according to risk and measuring whether faster delivery is producing better outcomes. When those conditions are in place, engineering teams are better able to respond to new threats and changing customer needs while maintaining the quality and trust customers expect.