Executive Summary
The most successful platform initiatives require leaders who can operate at three levels simultaneously: setting strategic direction, planning tactically with engineering teams, and addressing developers’ day-to-day challenges. This post illustrates each layer with real examples from my years at Microsoft – where senior leaders were expected to master technology, business, and people leadership alike – and from large-scale platform transformations that reached millions of users.
Introduction
Building a platform isn’t about controlling the system, but about guiding it.
“We can’t impose our will on a system. We can listen to what the system tells us, and discover how its properties and our values can work together to bring forth something much better than could ever be produced by our will alone.”
– Donella H. Meadows, Thinking in Systems: A Primer
I only discovered Meadows and systems thinking recently, yet this quote captures well how I’ve come to think about platform work – not as tech delivery, but as system stewardship.
Platforms are everywhere in IT. Ask someone about a “platform”, and they’ll likely point to the giants – Microsoft Azure, AWS, Google Cloud. These commercial platforms are the digital foundations on which countless businesses build their products.
But there’s another platform story unfolding inside enterprises too. More and more organisations are building internal platforms – created not for the market, but for their own internal use. These platforms serve the same purpose as Azure or AWS: to offer a foundation of self-service tools, APIs, and infrastructure as a compelling internal product. They enable people across the organisation to move faster and with less friction, supported by a shared layer of building blocks and standards. In effect, the internal platform becomes an in-house cloud on top of the cloud, tailored to the organisation’s specific needs.
During my tenure at Microsoft – a company whose DNA is platform-building – I led several strategic initiatives, including serving on the senior leadership team that transformed Dynamics NAV from a legacy on-premise product into the modern Dynamics 365 Business Central SaaS platform. I also helped build an organisation focused on engaging with software builders and turning their insights into improvements across the Azure platform.
Time and again, I found that mastering the code, the frameworks, and the bleeding-edge cloud services was the easy part. Anything unfamiliar usually gave way with a bit of curiosity and focused effort.
The real challenge lay elsewhere – and it was always the same: crafting a platform that developers would adopt, trust, and extend.
Success didn’t come from technical mastery or architectural purity alone. It came from sitting with developers, listening to their pain points, and iterating until the platform felt almost invisible – something they trusted and relied on.
I’ve yet to see a platform fail because of technology alone. When it fails, it’s almost always because we lose sight of the why – the purpose, and the people who rely on it. That was certainly the case with Windows 8 and Windows Phone – two platforms I had the pleasure of failing with, despite intense effort to the contrary. In both cases, we believed we had cutting-edge technology, but failed to align with what users actually wanted and needed. We didn’t get the why right.
Getting the why right sounds deceptively simple, but in practice it’s notoriously hard. It requires deep thinking, dedicated empathy, and a grounded understanding of how work really gets done.
Furthermore, that why has to be widely shared – across teams, functions, and leadership – adding communication, leadership, and alignment to the list of challenges that must be managed.
Building the Dynamics 365 Business Central Developer Platform
I remember when we released the first closed beta of what would later become Dynamics 365 Business Central – even the name hadn’t been finalised yet.
The goal was to invite developers to start building extensions and solutions – to treat Business Central as a true platform. But we didn’t yet have an online developer environment, and local setup was a mess. Developers had to navigate a maze of dependencies and manual configuration just to get started.
Not long after joining the product leadership team, I saw this firsthand – and it reminded me of challenges I’d tackled in my previous role. I’d worked with containers before – a lightweight way to package and run software in consistent, isolated environments – and started wondering: what if we could use them to ship a self-contained developer experience? One command, and it just worked. Not for production, but for development.
At the time, containers weren’t widely used in the Business Central product group, and the idea didn’t exactly catch fire. It felt unfamiliar – a sharp break from how things had always been done. But then I noticed something promising: someone in the developer community – outside the product group – had shared a rough prototype on GitHub. It wasn’t elegant or complete, but it showed there was interest. That was enough of a spark.
I pulled together a small internal task force – just a couple of engineers and myself – to explore the idea more seriously. We ran joint workshops, demoed early prototypes, and gathered feedback. The shared forum helped us test assumptions and bring people in early. Gradually, sceptics became champions.
From there we widened the circle – bringing in more teams to cement the path – and set up tight feedback loops: weekly, sometimes daily updates. We didn’t just ship improvements to the outside developer community; we explained our thinking, acknowledged resistance, and adapted to what we heard. That approach – grounded in purpose and mutual respect – made all the difference.
Within six months, adoption was nothing short of remarkable. We knew we were at the start of something exponential – and the millions of downloads that followed in the years ahead proved us right.
The container itself was just one piece. The deeper shift was behavioural: developers had to trust that we understood their day-to-day pain while fundamentally shifting the platform to the cloud.
Scaling the transformation
At an organisational level, the NAV-to-Business Central transition was massive and meant realigning several hundred internal engineers across multiple time zones, as well as a global network of tens of thousands of partners and developers.
Among many efforts, here are a few that are particularly relevant in the context of platform adoption and developer experience:
- Invested significant senior leadership time in defining the new architectural layering of the Dynamics 365 Business Central platform – from control plane to surface APIs – ready it for the cloud and to enable third parties to build add-ons, extensions, and custom solutions on top.
- Open-sourced the base application to invite the broader community into the process of defining critical new boundaries and dependencies: what only we should own, and what they could change and extend.
- Brought in external vendors under the same backlog and sprint cadence to accelerate delivery in well-scoped areas – such as documentation, communication, samples, and developer guidance.
- Instituted “Extension Office Hours” and other regular developer experience events and surveys, converting community feedback into concrete backlog items.
Throughout, the guiding principle remained a clear why: make third-party extensions and add-ons development friction-free, so partners could ship value faster and, in turn, accelerate platform adoption. Staying anchored to that purpose kept every discussion – from budget trade-offs to vendor scope – sharply focused.
That experience cemented a key lesson: Technology unlocks potential, while purpose and tight feedback loops unlock adoption.
Today, Dynamics 365 Business Central serves more than 45.000 customers and 2 million end users – with usage growing 75 % year-over-year. Many things had to go right for that success to materialise, and one of them was empowering – and inspiring – tens of thousands of developers to enrich and extend the platform, making it continually relevant and useful to customers.
Strategy First: Purpose and People Over Technology
The principles that powered the success of Dynamics 365 Business Central – and have guided me ever since – boil down to ideas I’ve gathered in this post.
“Start by asking what your goal is. Projects are a means to a goal, not a goal in themselves.”
– Bent Flyvbjerg, How Big Things Get Done
I think most of us have been part of projects where the why wasn’t clear – and the results were, at best, random. The antidote is to begin every engagement by asking stakeholders at all levels: “What problem are we solving – and why?” Keeping that conversation front and centre saves countless hours of confusion and course correction.
Clarity on the why can even save a business – as shown by LEGO’s remarkable turnaround, which began by asking: “Why does Lego Group exist?”.
Just as importantly, being able to clearly articulate the why to the teams I’ve led has made all the difference between teams that simply deliver, and teams that thrive and create real impact.
As the examples in this post show, I’ve often found myself in roles bridging those gaps – connecting engineers with executives (and occasionally, politicians), and translating between the logic of systems and the language of business, strategy, and leadership.
Too often, one side is buried in abstract architecture diagrams while the other obsesses over bloated slide decks. Neither sees the whole picture. My job – and my passion – has been to get both sides on the same page. Sometimes that means simplifying. Sometimes it means challenging assumptions. But it always involves some level of translation.
More often than not, the best way to align engineering and business is to swap the slide decks for a written narrative – because writing forces clarity in a way PowerPoint rarely does. I’ll take Word over PowerPoint any day.
Getting to a solid why doesn’t happen by accident. It takes deliberate effort – connecting the dots, grounding ideas in data, and having honest conversations about trade-offs, priorities, and purpose.
Here are some of the principles that have shaped how I approach strategy, platform adoption, and leading teams through change.
A Systems Thinking View
Donella Meadows, in Thinking in Systems, defines a system as “an interconnected set of elements that is coherently organised in a way that achieves something.” That “something” must be crystal clear. When purpose is fuzzy, the system doesn’t just drift – it drifts apart. The cracks show up in tool sprawl, adoption avoidance, and mounting workarounds.
Know Your Users
For external and internal platforms alike, treat development teams like customers – survey pain points, analyse support tickets, co-design features. Whiteboard sessions are great for high-level planning, but they’re no substitute for walking the floor.
I’ve never shied away from shadowing engineers for a day, taking notes on every obstacle and interruption in their workflow. In fact, over the past five years, that hands-on practice evolved into a structured model – and eventually, an entire global organisation dedicated to engaging with thousands of SaaS vendors and ISVs building solutions on the Azure stack.
Sessions like these reveal everything from missing or mis-targeted platform capabilities to fundamental conceptual gaps and UI gaffes. In one case, they showed that our so-called “self-service portal” wasn’t a product at all — it was a loosely structured wiki built for abstraction, not action. After we rewrote it with guided workflows and clear step-by-step paths, adoption jumped; what had been ignored became a true tool of empowerment.
Technology as Enabler
It’s tempting to chase shiny objects – service meshes, serverless, CNCF, and so on. I’ve learned to always pause and ask: “Will adopting this technology actually make life better for our internal users – and move us closer to our stated goals?”
A recent example drives the point home. I worked with a product team that embedded advanced resilience-and-security guidance – complete with one-click remediation – directly in the Azure Portal UI. It looked great in a slide deck, but professional developers ignored it (many even called it counter-productive). Their infrastructure is managed through CI/CD pipelines and automation scripts, so any fix applied by clicking around the portal was overwritten on the next deploy. The guidance belonged in the infrastructure-as-code tooling they live in every day, not in a UI they rarely visit.
A well-defined why acts as a filter, separating meaningful innovation from needless complexity – and preventing expensive detours that never reach the people who matter.
Earn – Don’t Mandate – Adoption
Our organisation was once called in to help with an external sample project on Azure Samples – built over several years to help thousands of SaaS developers – but it was going almost entirely unused. Why? Getting it to run required hours of frustrating setup. Most gave up before they ever saw it work.
To turn things around, I gathered a small team, and together we rewrote the sample with a robust DevOps script and clear, step-by-step guidance. Within a few months after releasing the update, usage had increased tenfold.
You can’t force adoption – or at least, not without incurring massive friction and overhead. Developers are creative. If your platform is slow, clunky, confusing, or filled with brittle dependencies, they will route around it.
Real success comes when the platform is so good that teams want to use it – because it saves time, removes pain, and feels like an enabler, not a constraint.
Why Build an Internal Platform?
Internal platforms exist to solve problems that slow teams down and drain focus. When done right, they streamline delivery and reduce complexity – but only if built with purpose.
Here are some of the key problems a well-designed internal platform can help solve:
Teams reinventing the wheel instead of delivering value?
A platform refocuses effort on what matters by handling common plumbing like infrastructure setup, deployment pipelines, authentication, and more – so teams can move faster and focus on delivering business outcomes.
Struggling with Consistency and Guardrails (Compliance-by-Design)?
A platform embeds security, policy, and regulatory requirements directly into the developer workflow. This shifts the compliance burden away from product teams. Audit trails, validation steps, and data safeguards get built in – not bolted on. Standardised infrastructure ensure teams meet the standards without relying on tribal knowledge or manual enforcement.
Are developers held back by complexity?
A great platform hides what should be hidden. It abstracts low-level details and offers clear, reusable components – whether that’s CLI tools, APIs, or preconfigured environments. Developers don’t need to become experts in networking, IAM, or observability just to ship code.
Is the developer experience sub-optimal?
When treated as a product, an internal platform prioritises usability and self-service. Developers provision what they need through a portal or API. That shifts the “path of least resistance” onto the platform itself. When the platform is the easiest and most productive way to get work done, adoption follows naturally.
Need scalable growth?
As organisations scale, platforms provide repeatability. New teams can onboard quickly. This makes growth predictable and sustainable. Adding products, engineers, and external vendors no longer means multiplying complexity.
Companies that succeed with internal platforms don’t just build infrastructure – they build leverage. Engineering teams spend less time on “yak shaving” and more time delivering features that matter. The result: faster output, better quality, happier developers, and more business results.
Start Ultra Focused and Evolve
In the Business Central project, our ‘early win’ was the one-command container; that victory bought us credibility to continue evolving with rapid iterations. Bent Flyvbjerg’s research on megaprojects shows that big-bang roll-outs rarely work, modularity, repetition, and focus are key to reducing risk. His 2021 study underscores this: the most successful large-scale initiatives break complexity into smaller, testable parts.
Here’s some high-level guidance that typically works well:
- Early Wins – Deliver something useful quickly to earn trust and build credibility.
- Learning & Adaptation – Real usage always surfaces edge cases and gaps you didn’t anticipate.
- Risk Mitigation – Smaller modules contain failures. If something breaks, the blast radius is limited.
This closely mirrors the “thinnest viable platform” idea from Team Topologies: start with the smallest possible set of capabilities that delivers meaningful value – often a basic CI/CD pipeline, standardised infrastructure templates, and a few shared services. Ship it. Observe. Iterate.
Feedback Loops and Team Structure
Many organisations stand up dedicated platform teams (I prefer the term ‘enablement teams’) who treat the platform as a product. As a tech executive, this means investing in a team whose sole job is to make other teams successful – a shift in mindset from delivering features to delivering capabilities.
Successful internal platforms evolve the way public clouds do – in response to demand and data. That means listening, measuring, and refining constantly. Set up regular feedback loops. Instrument the platform. Track adoption, satisfaction, and lead time to delivery.
These rituals aren’t process overhead; they are how we protect a learning culture where the platform team operates as product managers for developer experience. Don’t just build it – own it.
Layered Architecture
A layered model gives you a high-level map – you avoid over-engineering on day one and can grow the platform progressively:
- Infrastructure Layer – Cloud foundation, networking, CI/CD, security boundaries, and built-in guardrails.
- Platform Services Layer – APIs, deployment tooling, monitoring, and data access.
- Application Layer – Shared business logic, reusable services, and backend components.
- Enablement Layer – Documentation, automation scripts, developer portals, and APIs that expose application functionality and higher-order entities for reuse, automation, orchestration, and of course AI.
You don’t need to build all of this from day one. Start with the layer that solves the most immediate pain – then grow outward, one solved problem at a time.
Conclusion: Platform as a Strategic Asset
Internal platforms succeed when they quietly remove friction – letting teams focus on what matters: products, customers, and outcomes. When paired with a clear purpose and steady, modular progress, the platform evolves alongside your organisation – becoming not just infrastructure, but a strategic advantage.
When the platform fades into the background, its impact becomes visible through the data you collect and the feedback you monitor: faster iterations, higher quality, and a more confident, empowered engineering community.
Netflix often credits their internal platforms as key enablers of speed and scale.
Spotify open-sourced Backstage not just because it worked internally, but to encourage broader adoption – and with it, a growing community that could improve the platform faster than they could alone. It was a strategic bet: shared use would drive shared quality. An interesting approach – though probably not the right move for everyone.
If you’re on a platform journey, treat it as an ongoing conversation – not a one-off delivery. Keep the systems view, stay close to your internal users, and adapt as you go.
Like any product, a platform needs users, feedback loops, and continuous improvement – platform teams succeed not by building features, but by making others successful.
With that mindset, you won’t just build a platform – you’ll cultivate an ecosystem where good ideas move faster and great products emerge more naturally.
Platform leadership isn’t about choosing between strategy and technical execution - it’s about orchestrating both simultaneously. Whether you’re evaluating platform investments or building internal capabilities, the organizations that succeed are those that can translate strategic intent into developer reality, then back into business outcomes.
“Living successfully in a world of systems requires more of us than our ability to calculate. It requires our full humanity – our rationality, our honesty, our compassion, our faith.”
– Donella H. Meadows, Thinking in Systems
Epilog
If you’d like to dive deeper into the research that underpins this blog post, here’s a section on two books that have helped shape it’s thinking.
Two Great Books Shaping My Platform Thinking
Lately, I’ve been looking for frameworks that explain why certain platform projects succeed or stall. Two books have already given me language for what I was seeing: Thinking in Systems by Donella Meadows and How Big Things Get Done by Bent Flyvbjerg.
Both works have earned strong traction in technology and management circles. Meadows’s primer on systems thinking is now a go-to reference for leaders who want to break free from siloed thinking and understand the hidden dynamics that shape complex organisations.
Flyvbjerg’s research on megaprojects is equally compelling. Drawing on an unprecedented dataset of massive initiatives, he shows why so many fail – and what the successful ones do differently. His findings appear everywhere from academic journals to conference keynotes and strategic playbooks.
For me, Meadows crystallised that large-scale systems – internal or external platforms alike – are networks of interconnected parts working toward a shared purpose. That reinforced the need to define purpose early and align every component with it; vague goals inevitably breed tool sprawl and workarounds.
Flyvbjerg underscored the same lesson from another angle: clarity, modularity, and fast feedback loops are essential. His mantra “think slow, act fast” stuck with me – design carefully, then deliver in small, testable steps to reduce risk and build momentum.
I encountered these frameworks only recently, yet they clarified patterns I had already lived through – and they continue to shape how I approach new platform initiative.