Better developer platforms are the key to better digital products
However, despite all the benefits, product-thinking is often lacking substance. This is especially true for developer platforms. While the notion of “developer experience“–how development teams interact with their tools and platforms–is one that every organization needs to take seriously, it’s not enough to simply implement cross-functional teams (as important as that is) or go and purchase a platform on the back of positive noises from the wider software industry. These approaches may bring short-term benefits, but they are not sustainable over the long-term. If done incorrectly, what was meant to empower can become unreachable.
Developer platforms do indeed require a product approach. This should be a commitment to understanding the context of development work, and a willingness to adapt and evolve that context (both organizational and technical) over time. This requires a greater awareness of the work developers do and their role within an organization. It is impossible to build a developer platform that is effective while still assuming that technical teams are just a resource that 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 entail?
At one level, it requires you to discard any assumptions about developers or how they might work. We must start from the bottom and understand collaboration, tools, processes, skills, culture.
At Thoughtworks we advocate for a technique we call path-to-production mapping. This is a simple idea, where teams will draw the steps needed to make a change, and then push it to production. However, we rarely see clients doing it. This leaves developers with unresolved issues and inefficiencies. It helps teams understand how things work. It forces everyone to work together at all levels to find out what developers do and what they need in order to speed up the pace to value. This knowledge is invaluable for future platform development.
At another level, we need to clearly and publicly acknowledge the larger goals and drivers for the organization. Also, what are the opportunities for development teams to add value? And how can they add value faster?
This will vary depending on the type of organization. It is risky to have a preconceived notion of what a platform should look like (i.e. what features it should have). 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 platform for a particular purpose is an inflexible antipattern for another. A good platform implements safeguards that allow developers focus on what they do best: writing code and shipping it. It should reduce team cognitive load, minimizing the risk of error and maximizing the time developers can spend on value-adding work. Product owners are the best at managing or mediating the needs of software developers and commercial demands within an organization. This is an important role that is often overlooked. The product owner, while not strictly a business analyst or a developer role, is essential in ensuring that developers are empowered as well as delivering value to 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 is important, but we must also be aware of more than the platform’s nuts and bolts. We need to ensure that the platform’s value can be realized. This can only be achieved with a cohesive and sustained internal marketing strategy and communication strategy.
Again, what this looks like is contextual, driven by things like how an organization is composed, ways of working, and modes of collaboration. There is no one way to approach this for different sizes or types of organizations. It would be wrong to consider it as a single model.
In the end, good (internal marketing) is about making sure customers know the value of the platform and how they can achieve it. Sometimes it can be tempting to think that if a platform is viewed as a product, then its path to value should be seamless. This is not always true. Even the best platform products must be promoted to their users. Intuitiveness is a good guiding principle when it comes to building a platform product, but it’s a principle that should come with a dose of humility–an awareness that it will never be perfectly intuitive.
There is a caveat. Internal marketing should not be a top-down directive. It should facilitate and enable dialogue between the people who drive a platform and those who use it. Marketers should encourage users to ask questions, request new features and raise concerns.
Evolution and change
One of the challenges of developer platforms is that they shouldn’t be viewed as things that can just be built, launched, and then forgotten about; they require constant evolution and maintenance. This can be achieved by using a thoughtful communication strategy. However, it is also important to consider how the platform will evolve with the organization and new technologies.
A technique included for the first time in Volume 27 of our Technology Radar–incremental developer platforms–can be particularly useful as a way of responding to these multifaceted demands. Such an approach not only ensures alignment with the specific needs of users, but also prevents the platform from being derailed by over-ambition–something that typically stems from a preconceived vision of what the platform should look like. Industry is well aware of the benefits of an incremental approach to software development. Why not apply this thinking to internal tooling and platforms?
It’s time to acknowledge the experience of building software
Developer platforms are far from the most visible or eye-catching part of the technology industry. However, the way they are approached often reflects how software development is valued and respected within an organization. If software building is essential to delivering value, then we must also value the experience of doing so.
This content was produced by Insights, the custom content arm of MIT Technology Review. It was not written by the editorial staff of MIT Technology Review.
I’m a journalist who specializes in investigative reporting and writing. I have written for the New York Times and other publications.
