Developer platforms do indeed require a product approach. But this should mean a commitment to grasping the context of development work and a recognition of how that context (both technical and organizational) will change and evolve over time. At a broader scale, this necessitates sensitivity to the work developers do and the role they play inside an organization: it’s ultimately impossible to develop an effective developer platform while retaining the view that technical teams are little more than a resource that builds and runs code on demand.
Aligning developer context with commercial goals
But what does being sensitive to the work developers do actually look like? What does it involve?
At one level it requires you to throw out any assumptions about what developers might need or how they might like to work. We need to start from the ground up and understand collaboration, tooling, processes, skills, and culture.
At Thoughtworks we advocate for a technique we call path to production mapping. Although this is a simple idea—in which teams will literally get together and draw all the steps required to make a change and then to push it to production—we rarely see clients do it, leaving developer pain points and inefficiencies uncovered and unaddressed. For teams too, it helps ensure there’s a shared understanding of how things are done. Ultimately, it forces everyone, at multiple levels, to commit to finding out what developers actually do and what they need to accelerate the speed to value. This is a valuable foundation for any future platform development.
At another level, we also need to articulate and acknowledge the wider goals and drivers of the organization. In other words, where do development teams add value? And how can they add value faster?
This will vary widely according to the type of organization. It’s for this reason that a preconceived idea of what a platform should be (ie, what features it should have) can be risky. It would be great to be able to list examples of exemplary developer platforms—Spotify’s backstage is, rightly, often held up here—but the issue is that there is no exemplary. A perfect developer platform in one context is an inflexible antipattern in another. Fundamentally, a good platform implements guardrails that allow developers to focus on what they do best: writing and shipping code. It should reduce team cognitive loadminimizing the risk of error and maximizing the time developers can spend on value-adding work.
The needs of software developers and the commercial demands of an organization are best managed or mediated by a product owner. This is a role that’s often overlooked. Not quite a business analyst, nor a strict development role, the product owner is an essential person in ensuring that developers are empowered and that they are also delivering value for the wider organization.
Internal marketing
It’s important, however, that capturing feature requirements isn’t viewed as the full extent of platform-as-product work. Attention to detail matters, but we need to be attentive to more than just the nuts and bolts of the platform: we need to make sure that the value of those nuts and bolts can be realized. That can only be done with a coherent and sustained internal marketing and communication strategy.
