You invested in a developer platform. You restructured into product teams. You deployed AI coding tools and maybe even platforms for agentic. Maybe you restructured into product teams but the operating logic underneath did not change. The delivery numbers are not reflecting what you expected. The board is asking what they paid for. Your teams are using the tools, the architecture is modern, and something structural is still in the way — and you cannot name it clearly enough to fix it or explain it to the board.

This is not a tooling problem. It is not a change management problem. It is a structural problem. And it has a name.

The thesis

Enterprise technology organizations have accumulated operating model debt — a structural mismatch between how their teams are organized, how their software is architected, and how value actually flows to the people consuming the platform.

This debt predates AI. AI does not dissolve it. AI only accelerates the rate at which misaligned structures become visible as delivery ceilings.

Just because you woke up one morning and renamed your delivery teams as product teams does not mean the operating model has changed. Just because you adopted a platform does not mean the organizational design around it matches what the platform requires to be successful and generating value. The structures are new. The logic underneath is often the same as it was.

The question worth asking before yet another tooling investment: why does this structure exist, what value does it produce, and can we redesign it in favor of something that actually accelerates flow of value?

What the Builder Side covers

Diagnosing operating model debt. Not all structural debt is the same. Misaligned team boundaries require a different fix from wrong cognitive load distribution, which requires a different fix from a product operating model redesigned halfway. The Builder Side gives you the diagnostic vocabulary to name the specific constraint — because you cannot fix what you cannot name.

Team Topologies in the AI era. The four team types and three interaction modes remain the most useful structural vocabulary for technology organization design. AI introduces pressures the original framework was not written to address: cognitive load surfaces are shifting, optimal team sizes are changing, and the question of where human judgment is irreplaceable versus where AI agency can operate independently is now a live org design decision. The Builder Side extends Team Topologies into this territory.

Platform engineering as cognitive load strategy. Platform engineering is not an infrastructure initiative. It is a cognitive load strategy owned by technology leadership. In large, complex enterprises, there will be layers of platforms consuming other platforms. Infrastructure sits at the base. Developer tools and orchestration sit on top of that. Reusable components — checkout, search, authentication, data services — form yet another layer. This nesting is not the problem to be solved. It is the natural structure of a mature platform organization and it should be embraced. The central design question at every layer: what cognitive load is this relieving from stream-aligned teams, and what new cognitive load is it accidentally creating? A platform that requires three days of onboarding before a team can do anything useful is infrastructure pretending to be a platform.

AI changes this equation: platforms must now also manage the integration of AI agents, prompt governance, and the boundary between AI-assisted and human-driven work. Platform engineering without a cognitive load model is infrastructure with a product team bolted on.

The product operating model transition most organizations do halfway. Not everything needs to be a product. Regulatory compliance projects still have a place. Enabling teams, communities of practice, and boundary-spanning discovery work should not be encased in a product skin — doing so damages the value that kind of activity is designed to produce. The danger is doing the product definition exercise as a listing exercise — cataloguing everything without asking "should this exist? is there a better way? can we stop doing it?" A genuine product operating model requires value stream alignment, domain-driven team boundaries, and continuous empowerment of teams to make choices. One value stream can produce multiple products. A stream-aligned team can manage a portfolio of logically grouped products without each requiring its own dedicated team. But the operating logic — funding, governance, outcome accountability must be redesigned alongside the structure. Renaming teams without redesigning the logic is the most expensive form of operating model debt.

Wardley Mapping for technology leaders. Wardley Mapping provides the strategic layer that neither Team Topologies nor product operating model frameworks supply alone: a way to position any technology (and not only) capability on its evolution from novel to commodity, and to make deliberate build, buy, and adopt decisions at each stage. Starting with user needs and working backwards — not deciding what to build and then finding the users — is the discipline that separates organizations that navigate the curve from those that keep hitting the same ceiling at each new stage of it. For technology leaders adopting platforms and AI tooling, the Wardley lens answers the question boards are actually asking: when does this investment start delivering, and what does the organization need to look like at each stage of the curve?

Who this is written for

Lena is CTO of a Series C SaaS company, 180 people. AI tools deployed. Delivery fragmented rather than accelerated. Series D pitch in six months. She suspects the team boundaries are wrong for the architecture they have grown into. Every consultant tells her to “do Team Topologies.” Nobody gives her the diagnosis first.

Marcus is VP Engineering at a 600-person enterprise. Three platforms adopted in 18 months. AI harnesses from two different labs deployed. Velocity up 12% against a 40% expectation. He cannot name the structural constraint clearly enough to fix it or explain it to the board.

If either of those sounds like your situation, this section is written for you.

The frameworks

The Builder Side uses three lenses consistently, always in combination:

Team Topologies as the structural vocabulary for org design — extended into AI operating models through direct work with the authors at Conflux.

Platform engineering as a cognitive load strategy — the design discipline that determines whether a platform reduces friction or adds a new dependency for stream-aligned teams.

Wardley Mapping as the strategic lens — positioning technology capabilities on their evolution curve to make deliberate organizational design decisions at each stage.

Fast flow of value is the prerequisite — the condition that must exist. These three are the structural design decisions that determine whether it becomes achievable.

Cadence

One issue every two weeks, alternating with the Vendor Side. Each issue addresses one specific structural problem in enough depth to be genuinely useful. Every issue is labelled [Builder Side] in the subject line.

If you find the Vendor Side (CS and PS strategy for developer tools companies) consistently irrelevant, you can turn off those notifications in your Substack settings. The Builder Side will continue uninterrupted.

Reply to any issue if something resonates — or if you disagree. That conversation is where the thinking develops.

— Val

Val Yonchev · Platform Curve · valyonchev.com Associate Principal, Conflux · Team Topologies Valued Practitioner Director & Head of Enterprise Solutions and Customer Success EMEA, Apollo GraphQL

Connect or follow Val on LinkedIn

Your early adopters are thriving. Your early majority cohort is churning at a rate that does not make sense given the product quality and value. Your CS team is working harder than ever while having diminishing impact and producing less. Someone has asked you to own the renewal number and you have a quiet suspicion that this is corrupting the work your team should actually be doing. Your PS function is operating as a free consultancy that closes deals and destroys margin.

These are not performance problems. They are design problems. And they are connected.

The thesis

Customer success at platform and developer tools companies should function as a solution practice — recognizing the maturity of the customer’s organization and teams, identifying where your technology creates exponential value, building repeatable patterns to reach that value faster, and removing adoption blockers through hands-on work.

Not a relationship motion. Not a hidden sales arm. Not a QBR calendar dressed up as strategic engagement and health score theater.

The CS motion that works for early adopters — exploratory, high-bandwidth, no script — is precisely the wrong motion for the early majority, who need scaffolding, templates, proven patterns, and a clear path to return on investment before they commit fully. Running one model for both destroys value for both cohorts and no amount of CSM training fixes a structural mismatch.

What the Vendor Side covers

The Wardley CS model. Simon Wardley’s evolution axis tells you what stage your technology has reached and helps you identify the maturity of the customer you are working with. That stage and maturity determine the engagement model the customer actually needs — and why the model that succeeded with early adopters is structurally wrong for the enterprise majority now at your door.

The chasm handoff. The transition from early adopter CS to early majority CS is where most developer tools companies lose momentum. It is a CS design problem, not a sales problem. The Vendor Side covers what the redesigned motion looks like and how to execute the transition without losing either cohort.

Separating CS from commercial responsibility. Commercial incentives corrupt CS judgment, because the incentives are misaligned or inappropriate. The case for moving renewal and expansion responsibility to the finance or the sales organizations is structural, not ideological. This section makes that case and covers the org design that supports it. This isn’t a run away from accountability, rather focus on the levers for real impact on the growth of your company’s business.

AI-native CS scaling. The best CS knowledge in your organization should not live in your best CSMs’ heads. It should be encoded into system prompts, coding standards, agent contexts, and reference architectures that disseminate without proportional headcount growth.

PS productization. The models that break the free-consultancy cycle and the internal case for making the change without losing deal velocity.

Who this is written for

Sofia leads CS at a developer tools vendor. Her early adopter segment is thriving. The early majority is arriving and churning. She is being asked to own renewal numbers that are corrupting her team’s judgment. Her best people are doing account management instead of solution work. She needs a CS model differentiated by adoption stage and freed from commercial responsibility.

Daniel is VP of Professional Services at a platform vendor. PS is operating as a deal sweetener. Customers expect unlimited advisory. The team is exhausted and the revenue does not reflect the value delivered. The constant discussion on what is the appropriate cost of Services is wearing him out. He knows the model is broken and needs the structural arguments to have the internal discussion persuasively.

If either of those sounds like your situation, this section is written for you.

The frameworks

The Vendor Side uses three lenses consistently:

Wardley Mapping to position technology on its evolution from genesis to commodity and match the CS engagement model to the stage.

Diffusion of innovation (Moore’s chasm) to differentiate the early adopter CS motion from the early majority CS motion — and design the handoff between them deliberately.

Team Topologies applied to post-sale org design — specifically the three interaction modes (collaboration, X-as-a-service, facilitating) mapped to customer adoption stages.

Cadence

One issue every two weeks. Each one addresses one specific structural problem in enough depth to be genuinely useful. Every issue is labelled [Vendor Side] in the subject line.

If you find the Builder Side (enterprise technology leadership) consistently irrelevant, you can turn off those notifications in your Substack settings. The Vendor Side will continue uninterrupted.

Reply to any issue if something resonates — or if you disagree. That conversation is where the thinking develops.

— Val

Val Yonchev · Platform Curve · valyonchev.com Associate Principal, Conflux · Team Topologies Valued Practitioner Director & Head of Enterprise Solutions and Customer Success EMEA, Apollo GraphQL

Connect or follow Val on LinkedIn