If you’re supposed to treat your Platform as a Product, shouldn't your platform team look like a startup? The product offered by a typical SaaS startup is sold by Sales, marketed by Marketing, and supported by Customer Success. Product engineers enjoy the benefit of entire departments dedicated to getting the product they build into the customer’s hands and making them successful with it. An internal developer platform has its own customers: product engineers. They are discerning and sophisticated and need to be convinced to adopt new tools. They are overloaded and under pressure and need to be supported when things go wrong.
The burden of managing the entire lifecycle of an internal developer platform falls entirely to the platform team. They don’t have the luxury of dedicated departments to influence and support their customers so their purview extends beyond that of a traditional engineering team. In this article, I’ll discuss the composition of platform teams and why they should share qualities of a software startup.
Before becoming the CEO of Reddit, Yishan Wong spent five years at Facebook. One of the projects he led was building internal tools to help product engineers move as fast as possible during record hyperscale. After leaving Facebook, Wong wrote about the importance of internal tools.
Driving the effectiveness of that company and especially its own technology operations is the effectiveness of its tools … writing great tools and continuing to improve and replace them is more important than the next shiny feature”
His post was written 13 years ago, just as the term DevOps was coined. Six years after that, Google published Site Reliability Engineering which popularized SRE. Today, millions of dollars of venture capital are being spent to, yet again, “make fetch happen” as the industry converges on the latest term: Platform Engineering. It is a movement complete with conferences, communities, and provocative campaigns like “DevOps is Dead”. Vendors in this space (like my company, Sym) have struggled to sell into teams with titles, structures and philosophies that vary so much. In an attempt to manifest the ideal market, vendors are foisting a self-serving vision of a consolidated, managed-service-preferring platform team onto developers. Developers are predictably skeptical and fatigued.
It’s not all bad. Like any hype cycle, beyond the peak of inflated expectations, vendor and customer incentives will eventually align at the plateau of productivity. The frustrating part for developers is that, until the cycle plays out, they’ll have to wade through the barrage of platform marketing hype to find the signal in the noise.
In an effort to amplify some signal, let’s return to Manuel Pais’s Platform as a Product presentation. He begins with Evan Bottcher’s definition of a platform:
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product”
Pais expands on ”compelling internal product” by saying that use of the platform should be voluntary, that engineers should not be mandated to use an internal developer platform. Because of this, Pais explains, platform teams must adopt a product mindset to understand the needs of their users and build a compelling platform for them. Because usage is voluntary, they also need to advocate and “market” their tools to drive internal adoption. This is where the scope of responsibilities for a platform team really begins to resemble that of a startup.
Platform Engineering as a Startup as Code
Yishan Wong claims that "your most talented engineers should be working on your tools," but this is too reductive. Finding the right problem to solve and selling the solution internally requires skills beyond pure technical talent. Using skill set as a criteria to staff your platform team may lead to bringing on a Product Manager to help discover the right problems to solve. This is why Thoughtworks recommends applying product management to internal platforms. So does that mean platform teams should have sales and marketing resources too? Rather than relying on raw talent or skill sets to find the right candidates, a better way is to use the following shorthand: look for the entrepreneurs.
Just as founders start with an MVP, early platform efforts should start with a solution that meets the minimum requirements for their team’s stage. That could mean building something as simple as documentation for a deployment process. Skelton and Pais coined a Reis-esque term to capture this approach: Thinnest Viable Platform. It helps avoid the risk of building overly complex solutions that slow developers down, defeating the purpose. It’s too easy for the hype train to lead unsuspecting teams down deep into the trough of disillusionment.
Pais describes different collaboration modes platform engineers should adopt to avoid overbuilding. He explains they should begin by embedding themselves with product teams so they can identify the most immediate customer pain points and find the right solutions to address them. Staying close to the customer helps them be disciplined entrepreneurs. Bill Aulet would be proud!
Once the right solution is found, the focus turns to building a self-service product. The collaboration mode becomes less and less collaborative until the solution can be used autonomously. The job of the platform team is to repeat this loop for new services as the internal platform is built out.
The missing piece in my startup metaphor is the economics that determine the platform team's impact. In her Platform Engineering article, Charity Majors writes:
Developer cycles are the scarcest resource in your company, and you want to spend as many of those as possible on your core product: the crown jewel, the code that makes you a business.
If you square that with Yishan's perspective on talent, you can begin to triangulate on the economics. Platform engineers are multipliers of productivity for the rest of the engineering team. They are able to reduce the number of developer cycles to push the product forward. With each effort they make the company move a little bit faster.
The mechanisms by which platform teams increase velocity are abstractions. This perhaps is the crux of the platform impact. The best internal developer platforms have productivity-increasing abstractions and developer ergonomics that approach the level of successful open source projects. They allow you to get common tasks done quickly and offer reasonable paths to drop down into lower levels of abstraction for exceptional use cases.
A good example was presented by Mathieu Frenette at the last PlatformCon. His team built out helm charts with different levels of abstraction to support various deployment scenarios. At the highest level, they are “recipes” for common types of microservices (e.g. front-end, back-end, api-gateway). They define the components (security, monitoring, health checks) you’d need for a new service while exposing only relevant parameters. This provided a quick and easy “golden path” for typical production services. One layer of abstraction below recipes are “modules” which include components (ingress, cronjob, db) for assembling a custom microservice type. Finally, “extensions” are provided as an escape hatch to support raw helm charts. The result is a fully self-service toolset to get a new service into production. The design sought to maximize reusability (especially for sensitive areas like security) and minimized the cognitive overhead for developers no matter what their deployment needs were.
The right abstractions can also be found in commercial solutions. In fact, this is the ideal default to maximize the percentage of engineering cycles on the product. Build vs buy decisions are usually made by comparing costs of internal efforts with total cost of ownership. But what’s just as important is the specific abstractions provided by the vendor. If the product does not look like what you’d build for yourself internally, the delta in developer productivity needs to be considered. That’s why the most informed buyers are those that have built their own version of a product or have at least scoped the effort against a design. Only those teams will have fully considered which abstractions will be most effective to solve the problems at hand.
A platform team is a startup whose product is abstractions. The better the abstractions the more successful the startup. Along with an entrepreneurial mindset, the ability to deliver effective abstractions might be the most defining skill of a great platform engineering team.
In Charity Majors article, she compared her vision of an observability team to the role of a platform team.
I originally wrote this about observability, but it could just as easily be used to describe platform engineering as a whole. This is the role—being the bridge between other vendors and your own core software. It’s a very high-leverage place to sit.
This might sound self-serving coming from a vendor, but it makes sense. Building anything that is not unique to your company burns developer cycles that could have been spent improving the product. The most effective platform teams will leverage vendors to maximize company velocity.
Perhaps another reason to put your most entrepreneurial engineers on the platform is that they’re the ones most likely to leverage what they’ve learned to start their own devtools company. Eventually, any abstraction that is generally useful will be available as a commercial offering enabling platform engineers to focus only on logic that is unique to their organization.
But no matter the implementation, platform efforts begin with figuring out the most important problems and end with convincing people to use the resulting solution and then making them successful with it, which requires an entrepreneurial mindset. In the middle, the building phase requires implementing the right abstractions which requires experience writing code used by other code writers like APIs, frameworks and libraries. It also requires user empathy inherent in the best entrepreneurs.
Keep in mind that each member of the platform team does not need to have every skill necessary to invent, build, sell and support a software product. Each entrepreneur has their own strengths. But the best platform teams will have these skills on aggregate which is why you should build your platform team as if it were a startup.
