What is a platform team?
What is a platform team? Who are your customers? And how do you define a mission and vision for this team?
I work in a successful modern SaaS company. The primary focus of our business is our customers. They drive our revenue, which fuels our investments, which in turn fuels our product feature growth. Product features are created by the product team. The engineers write code, build it, test it and push it into production where customers can use it. So who or what is a platform in this? And what is a platform team?
In my view there are two platforms. The first platform is the developers and the tools, processes, and frameworks they use to write, build, test and deploy their code. These tools are a platform, and the experience they have with using these tools, is by extension also the platform. We call this Developer Experience.
Like a company that builds ships we start with raw materials like steel, but we need the tools — the cranes, lorries, the bolts, the welding torches in order to make the ship. I know nothing about ship building so this analogy will be limited! But you can imagine in a shipyard, you want the tools the builders are using to be effective, easy, efficient and safe to use. And we want the processes of using these tools also to be safe as well. You also want to prevent defects through best practices (making sure the quality of the riveting and welding is constantly reviewed) and you want to find and fix detects early, before the entire ship sets sail (making sure the right rivets were used before the hull is put under stress at sea). In software too, all of the tools used and the quality of their use is a ‘platform’. The ‘customers’ are the developers.
The second platform is the infrastructure that the code runs on. In our ship analogy we have launched and sailed the high seas as a luxury cruise ship. Passengers are on board and enjoying the entertainment and accommodation. The platform is still there — the hull of the ship, the propellers, and the giant engines that power everything on the ship. This platform supports the passengers, and takes them to their destinations, but they don’t think about it. The engines can’t be heard on the upper decks. They don’t know if the engines are efficient and running well. They don’t think about the backup engines should one fail. And they don’t think about the crew of mechanics, engineers and electricians that keep everything working. And in fairness, neither should they, they should be enjoying their cruise.
In software, the same is true for the production platform that the code runs on. Customers do not, and should not have to think about it. But just like in the lower decks of a ship, platform engineers work continuously to ensure the infrastructure is reliable, scalable, available. They also ensure that it is observable (just like all the telemetry and dashboards of a diesel engine which propels the ship and powers all the ships electricity and hydraulics). This platform, we call Infrastructure Engineering.
Who are the customers of our platform?
The customers of developer experience are the software engineers who use the developer tooling. You can measure their satisfaction through surveys, in-person conversations, office hours (consultancy sessions), the adoption rates of the tools we provide them, and sometimes through instrumentation of the tools. In a future article, we will go deeper into more advanced ways of measuring the benefits of developer experience, beyond the satisfaction of the engineers. The customers of the platform infrastructure are the end-users of the application who rely on this foundation to be always available, performant and robust. But you can’t directly measure their satisfaction with the platform. Like water, electricity (and broadband if you were born this century!), the infrastructure platform is assumed to exist and work all the time. However you can measure their dissatisfaction very easily when the platform ceases to work or has a performance issue which causes them to be delayed or stops them from what they want to do. Past failures can also be used to quantify the benefits of a highly available platform, which we will also discuss in a future article.
Mission and Vision for Platform Teams
In the software industry it is important to motivate, excite and give purpose to the work of engineers and engineering managers. Otherwise they will work somewhere else, because there are plenty of opportunities in this industry. A mission and vision statement for a team is a good way of creating unity and purpose for a team over a long period. The mission should be a statement of what you are constantly trying to improve every day at work. The vision is the destination you are trying to get to, a sort of utopia where everything is good and everything you wanted is achieved. Day to day or quarter to quarter, we can refer to these and they help us guide the direction of technical decisions, or help us to select and prioritize projects for our roadmap. A good vision can also simply inspire us to keep going through adversity, to shoot for the moon.
I find mission and vision statements most important when the team is not close to end users and therefore not able to directly influence the success of the product and resulting success of revenue. For those teams who are lucky to be “close to the money”, success of their work is easily quantified and easily understood: feature adoption, driving sales, driving NPS, and so on.
But given the ‘hidden’ nature of the platform, how do you define the mission and vision of the people working on developer tooling and production infrastructure? In a previous company my team and I were responsible for a platform which monitors a very large scale computer network. In the early days our leadership told us that our job was to keep network engineers happy by giving them the ability to create alarm configurations which they could act upon if they arose. The problem was that this was customer centric to our internal colleagues only, and not a very inspiring or motivating direction for my very talented team. We came to see our true customers as the end-users of the network. We rarely heard from them, unless an alarm configuration was incorrect and missed a problem which caused their applications to fail. But we decided that these end users, and not our internal colleagues, were the more important customers of our platform. So with a view to a more inspiring and ambitious responsibility, we came up with this mission and vision:
Our mission is to detect anomalies before they become failures which affect customers.
Our vision is that all failures are pre-emptively detected and remediated without manual intervention.
As an aside, we made great progress towards our vision and had some really nice wins on behalf of our customers.
When I came into my current company, the developer experience and infrastructure teams were delivering some nice work, but we were lacking a mission and vision statement for this combined platform. Each of the teams came up with some nice mission and vision statements, but we also needed a combined mission and vision. Our first attempt was something like this:
Our mission is to ensure our application is built and operated with excellence
Our vision is to have the best in class engineering org in 2023
Actually the mission statement was longer and the vision was also a longer description of the platform at the end of 2023, and how we envisaged our team a key core reason why we achieved our company BHAG. It was good but not as succinct as we would have liked. So as an extra, we created a tagline for all of this. We wanted a phrase that fitted on a t-shirt. We came up with “Driving Engineering Excellence”, and made some very nice t-shirts with this phrase and our team name and logo.
Mission Accomplished?
Looking back, these missions and vision statements served us well, especially when we formed and re-booted teams, and we had a mix of new and tenured folk who needed to align on a purpose. They gave us a focus and identity (and much sought after t-shirts) for more than a year. They helped us prioritise projects, and in some cases helped us to define the ownership of projects between two teas. But over time the mission and vision faded from memory. The now aligned teams grew in size and took on more areas of ownership, sometimes without us refering back to the mission statement. When you are scaling up like this, teams are busy getting on with their well understood projects. There are a lot of moving parts as the team settles into their ownership of day to day work. It can be a luxury to find time to revisit and refresh the mission and vision which is usually best done in an offsite with everyone together, and of course that wasn’t always possible. We also found that the mission and vision statements were not detailed enough to resonate with our new colleagues and higher company leadership. The phrasing was just a little too condensed, and didn’t describe what we are actually aiming for in tangible detail, like for example a product release note. In other words our future projects and deliverables needed to be expressed in other ways. What we did instead was a ‘working backwards’ exercise. We wrote a detailed description of the daily life of an engineer in 2024. Without getting into the details here, every sentence in that document was a future project for our team to deliver. I recommend this exercise to everyone who has a platform team that is delivering a broad range of valuable tools, processes and frameworks, and may find it hard to describe in a mission and vision statement.
Responsibilities of Tomorrow
Mission and Vision statements can ‘fall to earth’ and not land well. Most recently, we have faced a challenge in expressing “what we do” to a large number of new colleagues who have joined as part of a major recruitment drive in our product engineering teams. While the mission and vision of our teams still resonates with us, they are too abstract to convey to new colleagues who are delivering a very major feature set this year. We just want them to know how we can help them. This situation is common — we have a major company priority to assist with, and we don’t have the luxury of time to work on an update to our mission and vision, or to revise our ‘2024’ working backwards document. So instead I have found it useful to focus on expressing our responsibilities. In as few words as possible, this is the first line in our current roadmap document:
We are responsible for driving efficiencies in engineering, and protecting the availability of the application.
This short sentence expresses the combined responsibilities of developer experience and infrastructure engineering. To make it real, we have started to explicitly quantify how our platform deliverables improve efficiencies and availability. In a future article I will explain how this is done.
I hope this article has explained what a platform is and what a platform team does. I’ve given you some insight into how the platform benefits customers, and how you can form a mission and vision for the platform team. In the next article, I will introduce a path to uncover and measure the beneficial impact and deliverables of a platform team.
