Addressing Teams That Bypass Shared Platforms
This conversation is deceptive because it rarely appears as a mandate issue until it is too late.
A team is building around the shared platform rather than on it. They have reasons. The platform does not support their use case well enough. The timeline for platform support is too long. Their requirements are unique. Each of these explanations is locally plausible. Each of them, aggregated across teams and quarters, produces the same result: a fragmented architecture that costs more to operate than the one the platform was built to prevent.
The bypass is not usually an act of defiance. It is an act of pragmatism — a team solving the problem in front of them with the tools available to them. That makes it harder to address, not easier. There is no bad actor. There is no clear moment of violation. There is only a pattern that compounds until the structural cost becomes visible.
What makes this conversation hard
The team lead or engineering manager being addressed has usually made a reasonable local decision. The platform did not meet their needs. The timeline for platform support was too long. They had a delivery commitment. They found a way to meet it. From their perspective, they did their job.
The CTO is asking them to accept that a locally reasonable decision is structurally harmful — and to change course in a way that will cost them time, effort, and credibility with their own stakeholders. That is a difficult ask, especially when the team cannot yet feel the structural consequence of their decision.
There is also an organizational fairness dimension. If one team has been allowed to bypass the platform — even for good reasons — other teams will notice. The platform-first policy becomes selectively enforced, and selective enforcement is indistinguishable from no enforcement over time. The CTO addressing one team’s bypass is not just addressing that team. They are resetting the signal to every team watching.
The hardest element of this conversation is that it is recursive. If the bypass happened because the platform was not ready, the CTO must address the bypass while simultaneously acknowledging the platform gap that caused it. Failing to acknowledge the platform gap makes the conversation adversarial. Acknowledging it without addressing the bypass allows the pattern to continue.
What is actually at stake
The immediate question is whether this specific team migrates to the shared platform, adjusts their approach, or commits to a migration timeline. That matters, but it is not the primary stake.
The boundary being tested is whether the platform-first policy functions as a governance constraint or as a recommendation that teams follow when it is convenient. Every bypass that is resolved strengthens the policy. Every bypass that is acknowledged and allowed to persist weakens it — for every team that observes the outcome.
The mandate boundary is enforcement. A CTO whose platform-first policy is not enforced when a team has a plausible justification does not have a platform-first policy. They have a platform-first aspiration. The difference is visible to the engineering organization within one or two quarters, and the pattern of selective non-enforcement compounds faster than almost any other form of structural degradation.
How to prepare
Three things must be clear before the conversation.
First, the platform gap must be honestly assessed. If the team bypassed the platform because the platform genuinely did not support their use case, that must be acknowledged explicitly — not as an excuse for the bypass, but as a structural issue that the platform roadmap must address. Walking into this conversation without acknowledging the platform’s limitations will make the CTO appear to be prioritizing governance over delivery, which is the wrong framing.
Second, the cost of the bypass must be quantified. Not architecturally — economically. What integration overhead does the bypass introduce? What maintenance cost does it add? What is the cost of migrating away from the local solution when the platform is ready? These numbers change the conversation from a governance discussion to an investment discussion. The team made a local decision that appeared to save time. The CTO needs to show what that decision actually costs over four quarters.
Third, the path forward must be defined. A conversation that ends with “you should not have done this” is a reprimand. A conversation that ends with “here is the platform investment that would have prevented this, here is the migration plan that resolves it, and here is the commitment we both need to make going forward” is a governance conversation. Only the second one produces the outcome the CTO needs.
How to hold the position
The pressure point in this conversation is the migration cost. The team has already built the local solution. Migrating to the shared platform will cost engineering time that is not in their plan. Their stakeholders will not understand why they are rebuilding something that already works.
What cannot be traded is the requirement to migrate. The timing can be negotiated. The scope of migration can be phased. The support the platform team provides can be adjusted. What cannot be accepted is a local solution that remains in production indefinitely — because indefinitely is how temporary bypasses become permanent architecture.
The conversation must produce a specific, documented commitment: a migration plan with a timeline, an owner, and a review date. Without that commitment, the conversation has not resolved the bypass. It has only acknowledged it.
When the team’s stakeholders object — and they will — the CTO must be prepared to hold the position with those stakeholders directly if necessary. A migration commitment that evaporates under stakeholder pressure is not a commitment. It is a conversation that did not hold. The CTO’s willingness to hold the position with the team’s stakeholders is the signal that determines whether the platform-first policy is real.
What failure looks like
The most common failure is the acknowledged bypass that is never resolved. The CTO has the conversation. The team acknowledges the issue. A migration is discussed but not committed to. The local solution remains in production. A quarter passes. The migration is not on anyone’s roadmap. The CTO raises it again, and the response is that the team is too busy with current delivery commitments to migrate.
This pattern repeats until the local solution is so deeply embedded in the team’s architecture that migration becomes prohibitively expensive. At that point, the bypass is permanent — and every team that was watching has drawn the conclusion that platform-first is a policy that dissolves under delivery pressure.
The second failure mode is the conversation that becomes punitive. A CTO who frames the bypass as a failure of the team — rather than as a governance gap that the organization needs to close together — will produce defensiveness rather than resolution. The team will be less likely to surface future platform gaps early, more likely to bypass quietly rather than transparently, and less likely to advocate for platform investment within their own stakeholder group. The governance relationship that should have been built through this conversation has instead been damaged.
Five Circles reference: Circles I & III — Strategic Clarity and Organizational Foundation