Why developer platforms underperform in the public sector
By Thoughtworks
Ankit Wal, Head of Platform Engineering, APAC at Thoughtworks, has spent years leading the development of platforms for public sector clients. In this article, he shares common modes of failure that often impact public sector platform efforts, highlighting key takeaways from his experience.
-1737970564777.jpg)
Many organisations fall into the trap of treating central developer platforms as traditional projects, with separate build and operations phases, says Thoughtworks' Ankit Wal. Image: Canva
When it comes to digital government, standardised platforms are critical to supporting product development across ministries. While platforms hold the promise of reducing rework, improving the speed and security of projects while also lowering the cost of compliance, their success is far from guaranteed.
The foundation of building a platform lies in establishing long-term teams aligned to a clear goal: enabling developers in the organisation to do their best work by eliminating waste, friction, and cognitive load. The industry consensus is to build platforms like products, with long-lived, consumer-focused teams.
Teams and ownership
However, many organisations fall into the trap of treating central developer platforms as traditional projects, with separate build and operations phases.
This “project model” often results in subpar outcomes. A lot has been written about project vs. product model and the article "Products Over Projects" is an excellent starting point.
Another failure often seen across engagements is the “monolithic platform team” that owns all platform features, from DevSecOps pipelines to IaC modules for databases and shared API gateways.
Platform features are like product features: they are often better built by smaller, autonomous teams that can release independently—akin to the principles of microservices.

Applying this pattern to platform teams means identifying logical groupings of features and capabilities, and creating smaller squads to own and build them out.
The most challenging dysfunction, however, is the “no ownership” or the “magical inner-sourcing” model, where critical components lack dedicated ownership.
The platform capabilities are instead supposed to be built and maintained through an inner sourcing model where other teams contribute to some shared codebase.
This approach is often driven by a desire to promote “reuse” and avoid rework costs, but without the necessary investment in the platform. This underinvestment leads to underperformance.
At GovTech STACK Developer 2024, panelists including Thoughtworks’ Chief Technology Officer, Rachel Laycock, and GovTech Singapore’s Chief Technology Officer, Chang Sau Sheong, highlighted that clear product ownership is key to the success of common platforms.
In our experience at Thoughtworks, we've seen this play out across multiple sectors, reinforcing the need for long-lived teams with clear product ownership.
Platforms are products that require strong ownership and stewardship, and the platform team’s structure should reflect this principle.
To subscribe to the GovInsider bulletin click here.
Product feature roadmap vs. customising per customer
When it comes to feature prioritisation and decision-making, imagine a spectrum. At one end is “building everything custom on customer request,” and at the other is “build it and they will come.”
Many public sector leaders already understand that their internal platforms can only succeed if built as products. However, avoiding the failure mode of over-customisation can be tricky and it’s easy to overshoot to the other extreme.
Equally dysfunctional is the opposite extreme: building features with little user research or early validation, assuming users will naturally adopt the platform.
This approach often leads to features that fail to meet user needs, with platform engineers relying on implicit assumptions to prioritise and design platform features. In practice it could sound and look like -
- “Of course all developers can write YAML; let’s use that for our platform interface.”
- “We don’t know why developers aren’t using the CI/CD pipeline templates we created; they’re obviously the best design.”
- “We don’t know why developers aren’t adopting the cloud reference architecture IaC we built; it obviously covers all their use cases.”
Striking the right balance between these extremes requires strong feedback loops to ensure the platform is both usable and valuable. Embedding continuous feedback and dedicating product-focused roles within platform teams is essential to mitigate feature misalignment.
Driving adoption via mandate vs. choice
Imagine judging a contest where only one participant is allowed to compete. There is no real winner. This is the same when a platform adoption is driven by making it mandatory.
Public sector projects can rely on mandates by management to drive adoption of central platforms and tools.
While there are valid scenarios for mandating certain tools or practices—such as security or compliance requirements—this approach inadvertently masks issues and breaks the all important feedback loop required to create great (platform) products. This is particularly problematic when combined with a “build it and they will come” mindset.
When adoption rates alone are not an accurate measure of platform success - organisations should allow project teams the autonomy to choose which parts of the platform to adopt and to deviate from the standard if necessary.
For non-optional capabilities, such as key security features, other mechanisms—such as surveys and user interviews—can help continuously improve the platform’s offerings.
You can reach Ankit Wal at LinkedIn: https://www.linkedin.com/in/ankitwal/.