Notes from building internal developer platform — Part 2: Giving developers super power

Photo by Ryan Quintal on Unsplash

So, we’ve mentioned platform engineering, albeit briefly. And truth be told, it’s a wide domain and building it would be very contextual for every organization, though the goal could be a uniform one: improving developer productivity. So, how can you ensure that a platform can fully benefits developers who are its main users? In order to answer that, let’s step back and see developers’ workflow.

I propose a simple model to represent developer activity. This consists of 5 repeatable tasks that developers do on a daily basis

Developer Activity Model

These 5 steps represents different domains and clearly depict how vast is the area touched by developers. And you could already probably started imagining that when we talk about “you build it, you own it” all these 5 areas should be touched by developers.

Now, here comes the tricky part. I’d argue that the key working area for a developer, and the main reason that a developer is hired by an organization is to do point number 2, and to some extent 3. The rest of the model is probably hard to be recognized by person with no experience in writing code, thus making it hard to reason about, even though these are valid points. But we can use this notion to reason about why we build developer platform.

Let’s get back to the original goal of improving developer productivity. Now, since we’ve acknowledged that the full value of a developer is realized in step 2 and 3, I’d argue that these are the main productive time of a developer. Thus, if you want to improve developer productivity, starting by reducing the time spent by developers to do step 1, 4, and 5, can be a great starting point. And yes, that’s where our platform can play fundamental part.

Acknowledging that each of these 5 points is huge domain on its own we can start the journey of building our platform by tackling one problem first, before expanding it to different direction. For example, let’s tackle point 4 of the model above: integrate. Problem wise, this could lead to 2 different problems:

As you can see, 2 different problem statements that could result in many kind of solutions. For example:

These are probable solutions to different problem statements. And you can see that the platform could end up in many different places, depending on our direction.

As you can see, we start to formulate platform as an abstraction of the infrastructure. Our aim, as the platform builder, is clear: to represent part of the infrastructure and make it friendlier for developers, so they can fully own the operation part of their code. But you may also notice that even after we outlined the domain where platform can play its part, the depth of the domain requires us to think carefully where we want to direct the development of the platform itself.

Product management to the rescue. More on that, on part 3 of the series. But if you missed part 1 of the series, do check it out.



Currently working as product manager for cloud infra product. Cyclist + Gamer + Metalhead. Also, proud dad and husband.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adityo Pratomo

Currently working as product manager for cloud infra product. Cyclist + Gamer + Metalhead. Also, proud dad and husband.