An internal developer platform usually begins with a sensible ambition: reduce repeated preparation and give application teams a dependable route to useful services. Over time, the ambition can change into a numerical objective. Adoption becomes the headline. A team outside the platform becomes a problem to solve, even when the service does not yet support its requirements. I think that shift can turn a useful engineering product into a measure that asks the enterprise to forget why it was built.
My test is whether the platform makes appropriate work easier to deliver and maintain under conditions the bank can explain. That includes the cost of support, the limits of the common route and the obligations retained elsewhere. Universal adoption may eventually be sensible. It is not evidence of value by itself. A team can be nominally onboarded while continuing to do the difficult work through an unofficial arrangement that the platform account does not acknowledge.
Fit comes before the percentage
At Talverin, twelve application teams were considered for a common developer platform. Nine could use the initial offering. Three had requirements it did not support. The platform sponsor understandably wanted one route to operate and improve. The specialist teams wanted assurance that joining would not make them responsible for compensating for missing capability while their adoption was reported as a success. Both positions had an economic consequence worth examining.
I asked for the outstanding requirements to be described in terms of the work they enabled. That prevented the conversation from becoming a contest between advocates of standardisation and defenders of local preference. Some differences may be historical habits that no longer deserve separate support. Others reflect a continuing need the common service has not met. The engineering decision depends on distinguishing those cases, not on assuming that every exception belongs to the same category.
Over ten weeks, we spent USD1.8 million on selected support changes. Two further teams adopted the platform. Eleven then used the common route, while one retained a separately governed specialist arrangement. I did not present the last team as a failure hidden at the edge of an otherwise successful chart. Its requirement, owner and support cost remained part of the operating model. Management could therefore examine whether expanding the common service would be worth the additional work.
That account is more demanding than an adoption total. It asks the platform owner to explain what the service does well, where it stops and what a receiving team must still provide. I regard those explanations as product management for an internal service. Application teams need a proposition they can evaluate, just as the platform team needs a coherent scope it can support. Neither benefits when a numerical ambition quietly promises capabilities that have not been built.
Keep the benefit attached to the observed work
For the original nine adopters, the observed median interval from approved request to a usable test environment moved from 4.2 to 2.1 days across the comparison periods. That was a useful result. It concerned the same cohort and a defined preparation stage. We did not add the two later teams to the earlier comparison or describe the change as evidence that the entire delivery process had become twice as fast.
A test environment is one condition for development work, not the whole journey to a production release. Requirements, implementation, review, testing and operating decisions can still determine when a change becomes usable by the business. Reducing one waiting interval may help that journey, but the relationship needs examination. If another constraint dominates, a shorter preparation stage may improve the developer's experience without producing the same proportional change in elapsed delivery time.
The observation was also not a controlled experiment isolating every other change. I included that limitation because the platform did not need an exaggerated claim to be useful. The evidence supported further operating review and a more informed discussion of the service's cost. It did not establish a staffing reduction or authorise an arbitrary acceleration of every team's commitments. A modest benefit explained accurately is a stronger foundation for investment than a broad claim colleagues cannot reproduce.
I want the cost account to remain equally clear. The USD1.8 million programme was a specific period of engineering and support work. Continuing platform operation and the specialist route have their own obligations. Counting an initial waiting-time improvement while leaving those costs outside the discussion would produce an incomplete economic story. The next investment decision should compare what the service can support with the resources needed to keep supporting it.
An exception is a continuing decision
A governed exception is not simply a team permitted to do anything it prefers. It has a reason, an accountable owner and a support arrangement the enterprise can understand. Its basis should be revisited when the team's requirement or the common offering changes. That makes the exception part of the operating decision rather than a permanent exemption whose original purpose nobody can remember.
Review does not mean assuming that every exception will disappear on the same timetable. Sometimes a specialist need remains economically sensible to serve separately. Sometimes the common platform develops enough capability that the balance changes. The useful question is what work and cost now justify the difference. A predetermined migration date can focus preparation, but it cannot establish that the receiving service has become suitable or that the specialist need has ceased to exist.
There is also a learning opportunity for the platform team. A well-described exception can reveal a capability worth adding for several future users. It can also reveal a costly edge case that should remain outside the common product. Both are valuable findings. Treating all non-adoption as resistance discourages the evidence needed to make that distinction and may lead to a platform whose scope expands beyond what its owners can responsibly maintain.
My improvement for the next proposal is to assess fit across representative teams before announcing an adoption objective. I would include straightforward users and demanding exceptions in that first examination. The aim is not to postpone a common service until it can satisfy everyone. It is to define an honest initial proposition, a credible route for extending it and the continuing responsibilities outside it. A platform earns its place when those who use it can explain its value, and those who do not can explain their remaining need.