Platform engineering anti-pattern: seeing user support as a distraction
For a long time, teams that do infrastructure or platform work have often faced a perceived fundamental conflict: so-called planned vs unplanned work, specifically support. In the transition to effective platform engineering, viewing this as a distraction becomes an anti-pattern.
Unplanned work?
This is different from the sort of unplanned work that arises from poor coordination. No, this is the issue where teams are trying to build things and feel like they are not making progress due to fielding support issues from users. Often-times, it feels like the support issues are things they are trying to fix but may not have time to make progress.
The disconnect
There is a fundamental disconnect here that comes into play between the why of the work and the what of the work.
Platform engineering teams are a fundamentally different way of working from IT/automation or DevOps teams. In the latter, teams are responsible for the systems that other people depend on or supporting those systems for other users, i.e., the build system, deployment system, runtime, etc. In this scenario, these teams are effectively trying to build to requirements for the system and ease their own work with the things that they build.
Platform engineering, on the other hand, is building things for others, i.e., customers. The platform engineering teams build based on the needs and requirements of their users and not necessarily automating their own work.
Changing the why
If you are building capabilities for others, then that changes the purpose, or the "why", of the things that you build. For instance, in prior times, an ops team would need to be able to have logging in order to diagnose the state of the system. Therefore, they would build a logging platform for their own use and make it available to developers. For a platform team, the need is from the users of the platform to be able to effectively support their own apps deployed on top of the platform. For this they need tools including logging that allow them to do this for themselves.
If the need goes from "we need logging in order to support production and/or operations" to "our users need the tools to do the support for production for their apps," then a fundamental shift in operating model is required. So rather than being a distraction, it is an indication of how successfully you are serving your customers. If you are handling a lot of support requests, then your product is likely not meeting the needs of users, and you need to rethink what you are building.
Just trying to work
It is important to note that users are trying to get their own job done and are not asking for help in order to bother the team. It's that the tools that they're trying to use are insufficient, and the team needs to pay attention to these signals from users and potentially alter what they are actually building and working on. The concept of what to build itself changes, and you need to move on from building components and infrastructure for the same team. Instead you begin to behave like a product organization, identifying needs of users and how they do their own work and figuring out how to enable them to be more effective.
Different emphasis for support
So, the platform team that finds itself doing a lot of support needs to evaluate why they are doing that. What is it about the products that they have put in front of customers and the way that they have put them in front of customers that are not working out the way they should? An ideal platform is as self-service as possible and allows other parties that use the platform to get their own work done and stay in a state of flow. If the platform isn't fulfilling this due to documentation issues, bugs or simply not being fit for purpose, these are critical things to fix in order to be an enabler of other parts of the organization.
Making the shift
How do you change this mindset and take practical steps to work in new ways? There are contributions to be made at different levels from the CIO/CTO, VP of Engineering to the Platform Engineering tech lead(s) to enable the platform team to approach customer support differently.
CIO/CTO
At the CIO/CTO level, there must be a statement on how all parties should be working together. Ensuring that there is a collaborative environment and a stable definition of how teams depend on one another with minimized coupling and avoiding tossing work over the wall. An example of this would be Jeff Bezos' mandate for well defined APIs to be used between teams.
VP Engineering
At the VP Engineering level, there needs to be clear guidance on what the expected capabilities and developer experience are on the platform. At the same time, there needs to be equally clear expectations of what the development teams are responsible for that the platform team should not be doing. This clarity allows teams to set clear expectations for each other and reinforces the the working style set by the CIO/CTO.
Platform Team
At the platform engineering team level, the team lead is able to use modeling behavior and set expectations for how the flow of work goes through the team. With the tone set from leadership, the lead can change the emphasis of support to one of a feedback loop from customers that impacts the priorities of the team. This may sound like a bad outcome since it could constantly pull you in the direction of whatever problem users are facing. At the same time, it opens up the chance to find out what users are trying to accomplish and modify systems or build new ones to make them self-sufficient. This is bolstered by the fact that a bi-directional dialog is expected between the teams where they collaborate on solutions rather than making demands on each other that might result in systems that might be either difficult to support or difficult to use.
A combined effect
With consistent guidance from leadership and a change in perspective on the mission of the team, the nature of support can be changed. It can be turned into something that creates a generative environment and improves the platform to the point that users do not need as much direct support.
Summary
So, in summary, the platform engineering team needs to look at support not as a distraction but as an important signal. This signal becomes part of the feedback loop on their performance as a platform team and the owner of a product other people depend on. Leadership must support this view of work and the platform team should seize the opportunity to build products that satisfy user needs.
If you need help getting your platform team and dev teams aligned, get in touch!
