Transforming Security Engineering Through Outcomes-Based Leadership

From Bottleneck to Business Enabler: Leading Security Engineering with Outcomes

When security teams roll out a vulnerability management program, what starts as a well-intentioned initiative often cascades into an overwhelming reality: an endless stream of Jira tickets and vulnerability alerts flooding engineering teams' backlogs. Soon, engineering and product leaders begin questioning the validity of these findings — and rightfully so. What follows is a draining cycle of back-and-forth discussions, pulling everyone away from their core mission. Engineering can't focus on building product features. Security can't focus on identifying real risks. Trust begins to erode.

As tensions mount and teams grow frustrated, organizations typically fall back on familiar — though ultimately unsatisfying — solutions: they outsource ticket management to external agencies. They spend precious budgets on promising vendor software that creates more integration headaches than it solves. They hire Technical Program Managers who, while masterful at managing cross-functional roadmaps, can become a band-aid over a deeper problem. Security leaders want and deserve a better way, but the daily pressure to keep things moving leaves little room for the strategic thinking needed to break this cycle.

Many security leaders know this. But what if we looked at this differently?

Defining the Right Outcomes

In my environment, which combined rapid-fire security demands with high-velocity development, the volume of incidents, ticket requests, exception requests, and access management requests was intense. I saw these not as problems, but as data gold mines. By querying them, finding patterns and trends, and validating pain points with engineering and product leaders, I could move straight to measurable solutions.

Let me share what this looked like in practice. It’s about setting clear objectives and key results:

Objective: Maximize Engineering Time for Product Innovation

• Key Result: 24hr SLA from Security to validate and respond to vulnerability management tickets
• Key Result: 98% accuracy rate on security findings in vulnerability management tickets

This means engineers only handle legitimate, critical issues — if security asks for engineering time, it's because there’s real risk to address.

Sounds impossible, right? What made it work was thorough implementation. This isn’t about working harder — it’s about working smarter. It means focusing on ensuring accurate criticality assessments, smooth intake processes, and robust automation. It’s easier for engineering and product leaders to get on board when they can trust that their tickets would be real, relevant, and fewer overall. The conversation shifted from "here's another security requirement" to "here's how we can help you get your time back and resolve risk efficiently."

Going from Outcomes to Implementation

The magic then happens by focusing on implementation. A dedicated Security Engineering team of builders, focused solely on writing software and following a clear plan, makes shipping the right outcomes possible. This approach works well in both high-velocity and high-security threat environments, where third-party vendor services often can't meet security standards and shipping cycles need to happen quickly.

To validate critical risks security tools can’t solve, great partners are red teams, offensive teams, and application security practitioners. In my case, I partnered with both the offensive team and application security team. Getting their commitment was easier when the scope was clearly a cross-functional priority — after all, who wouldn't prioritize enabling faster shipping cycles for product and engineering?

But building your own software creates software maintenance. Yes, it's an ongoing cost and potential time drain when managed poorly. After meeting the primary objective, it’s important to transition to maintenance metrics, turning them into OKRs that typically consume no more than 30% of team capacity. If it crossed that threshold, it signaled something needed optimization. Keeping results outcome-focused, kept pressure off teams while maintaining effectiveness.

What about new features? Depending on size and impact, it’s a matter of deciding to either roll them into quarterly objectives or maintenance work. This structure gets co-defined and agreed upon with partner engineering, product, and security teams (or adjacent individual roles in smaller companies).

The pattern is clear: focus on outcomes, set an implementation plan, deliver it, partner with teams that share incentives, monitor the data, and repeat.

This approach differs fundamentally from the traditional path of lengthy vendor integrations or having security engineers both build and conduct security reviews. While many teams start with the latter model, it becomes difficult to scale in high-growth environments.

Focusing on the right outcomes lets something remarkable happen: People start supporting security initiatives and see security as a problem solver rather than a workflow creator or gatekeeper. They rally around security initiatives because they see tangible benefits.

I now enjoy helping security leaders identify the right outcomes to resolve their security challenges, measure them effectively, and create practical implementation plans to achieve them. Does this approach resonate with your experience? Let's connect and discuss how we might apply these principles to your security challenges.