Skip to main content

When to think about developer platforms

Developer platforms start organically. A resourceful engineer sets aside a few hours to create something that makes her and other engineers life easier.

This may happen in time, but it is more than likely that the idea of having a platform comes after experiencing serious pain.

After experiencing serious pain​

Experiencing pain helps making the case for platforms, but at this point, the company has already suffered a loss in some sense. It is good practice to listen to team conversations.

If a problem is discussed in multiple teams independently, or if there is shared knowledge about circumventing a core issue, - like how to handle a third party component - you can benefit from the technical solutions developer platforms offer.

Let me give you two examples:

  • Early in my carrier, I worked for a company that worked with social media data. Relying on third party APIs is always a risk, especially if you use the API of an industry giant like Facebook. I was the in-house expert of their API, knowing all the quirks, and I was also the highest volume API user. Truth is, their API was a black box. We were probing it, and adjusted our usage every time they made changes to their API. Then I was trying to share the latest best practices within the team. But us being a growing company, the API usage came up in every team and we were also at odds using API rate limits. We were way pass the point where we should have introduced a platform solution to the API access problem. Wrapping the third party access in a service would have given us more control and less cognitive load across teams.

  • The other example is not mine, but it is well-documented in the exceptional Pragmatic Engineer blog. It is an interview with Ganesh Srinivasan, who spearheaded a platform effort at Uber. The interview is behind a paywall, and it is about many other topics, but it is interesting to point out that their 6th mobile engineer was already a platform hire.

So, should you start paying attention to platforms when you are about to hire your 6th engineer?

Platform effort doesn’t have a specific team size limit​

Tips are:

  • Listen to team conversations: when a topic or pain is discussed repeatedly in multiple contexts, perhaps, it is time to address the issue with a technical solution, a platform effort.

  • But be aware that processes may yield better results in small teams. Before going for a technical solution, make sure you have depleted the benefits of process adjustments. Waiting on PRs, having too many work items in progress are the typical congestion points of engineering teams. Solving these by process adjustments yield better results faster.

  • Also know that platform efforts are almost always late, so don't be afraid of experimenting.

  • And don't forget: if you start early, or your platform effort had run its course, don't be afraid to abandon it. Reevaluate it periodically. If you made a mistake, correct your course. Don't dwell on it.

It's also worth noting some common pitfalls:

  • Shiny objects. Engineers are keen optimizers, sometimes optimizing towards a local maximum. With good engineering leadership, however, you can provide context and business goals, so they don't lose sight of the big picture.

  • Competing efforts. Seniority is drawn to platform efforts. Without good technical leadership, platform efforts may become political, producing competing efforts. Help them see the big picture.

A note on adopting existing dev platforms​

Sometimes, dev platforms are not grown organically. You may start using ready-made platforms, these Platform as a Service solutions (PaaS) include Heroku or CloudFoundry.

This effort is not organic, but lifts the burden of making many decisions from your shoulders, sometimes at the expense of optionality. What you can be sure of, though, is that you get a polished and coherent experience from the get-go.

There are many flavors of ready-made platforms, and you can decide which tasks you want the platform to do. The below image is from an excellent blog post that sums up your options very well.

Layering of developer platforms

This book is about building developer platforms, therefore, I'm not going to go deeper into *aaS solutions.

What is a platform team​

A platform team is a dedicated team to take care of developer platform efforts. They don't work on customer oriented features, their customers are the product engineers who build customer oriented features.

You may not work for a company that can afford a dedicated team for developer experience and internal tooling. This book, and the tools we recommend, try to help you achieve a similar result with a part-time effort.