Unifying an SDLC at a cybersecurity company
When every team has its own process and none of them talk to each other, someone has to build the connective tissue. I was that someone.
The setup
You know the feeling. A PM asks where a project stands and gets three different answers depending on who they ask. Engineering says it’s in progress. Design says they’re still waiting on requirements. The PM thought it shipped last week. Nobody is wrong, exactly. They’re just operating from completely different maps.
That was the daily reality at Rapid7 when I moved into Product Operations. Every team had built what they needed to get by: their own rituals, their own definitions of “ready,” their own understanding of when something was done. It worked, until it didn’t. And at the scale of a public cybersecurity company shipping across multiple product lines, it had stopped working a while ago.
The symptoms were familiar to anyone who’s lived inside a scaling org. Planning conversations that had to start from scratch every quarter because there was no shared foundation to build on. Onboarding that meant shadowing someone for weeks to absorb the unwritten rules, which varied by team. Delivery readiness that came down to gut feeling rather than anything you could actually point to. The people were strong. The infrastructure underneath them simply didn’t exist yet.
What made this problem hard to solve wasn’t complexity. It was invisibility. The cost wasn’t dramatic. It was cumulative: a little duplicated effort here, a misaligned handoff there, a planning cycle that took twice as long as it should because nobody had a shared language for the work.
My role and approach
Nobody asked me to build this. I saw the gap, made the case, and then built the thing. When I see structural problems that are making life harder for delivery teams, I build toward them.
The first thing I did was listen. I sat with Product Managers, Engineering leads, and Design partners and asked them to walk me through how they actually worked. Not how they were supposed to work, not the process they described in onboarding decks. How things actually moved. Where handoffs broke. What “done” meant to each of them. Where they felt friction they’d stopped noticing because it had always been there.
I see systems the way a designer sees interfaces: where the friction is, where people get lost, where the mental model breaks.
What I heard shaped three design principles that guided everything after. First: create structure through phase gates with clear entry and exit criteria, not prescriptive step-by-step workflows. People need guardrails, not scripts. Second: ground the system in artifacts that already had value (PRDs, design specs, technical assessments) rather than inventing new paperwork. Third: design for visibility. If someone has to ask “where does this stand?” the system has already failed.
What I built
The result is the Quarterly Commitment Model: 59 pages of end-to-end operational infrastructure connecting how work is planned to how it’s executed and measured. The SDLC lives inside it. Together, they answer the question every scaling org eventually has to face: how does work actually move through this company?
The SDLC is the spine. It establishes the company’s first unified development lifecycle: phase gates with entry and exit criteria, artifact requirements at each stage, and ownership clarity for who is accountable at every transition. I built custom fields in Jira (SDLC Phase, artifact status, Delivery Confidence) so that process state is always visible without anyone having to write a status update.
The planning cadence gives the quarter its rhythm. A structured planning period flows into Quarterly Commitment Week, where teams formally commit to delivery targets, then into execution with a steering process for the trade-offs that inevitably come up mid-flight. Each phase has defined requirements for what needs to be true before the organization moves forward. No ambiguity about whether you’re ready. You either meet the criteria or you don’t.
The artifact framework replaced a patchwork of team-specific documentation habits with a shared standard. PRDs, technical assessments, design specs, readiness reviews: each has clear expectations for what “complete” means, so all three functions can reference the same thing and know they’re talking about the same level of done.
Execution visibility is baked in, not bolted on. Inspection gates, delivery health indicators, and recurring ceremonies are designed to surface problems early rather than at the end of a sprint when it’s too late. Dashboards in Jira and Productboard give leadership a live view of portfolio health. No more “can you send me an update?” meetings.
The quarterly calendar ties it all together into a rhythm the organization can internalize. Planning periods, commitment windows, ceremony cadences, review cycles. When you can see what’s expected and when, you stop being surprised by the quarter.
The adoption layer
Here’s the thing about operational systems that most people learn the hard way: the design is maybe half the work. The other half, the harder half, is getting an entire organization to actually change how it operates. I’ve seen beautifully designed processes die on Confluence pages because nobody treated adoption as a design problem.
I wasn’t going to let that happen here.
Adoption failures are usually behavior problems. I design for that.
My approach was simple in principle and relentless in practice: make the new way easier than the old way. Don’t ask people to go somewhere new. Bring the system to where they already are.
That meant embedding SDLC phase tracking directly into Jira, so engineers could see process state inside the tool they were already living in. It meant configuring delivery health dashboards as browser defaults for key stakeholders, so portfolio health was the first thing they saw when they opened their laptop, not something they had to go looking for. It meant designing ceremony cadences that replaced existing meetings rather than adding new ones to already-packed calendars.
I also built Knowledge Central: a single, searchable home for all process documentation, tooling guidance, and operational standards. This wasn’t a side project. It was the critical support layer that made the SDLC stick. When someone needed to know what a phase gate required or how to fill out a template, the answer was findable in under a minute. No Slacking a colleague. No guessing.
And when I hit resistance? I treated it as feedback, not as a compliance problem. If people weren’t adopting a piece of the system, that usually meant I’d designed it for the org chart rather than for how they actually worked. The system evolved through use. The parts that stuck are the ones that earned their place.
Impact and results
The best signal that a system works isn’t a launch announcement. It’s what happens six months later, when nobody’s championing it anymore and it’s either part of how people work or it’s not.
This one stuck.
People stopped translating. Product, Design, and Engineering now operate under a common lifecycle with shared definitions for readiness, quality, and completion. Planning conversations start from the same foundation. That sounds small until you’ve been in the room where three functions spent the first thirty minutes just getting on the same page about what “ready” means.
Leadership can see without asking. Delivery Confidence indicators, SDLC phase tracking, and inspection gates provide a continuous signal across the portfolio. The “can you send me a status update?” meeting is largely extinct.
New people ramp faster. Instead of absorbing tribal knowledge that varies by team, new hires have a documented, searchable system they can learn from. Knowledge Central made onboarding consistent regardless of which team someone joined.
The system keeps growing. I built a maturity model into it, so improvement is directional rather than reactive. The organization knows where it is today and what the next level looks like, which means we’re building toward something rather than constantly reacting.
The scope extends across the entire product delivery organization: multiple product lines, cross-functional teams spanning the US and Ireland, and visibility up to VP level. I’ve since extended the work through quarterly BRP facilitation, which I redesigned from siloed pillar planning into a customer-back approach across three pillars.
Reflections
What I’d do again in a heartbeat: Build for behavior, not compliance. Every design decision that reduced friction paid off. Embedding process into existing tools instead of creating new destinations. Replacing meetings instead of adding them. Making the right action the default action. I’d also build from the organization’s specific needs every time. It took longer than importing a framework, but it fit. And fit is what makes the difference between a process people tolerate and one they actually use.
What I’d do differently: I’d push for formal measurement earlier. The qualitative signal was strong. Stakeholders could articulate what had changed, and the engagement data backed it up. But I was slow to instrument delivery health metrics in a way that made the before-and-after undeniable on a dashboard. I’ve learned that even when everyone knows something is working, the numbers still matter. That’s a gap I’m closing now.
Where it’s going: The system keeps evolving. I’m currently building AI-augmented operational tooling on top of the infrastructure: intake triage automation, in-flight pattern recognition, dependency surfacing. The SDLC was the foundation. The next layer is making it intelligent.