September 28, 2026
9 min read
If you have not read about the Four Stages of GTM Infrastructure, I highly recommend that before embarking on reading this as we will be referencing stages directly.
Let’s get practical on these stages and how we see them in real life. There is a version of Stage 2 that feels like success and a version that feels like controlled chaos. In practice, they are the same thing. Revenue is growing. The team is adding headcount. Tools are getting bought to solve real problems. Everything is working, mostly, until it isn’t.
The transition from Stage 2 to Stage 3 is something companies either prepare for or get surprised by. The ones that prepare for it build something that can support the next phase of growth. The ones that get surprised by it spend the first half of Stage 3 cleaning up what Stage 2 left behind instead of building toward Stage 4.
This blog is about the moves that separate the first group from the second. Specifically, the systems, governance, and architectural decisions that need to happen during Stage 2 if you want Stage 3 to be a period of scaling instead of a period of firefighting.
If you are already deep in Stage 3 and recognizing yourself in the warning signs from our last blog, the same moves apply. They are just more urgent and more expensive to make with the business still running at full speed.
Stage 2 companies accumulate tools. That is not a criticism. Tools are the response to real problems. The SDR team needed a sequencing tool. The finance team needed something better than spreadsheets for expense management. The Support team needed a ticketing system.
Each of these decisions was reasonable in isolation. The problem is that “reasonable in isolation” is the definition of a stack that was never designed to scale.
The shift that has to happen somewhere in Stage 2 is from “what tool solves this problem” to “what tool fits the architecture we are building.” That is not a small change. It requires someone who can see the whole stack, not just the problem in front of them. As we have discussed, most companies do not invest in this type of person at this point.
Before the next tool purchase, the question that should be in the room is: do we already have a system that can handle this with some configuration work? If yes, why aren’t we using it? If no, does this new tool integrate cleanly with what we already have, and who is going to own that integration? These are not complicated questions. They are just questions nobody is asking yet in most Stage 2 companies.
In Stage 2, every system has its own version of the customer. HubSpot knows about the prospect. Salesforce knows about the opportunity. The billing system knows about the contract. The Customer Success platform knows about the renewal. None of them fully agree and this is what a RevOps organization is usually chartered to fix. The problem is they can’t fix it, they do not have the architectural knowledge to connect the dots so what do they do instead? Manual exports from all the systems and spreadsheets or their approved AI to comb through it all.
Every system maintains its own conflicting version of customer data, creating an invisible operational crisis
This is survivable when the team is small enough that people can reconcile the differences in their heads. It becomes a crisis at Stage 3 when the team is too large for that reconciliation to happen informally and the gaps start showing up in board presentations, customer conversations, and executive decisions.
The move here is to decide, explicitly and in writing, which system is authoritative for which data. Not which system has the data. Which system is right when they disagree.
This sounds simple but it is not. Every team thinks their system is the right one. The conversation about authoritative data sources is often the first time a company’s leadership team realizes they have been making decisions off different versions of reality. But that conversation has to happen, and the earlier it happens, the less expensive it is to act on.
In a Stage 1 or early Stage 2 company, institutional knowledge living in people’s heads is fine. The team is small. Everyone knows everyone. The person who knows how the billing integration works sits twelve feet away.
At Stage 3, that same dynamic is a single resignation letter away from a crisis.
The move is not to document everything at once. That is not realistic and usually produces documentation that nobody reads. The move is to identify the two or three systems or processes where the company would be most exposed if the person who owns them left, and start there.
What does the billing integration actually do? Who built it, when, and why? What breaks if you touch it? Where does the configuration live? That documentation does not need to be long. It needs to exist.
Repeat for the next most critical system. Then the next. The goal is not a perfect knowledge base. It is a company that is not catastrophically dependent on any single person’s memory.
In Stage 2, systems requests come through Slack. Someone needs a new report, a broken workflow fixed, a field added to the CRM. They message the operations person directly. The operations person figures it out.
This works until it does not. And it stops working faster than most companies expect.
The transition to Stage 3 requires something more formal. Not because bureaucracy is good. Because the operations team cannot prioritize work they cannot see, and they cannot see work that arrives informally in twelve different channels with no context about urgency, scope, or business impact.
A structured intake process does not have to be complex. A simple ticketing system with a standard request format, a triage process, and a visible backlog is enough to start. What matters is that requests are visible, prioritized, and worked in sequence instead of in reaction to whoever messaged loudest that day.
This also creates something that did not exist before: a record of what the systems team is actually doing. That record becomes the foundation for the roadmap conversation, which is the next thing that needs to happen.
A backlog is a list of things to do. A roadmap is a prioritized view of what the systems need to look like in six, twelve, and eighteen months to support where the business is going.
Most Stage 2 companies have a backlog. Almost none have a roadmap. The difference matters because a backlog is reactive and a roadmap is strategic. A backlog tells you what is broken. A roadmap tells you what you are building toward and in what order.
Building the first roadmap is not complicated but it requires input from leadership that most operations teams have never been invited to give. What are the company’s growth bets for the next twelve months? What new markets, new products, or new motions are being planned? The systems team needs to know this before the plans are finalized, not after, because the architecture required to support a new motion often needs to be built before the motion launches.
Getting operations into strategic planning conversations earlier is one of the highest-leverage changes a Stage 2 or early Stage 3 company can make. The cost of doing it is a seat at the table. The cost of not doing it is rebuilding the stack again six months after the new initiative launches.
Here is the hard one.
Most of the moves above require someone who can think across the entire stack, not just inside one system. That is not a junior admin skill. It is not even a mid-level RevOps manager skill in most cases. It is a systems architecture skill that requires significant experience across multiple platforms, multiple company stages, and multiple integration patterns.
Most Stage 2 companies do not have that person on staff. They have an operations person who is doing their best with the context they have. That person is not the problem. The absence of senior architectural guidance is the problem.
The options here are not binary between “hire a VP of RevOps at $250K” and “keep hoping the admin figures it out.” Fractional senior systems leadership exists specifically for this stage. The companies that move through the Stage 2 to Stage 3 transition most cleanly are the ones that brought in senior architectural thinking before the dysfunction became load-bearing, not after.
That thinking does not have to be full-time. It has to be present at the decisions that matter: tool purchases, integration design, data model decisions, the roadmap conversation. Those are the moments where senior experience either prevents the next layer of operational debt or compounds it.
Reading this list, the instinct is to do everything at once. That instinct is wrong.
The sequence that tends to work:
First, establish who owns what. Systems, processes, and decisions all need an owner before anything else can be governed effectively.
Second, decide which system is authoritative for which data. Without this, everything else is built on a foundation that does not agree with itself.
Third, build the intake and triage process. Without visibility into the work, prioritization is guesswork.
Fourth, get the tribal knowledge documented starting with the most critical systems.
Fifth, build the first roadmap with input from leadership about where the business is going.
Sixth, bring in senior architectural thinking before the next major tool decision, integration build, or strategic initiative launch.
None of these require a full stop and a complete rebuild. All of them require intention that most Stage 2 companies have not yet applied to their operational infrastructure.
The companies that do this work in Stage 2, even partially, arrive in Stage 3 with a foundation they can build on. The companies that wait arrive in Stage 3 with a foundation they have to undo before they can build anything.
That is the difference between scaling and restarting.