This is the first of a three-part series based on a real-world engagement: a company that scaled from $40M to $1B in annual revenue in just five years, and the security program that had to grow with it.

This is a story about building high-performance operating systems where security, standards, architecture, and performance act as enablers rather than constraints.

  • Part 1: Earning credibility before you’ve earned authority.
  • Part 2: Blurring the lines - Security at the SRE and Operations level.
  • Part 3: Wrapping the gift - Transparency and agency.

The Inflection Point

A few years back, AMTI was at the heart of a fascinating corporate challenge. I was serving as a fractional CISO and advisor for a company standing at a critical inflection point.

In Brazil, economic and regulatory constraints often mean that growth is a slow, predictable, and - let’s be honest - somewhat boring climb. But this was different. This company had launched a new line of business that was gaining massive traction. When I joined the fray, they were comfortably hitting 30% year-over-year growth. They were doing well, but they were preparing for something else entirely: The Hyper-Growth Phase.

The Spoiler

To give you the punchline early: this company reached a billion dollars in annual revenue in just five years. When I first stepped in, they were at $40M.

The Context: Passing V1

Out of professional discretion (and ethical necessity - blame the CISSP in me), I’ll keep the client’s identity anonymous. But their situation is one many high-growth founders will recognize.

In aviation, there is a concept called V1 - the speed beyond which you can no longer abort takeoff. You are committed. The runway behind you is useless; your only option is to get airborne with whatever you have on board.

At 30% growth, you’re still taxiing. You can stop, turn around, and fix things. But at 10x growth, you’ve passed V1. The security program you have at that moment is the one that has to fly. Most security programs are designed for taxiing - they are heavy, grounded, and cautious. If we didn’t transform security from dead weight into lift, the sheer friction of our own processes would keep us on the runway while the business was already committed to flight.

The Constraints

I believe technology emerges when constraints are broken. We had some significant ones:

The Monolith: The application wasn’t a “trendy” monolith; it was decades of organic accretion. Nobody alive fully understood the dependency graph. Re-engineering it would take years we didn’t have.

Hero Culture: Accountability was inconsistent. Knowledge was tribal. The SDLC barely existed, and the growth trajectory didn’t allow for rework. They needed survival-mode solutions. The “bi-modal IT” jargon consultants love to sell didn’t apply here - you can’t run at two speeds when one of them is “don’t crash.”

The “Theorist” Stigma: I had the backing of the C-suite, but to the engineering team, I was just another suit - a theorist who would deliver a 200-page unreadable report after three months of useless meetings.

Earning the Right to Lead

I needed to earn their confidence. Not by mandate, but by peering. I needed to join the team in the trenches.

Before touching a spreadsheet, I looked for the “scapegoat” - the team everyone blamed for every failure. The answer was unanimous: The Infrastructure Stack. The company’s primary pain point was Availability. The application wouldn’t scale, and the infra team was taking the heat for it. I had my starting point: if I could help unblock the team that everyone else was blaming, I could change the entire culture of the organization.

The Spearhead

With the right clearance in place, we dug in. The infrastructure team felt a wave of relief - finally, they had a partner with C-level endorsement who was actually paying attention to the technical debt they’d been forced to carry.

I’ve said it before: Security, Infrastructure, and Operations are the three legs of the same stool. In a matter of weeks, infrastructure was no longer the constraint. The impact was what mattered: before launching a full assessment or announcing “here are your problems,” we focused on solving the number one issue through the eyes of the people who were currently underwater.

That is how you build a bridge of trust. I earned their respect - not as a “wartime desk specialist” operating from a distance, but as a peer who was willing to get their hands dirty to clear the path.

Projecting Security

Here is the thing most people miss: Prioritizing availability was the ultimate security play.

The CISSP framework anchors security on the CIA Triad: Confidentiality, Integrity, and Availability. Most people hear “security” and think only of confidentiality. But Availability carries equal weight. When an application can’t scale and the business bleeds, that is a security failure. We didn’t lead with frameworks; we led by fixing what was broken. The framework simply provided the validation for our direction.

We partnered with the infrastructure team with one objective: Keep the system running. It wasn’t a coincidence that the infrastructure improvements and the security mission pointed in the same direction - it was synergy. By stabilizing the environment first, we ensured that future standards and assessments would land on stable ground instead of quicksand.

Setting the Compass

You need your eyes on the compass at all times.

Communicate North: Give executives the confidence that risk is being managed.

Unblock South: Remove friction so the engineers can execute.

Align East-West: This is where the momentum builds.

The “East-West” were my peers - AMTI’s bench and the client’s internal departments. Once infrastructure stabilized, something shifted. Sales and Procurement - teams that had spent years apologizing for the system - started operating in a new reality. The system was just there. Always on. Like a utility.

Nobody thanks the power grid when the lights work, but everyone notices when they don’t. We had taken availability off the table as a complaint. Now, the conversation could move to what actually mattered.

We had the North aligned. We had unblocked the South. The East-West was finally feeling the difference. The real work was about to begin.

Codifying the Chaos

Operations already existed - they were just crooked. But that’s the nature of organic growth. No tree grows as a perfect, isometric cylinder; it twists and bends as it reaches for the light. Our job wasn’t to cut the tree down and start over, but to steer it in a feasible direction.

We started locking in standards and playbooks. Suddenly, there was a baseline. We weren’t building a theoretical fortress; we were simply fencing the perimeter of the land the business had already grabbed.

Was it “state-of-the-art”? That’s the wrong question. In a hyper-growth environment, the only question that matters is: “What does the business need right now?”

Clean Sheets

The most surprising result of this infrastructure stabilization was who got unblocked next: Compliance and Protection. As the infrastructure, operations, and reliability teams began to embrace this new reality, the atmosphere shifted. There were fewer tickets, less “pager fatigue,” and finally, the breathing room needed to decentralize tribal knowledge and build proper, sustainable systems. We were moving away from chaos and toward structure. And let’s be honest - everyone likes the feeling of clean sheets on the bed.

The Hardening

With the foundation stable, we moved into “security proper.” We began hardening devices, centralizing the management of certificates and operating systems, and automating application baseline deployments. We implemented continuous data protection with verifiable evidence and formalized our Disaster Recovery protocols. Reliability metrics - RPO, RTO, SLOs, and Error Budgets - became the standard data contracts of our operations. Everything started to bloom.

The resistance from the engineering team? Near zero. By this point, the stakeholders weren’t just following a policy; they were experiencing the tangible benefits of the trade-offs we had made. We had replaced friction with flow. It was a true win-win: the engineers got a platform that actually worked, and the business got a security posture built on solid ground.

Suddenly, items for ISO, NIST, and SOC 2 were being marked as completed. It was a bit like Pooh “discovering” the North Pole: he wasn’t actually looking for it, he was just busy helping a friend - but he ended up exactly where he needed to be.

The View from the Sidelines

It’s easy to throw stones from the cheap seats.

I’ve seen too many security programs that operate like a series of hammer strokes - blunt, top-down, and designed more to diffuse blame than to solve problems. These programs ignore the “why” behind an organization’s development. Companies don’t grow “crooked” by choice; their systems are the result of years of talented people doing the absolute best they could with the constraints they had at the time.

I’ve been on the receiving end of the so-called “Security Experts” who spend their days painting Excel cells and shifting bars on a Gantt chart. They preach “blameless culture” not as an engineering principle, but as a personal shield: a safe way to say, “The project is delayed, but don’t look at me.” They hand out piles of incomprehensible chores from the safety of their ivory towers, treating security as a blame-diffusion exercise rather than a collaborative effort. In that world, the “expert” is just a critic, and the engineering team is the target.

What Stayed With Me

There is a pattern buried in this story that took me years to fully articulate: We didn’t build a security program by starting with security. We built it by starting with the pain.

Availability was the wound. Infrastructure was the scapegoat. Tribal knowledge was the fog. The standard playbook - assess first, report second, implement third - would have failed here. Not because the methodology is inherently wrong, but because it assumes a level of trust that simply hadn’t been earned yet.

Before I had a name for it, what we were actually practicing was Resilience Engineering. Not the academic kind, but the pragmatic kind: the kind where you stabilize what is failing, build genuine relationships with the people closest to the problem, and let the standards emerge from the work rather than imposing them from above.

Security didn’t arrive as a mandate. It arrived as a side effect of things getting better. And I’ve come to believe that is the only way security truly scales during hyper-growth.

The foundation was set. The team was aligned. The compliance items were practically filling themselves in. But we were still operating at the infrastructure and platform layer. The next challenge was threading security into the heart of the application itself - into the SRE workflows, the deployment pipelines, and the daily rhythm of a company that was doubling in size every year.

That is where the lines really start to blur.

Part 2: “Blurring the Lines - Security at the SRE and Operations Level” will be published soon. A link will be added here once it’s live.