Platform Engineering gained a foothold in the DevOps community because it solves:
- Cognitive overload
- Complexity
- Burnout
Gartner put Platform Engineering in its ‘Top 10 Strategic Technology Trends for 2023’.
You can use our decision flow to get a positive result from Platform Engineering. The guide ensures you have the foundations to create a team to build an internal developer platform (IDP). We provide alternative ideas when there are better solutions than Platform Engineering.
This will help you avoid common Platform Engineering anti-patterns.
Platform Engineering helps you scale
The quick check for Platform Engineering is to look for signs of scaling pain. An internal development platform (IDP) is an option if you see these 4 signals:
- You increased the number of developers and development teams
- The developers are responsible for building and running their software
- There’s a high level of operational complexity
- Developers become overloaded and can’t spend enough time on feature development
Every team is different. Complexity and overload depend on the skills and experience available to each team. Some teams will easily follow the ‘you build it, you run it’ pattern, while others will struggle.
If you found the signs of scaling pain, proceed to the Platform Engineering decision flow.
When you should use Platform Engineering
The right foundations will help you succeed with Platform Engineering. A DevOps approach is crucial. You need metrics to ensure the IDP is helping, not hindering, your development teams. You need to show developers the value of the platform. You must also convince stakeholders to continue their investment.
In Beyond Boredom and Anxiety, Mihaly Csikszentmihalyi describes a model for work satisfaction. The model needs a balance between opportunity and capability. You get bored or anxious when you can’t use your skills, but a challenge that exceeds your skill level can cause worry or anxiety.
When the balance is correct, you achieve a flow state.
Enjoyment appears at the boundary between boredom and anxiety, when the challenges are just balanced with a person’s capacity to act. - Mihaly Csikszentmihalyi
By introducing an IDP, you impact the challenges developers face.
You create a more successful IDP if you understand this balance.
The decision tree helps you decide if Platform Engineering is the right solution. It also ensures some essential foundations are in place before building an IDP. In some cases, it leads to a different solution.
Follow the flow from top to bottom to get the best outcome.
1. A view of developer satisfaction
Developer satisfaction predicts software delivery performance. You should measure satisfaction and enjoyment whether you use Platform Engineering or not.
Measuring developer satisfaction before you introduce an IDP provides a crucial baseline. You can then track the impact of the platform over time.
Organizations that don’t recognize the importance of developer satisfaction lose their best developers. This isn’t a fluffy soft metric. It surfaces cultural problems and cognitive overload while predicting business costs and outcomes.
Can you track developer satisfaction?
Yes
Continue to overload and burnout.
No
Improve your ability to assess developer satisfaction before adopting Platform Engineering. Research proves the relationship between job satisfaction and performance. You need to show the impact Platform Engineering has on developer satisfaction to prove that you’re getting one of the intended benefits.
2. Overload and burnout
A key reason to adopt Platform Engineering is that the operations burden overloads the development team. This is more likely to happen with “you build it, you run it” styles of DevOps, but not all teams struggle to run their software in Production.
If your developers can productively and sustainably run their software, an IDP isn’t solving a problem. You may end up with low adoption rates or dissatisfied platform users.
Are your developers overloaded or experiencing burnout?
Yes
If developers are suffering, continue to cognitive overload.
No
Head to software delivery metrics.
3. Software delivery metrics
You may already use DORA metrics in your software delivery process. Platform Engineering can improve these measures both directly and indirectly. Helping development teams track DORA metrics means you can show the IDP’s impact.
You can increase your internal market share by showing how the IDP helps improve these metrics.
The metrics you use in your DevOps journey set the direction of efforts like Platform Engineering. This helps the organization understand the impact of changes they make to their funding. That’s why having metrics in place before you build an IDP is crucial.
Can you track software delivery metrics?
Yes
If you have metrics in place, go to performance problems.
No
You should fill the gap by tracking software and operational performance. You can’t tell if your IDP works without these and the developer satisfaction metrics.
4. Performance problems
A change in performance may signal that you need an IDP. A sign of operational burden is performance hitting a plateau or dropping.
When metrics send this warning signal, it’s time to check for cognitive overload. You can also collect specific examples of the problems developers face. These are essential inputs for your IDP product development process.
Have you reached a plateau or found a drop in performance?
Yes
Continue to cognitive overload.
No
An IDP offers few benefits if a team delivers frequent, high-quality software deployments and manages their software in Production. Focus instead on the existing continuous improvement process.
5. Cognitive overload
In the January 1988 edition of Educational Psychology Review, John Sweller, Jeroen van Merriënboer, and Fred Paas described cognitive load theory in the context of instructional design.
Compared to the seemingly infinite ability of the brain to store information, working memory has limits. Working memory can hold about 7 chunks of information. Fewer if you need some capacity to process it.
New information and existing concepts combine to create new schemas to store in your long-term memory. This process can take place in working memory, or it can happen through practice.
Mastery happens when you create a large set of pre-saved concepts. Chess grand-masters don’t out-think their opponents; they access schemas from their long-term memory.
Successful DevOps teams have a library of operations plays. Overload happens when DevOps teams lack this institutional knowledge. It can happen when:
- Developers vastly outnumber the operations experts
- An organization opts for ‘you build it, you run it’ in teams with low operations experience
- Development teams all head in different directions, which causes a lack of shared knowledge and reduces collaboration
Developers with less operational experience can become overwhelmed. They need to think through each ops move to build, deploy, and operate their software.
It can be hard to determine whether cognitive overload causes stress or burnout. Development teams can show the same symptoms due to:
- Pathological management
- Bureaucratic processes
- When they lack a constancy of purpose.
Read more about this in our DevOps culture section.
Does cognitive overload cause the problem?
Yes
If you think it’s cognitive overload, go to necessary complexity.
No
If you’re not sure if cognitive overload caused the problem, use your trusty retrospective process to discover causes and find solutions.
If you’re still struggling to resolve the overload after several retrospectives, you could run a Platform Engineering trial to see if it helps. Make sure you have the appropriate metrics in place to assess the effectiveness of Platform Engineering.
6. Necessary complexity
There’s an amount of necessary complexity when solving a challenging problem with software. You don’t need to protect developers from necessary complexity. It’s a challenge they’re trained to overcome.
Finding a simple way to provide a complex feature is a highly satisfying pursuit.
But, many kinds of complexity aren’t necessary. When each team makes local decisions, you can complicate your organization’s technical landscape. Many languages and frameworks, and different Continuous Delivery tools and infrastructure choices, are hard to manage.
An acid test of this problem is to see how different systems log error messages. Do they all call the same API to store errors, or do they all have their own way of writing these messages?
Some variation may be necessary. It’s hard to think of a reason why you’d handle errors in a different way for every application. A common cause of fragmentation is when teams choose a new direction without taking time to update existing code.
Developers introduced necessary complexity with strong communication and deliberate choice. Communications failure and ad-hoc or unilateral decision-making cause accidental complexity.
Is the complexity that causes the cognitive overload necessary?
Yes
If the complexity is necessary, head to the section on teams.
No
If the complexity isn’t critical to your business, it’s time to consider simplification. You can introduce cross-team communities of practice to align decisions and reduce fragmentation. You can collectively increase your skills alongside these choices. This makes it easier to find someone in the organization to help when there’s a problem.
When cross-team groups can’t agree on a way forward, you may feel tempted to introduce Platform Engineering to resolve the conflict. This is the worst situation for a new platform team to face. They won’t find it easier to choose options for their golden pathways when there’s conflict amongst developers.
You’ll need to tackle the problem from a people and culture perspective before you can solve the technical issues.
7. Teams
A rule of thumb is that Platform Engineering is premature if you have fewer than 5 stream-aligned teams.
Instead, encourage teams to collaborate and reduce chaos. For example, reduce the number of ways you collect telemetry or consolidate tools that do the same thing.
You might need more skills to start a cross-team effort to solve these problems. Platform Engineering may free up people who do have the necessary skills. This lets them make more impact.
If you have 5 or more teams and have passed all the other signposts, Platform Engineering is likely a good choice.
How many developer teams do you have?
Fewer than 5
Read the skill shortage section.
5 or more
It’s time to consider Platform Engineering to create an IDP. Golden paths help reduce the technical spread associated with scaling a development organization. Read on to find out how to get the benefits of Platform Engineering.
8. Skill shortage
On a small team, it’s common for 1 person to handle build, deployment, and operations tasks. In these cases, the deployment pipeline isn’t widely understood and depends on an individual’s knowledge to maintain. There’s often just enough design to get the team up and running.
As you scale up, this solution is no longer enough. Fire-fighting build, deployment, and operational issues hold developers back. You may need more people with experience to give each team ops knowledge.
In these cases, there’s value in specialists spending time to build higher-quality solutions than the cobbled-together pathways.
Do you have a shortage of build, deploy, and ops skills?
Yes
Platform Engineering lets you create a team concentrated with specialist skills. It embeds the skills into a platform rather than using them to service a request queue. Developers then self-serve using the platform rather than asking others to do the tasks.
A platform team lets you maximize the value of specialized knowledge.
See more information on how to get the benefits of Platform Engineering.
No
It may be better to encourage cross-team collaboration to align decisions and reduce tech fragmentation.
Different team types
Here are some examples of everyday situations where you can use a different team topology to solve a problem in your organization. You can also learn more by reading the Team Topologies book in our DevOps reading list.
Getting a new feature to market
When you need to get a new feature to market, you should use a stream-aligned team. The team focuses on creating a competitive, marketable solution for a specific business segment. They might change direction several times while searching for something valuable to customers.
Integrating with specialist hardware
When you need to use specialist technology as part of your product, like a new hardware device, you should use a complicated subsystem team.
This team builds deep knowledge and provides an easy-to-use wrapper for stream-aligned developers to use. The complicated subsystem team holds the expertise and manages complexity.
Introducing a new capability
If you need to introduce a new capability, like deployment automation, you can use an enabling team. Enabling teams don’t do the work for the stream-aligned team or provide a solution as a service. Instead, they develop an understanding of the capability and work to introduce it into the stream-aligned team.
Steam-aligned teams own the capability once they’ve learned the skills. Enabling teams have more scope to identify missing capabilities and experiment to find the right way to introduce them.
The 8 decisions for Platform Engineering
This cheat sheet summarizes the 8 steps that help you decide if to use Platform Engineering.
Conclusion
Platform Engineering is a common solution to scaling and complexity problems in DevOps organizations. You’ll be more successful if you can measure the impact of an IDP. Sometimes Platform Engineering isn’t the right move.
High-performing DevOps organizations are more likely to use Platform Engineering than those in lower-performance categories. However, more than half of high performers aren’t using Platform Engineering. If you try to use an IDP without finding the right signals, the effort will fail to deliver benefits.
Platform Engineering can boost software delivery and operational performance in the right situation. It can create an environment for developers to do their best work.
Further reading
- Beyond Boredom and Anxiety by Mihaly Csikszentmihalyi (1975)
- Team Topologies by Matthew Skelton and Manuel Pais (2019)
Help us continuously improve
Please let us know if you have any feedback about this page.
