The move to thinking about “products” instead of “projects” is to be welcomed when it comes to developer tooling. At a time when hiring and retaining talent — technical or otherwise — is one of the biggest concerns for organizations, paying attention to the needs of internal customers can only be a good thing. 

However, for all the benefits of this turn to product-thinking, too often it can lack substance. This is particularly problematic when it comes to 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 might bring short-term benefits but their value is limited and potentially damaging over a long-term period. Done incorrectly, what was intended as empowering can become inflexible. 

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 (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, which leaves 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, itt 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 just 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 load, minimizing 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. 

Again, what this looks like is contextual, driven by things like how an organization is composed, ways of working and modes of collaboration. There’s no single model of how different types or sizes of organization should go about this and it would be wrong to think about things in terms of an “enterprise way of doing things” or a “startup way of doing things.” However, some activities and artifacts that could be implemented — at the appropriate level of scale — include documentation (perhaps even a lightweight wiki), training sessions and clear communication channels to showcase updates and changes.

Ultimately, good (internal) marketing is about ensuring customers are aware of the value the platform is meant to deliver, and how they can realize that value. Sometimes it’s tempting to think that if we’re approaching a platform as a product, its path to value should be seamless, as if any friction is indicative of a problem with the product. This is rarely the case — even the most well-considered platform products need to be marketed 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 an important caveat: internal marketing shouldn’t be delivered as a top-down edict. Instead, it needs to be something that facilitates and enables dialogue between those driving a platform and those using it. Marketing should initiate dialogue, encouraging users to ask questions, request new features and raise issues.

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. The feedback loops initiated by a considered communication strategy will help here, but it’s also important to consider the ways the platform evolves alongside the organization and emerging technologies.  

A technique included for the first time on 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, it 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. The virtues of an incremental approach to software is widely accepted by the industry — so why don’t we bring this thinking to the way we think about platforms and internal tooling?

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. Yet the way they are approached often reflects the extent to which software development is respected and valued within an organization. If building software really is key to delivering value then we also need to value the experience of doing it.

Resource : https://www.thoughtworks.com/en-in/insights/blog/devops/better-developer-platforms-key-better-digital-products