Platform Curve
Most technology investments plateau before they deliver the full value, not because the technology fails, because the leaders don’t always understand the evolution patterns of technology and that the organizational designs around it may not match what the technology requires at each stage of its evolution.
Platform Curve covers this from both ends of the same transaction.
The Vendor Side is for CS and PS leaders at developer tools companies — the ones responsible for moving customers from successful pilot to enterprise-wide value.
The Builder Side is for technology leaders inside enterprises — the ones who bought the platform, restructured the teams, deployed the AI tools, and are still waiting for the delivery numbers to reflect the investment.
Both sections share a framework: Wardley Mapping for technology maturity, diffusion of innovation for adoption stages, and Team Topologies for the organisational infrastructure that determines whether value actually flows. What differs is the vantage point — and occasionally, the same structural failure looks entirely different depending on which side of it you are standing on.
THE VENDOR SIDE
[Vendor Side] — For Customer Success, Services and Consulting leaders at developer tools and platform technology companies, thoughts on…
The problem: Maybe your early adopters are thriving and your early majority cohort is churning at a rate that does not make sense given the product quality. Maybe your CS team is running the same playbook they ran twelve months ago and it is producing diminishing returns. Maybe 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.
The thesis behind this newsletter is simple: customer success at platforms and developer tools companies should function as a Solution Practice. It should identify where your technology creates exponential value, build repeatable patterns to reach that value faster, and remove adoption blockers through hands-on work. Not through more meetings. Not through better health scores. Not through a hidden sales motion dressed up as partnership.
Published every two weeks.
Each post addresses a specific structural problem — not a productivity tip, not a framework overview, not a list of best practices borrowed from enterprise SaaS and applied to a context where they do not fit.
THE BUILDER SIDE
[Builder Side] — For CTOs and VPs Engineering at enterprise organizations, thoughts on…
The problem: Maybe you restructured into product teams and the operating logic underneath did not change. Maybe your engineers are using AI coding tools and delivery has fragmented rather than accelerated. Maybe you adopted a developer platform, the tooling is standardized, and something structural is still in the way — and you cannot name it clearly enough to fix it or explain it to the board.
The thesis behind this section is direct: 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. This debt predates AI. AI does not dissolve it. AI accelerates the rate at which misaligned structures become visible as delivery ceilings. The question worth asking before anything else is not "which tool should we adopt next?" It is: why does this structure exist, what value does it produce, and can we eliminate the process in favor of something consumable?
Published every two weeks, alternating with the Vendor Side.
Each one addresses a specific structural problem — not a technology recommendation, not another call to "do Team Topologies," not a transformation program pitch.
Whichever side you are on, you are subscribed by default to both (sorry, a Substack limitation).
Each issue carries a clear [Vendor Side] or [Builder Side] label in the subject/title line — one glance tells you whether it is relevant to your work right now. You can turn off notifications for one section in your Substack settings at any time.
→ Read the full VENDOR Side brief → Read the full BUILDER Side brief
Who writes the Platform Curve
Val Yonchev
valyonchev.com · linkedin.com/in/valyonchev
Val is a Team Topologies Valued Practitioner (TTVP) and Associate Principal at Conflux, the consultancy founded by Matthew Skelton, co-author of Team Topologies. Val works with Matthew and Manuel directly on extending Team Topologies thinking into AI operating models and platform engineering strategy, further developing their work alongside them in live practice.
Val’s team at Red Hat’s Open Innovation Labs was an early reviewer and contributor to the first edition of the Team Topologies book. Under his leadership, they combined Team Topologies with Domain-Driven Design, Wardley Mapping, and Product Operating Model design to help some of Europe’s largest banks, insurance companies, aerospace and automotive producers to deliver technology products at speeds and quality their organizations had never before achieved. A 2018 engagement with a Finnish insurance company, delivering a new product to production 10x faster by redesigning team structures and interaction modes, remains one of the clearest demonstrations of what this combination of approaches can produce.
Val is currently Director and Head of Enterprise Solutions and Customer Success at Apollo GraphQL. He is a regular speaker at Platform Engineering meetups and conferences, a contributor to the CNCF Platform Workgroup, and holds a Lean Six Sigma Black Belt — a combination of org design, engineering leadership, and financial rigor that is rare in this space and directly relevant to the conversations this newsletter is designed to have.
He has one belief that runs through everything on this page: all organizations can be more successful — and more humane — by designing deliberately for fast flow of value if they understand there is no single framework, approach of model as a gospel. A good design for fast flow of value takes into account the business context, the technology evolution and trajectory, the architectural patterns, the SDLC and defines a matching organizational pattern.
There are better ways for engineers make a big impact on the business.
No ads. No sponsored content. If it is useful to you, share it with someone who may like it.
***
