Platform engineering creates user-centric capabilities that enable teams to achieve their business outcomes faster than ever before. At Equal Experts, we’ve been doing platform engineering for over a decade, and we know it can be an effective solution to many scaling problems.

Unfortunately, it’s easy to get platform engineering wrong. In this series, I’m covering some of its pitfalls. First, it was the power tools problem, then the technology anarchy problem, and today it’s the ticketing hell problem. 

Fewer handoffs, more speed

A platform engineering team aims to accelerate technology outcomes for all their teams, so they can deliver business outcomes faster than ever. I’ve explained before how those technology outcomes map onto the DORA metrics:

• Speed (deploy lead time and deploy frequency)
• Quality (unplanned tech work)
• Reliability (deploy fail rate and time to restore)

At Equal Experts, we define engineering excellence as achieving high standards in all these metrics. One of the main blockers to excellence is handoffs. They occur when a team depends on another to complete a task, such as needing DBAs for schema creation, change managers for approvals, or your operations team for deployments. If you have handoffs in platform engineering, your teams will be stuck in ticketing hell.

The nightmare of ticketing hell

Ticket-driven platform capabilities can seem appealing. Your platform team can reuse existing workflows, and teams can simply file a ticket when they need something. However, this approach causes delays, as tasks are stuck in different queues e.g. triage, priorized, blocked. A task to create, deploy, or restart a service might take minutes to complete, but the queue beforehand can take days or weeks.

You can measure a platform capability in internal customer value, internal customer costs, and platform costs. Here’s a v1 platform with ticket-driven capabilities, and it’s a long way from our high value, low cost ideal:

• Internal customer value is low. Technology outcomes can’t be significantly accelerated for teams, because there are so many handoffs and queue delays
• Internal customer cost is low. Fortunately, teams don’t have much unplanned tech work, because everything is handled by the platform team
• Platform costs are high. The platform team has to manage a lot of incoming tickets from teams, on top of actual build and run work for the platform

This pitfall happens when your organization has a long-term, ITIL-driven culture of centralized workflow management. Platform team workload will grow uncontrollably as you increase teams and platform capabilities. Ticket queues, conflicting priorities, and strained relationships will damage speed, quality, and reliability for your teams. 

For example, at a Dutch bank we saw a new employee wait 11 weeks for access to code repositories, because their request was stuck in the platform team’s queue. The employee felt unproductive, but they were reassured by their team it was standard practice.

And at an Australian telco, any deployment to any environment requires a platform ticket, which creates a combinatorial explosion. The platform team can’t keep up with demand, which results in blocked deployments, prioritization clashes, and platform engineer burnout. 

Embracing the power of self-service 

The wrong answer to ticketing hell is to embed platform engineers into teams, as it’s unsustainable and creates its own problems. The right answer is to standardize on self-service workflows with automated guard rails and audit trails. Here’s how your platform team can get started:

1. Measure the end-to-end time for all v1 ticket workflows.
2. Prioritize a task that’s frequently used, and frequently slow for teams.
3. Create a v2 self-service, fully automated pipeline that consistently performs the task to a high standard, and logs an entry in an audit trail afterwards.
4. Visualize the audit trail in a platform portal, so teams and their stakeholders can understand the impact of their actions on user behaviors.
5. Migrate teams from the v1 workflow to the v2 solution for a single task, delete the v1 workflow.
6. Move onto the next priority workflow.

Here’s v2 of that imaginary platform. There’s a much higher internal customer value for teams when they’re able to move quickly and meet business demand. Your platform engineering efforts can be shown to have accelerated outcomes.

Conclusion

Ticketing hell can cripple your platform engineering efforts by creating bottlenecks and frustration. By transitioning to self-service capabilities, you can unlock higher internal customer value and empower your teams to deliver business outcomes

I’m going to be sharing more platform engineering insights in my talk “Three ways you’re screwing up platform engineering and how to fix it” at the Enterprise Technology Leadership Summit Las Vegas on 20 August 2024. If you’re attending, I’d love to connect and discuss platform engineering challenges and solutions.

I speak with customers and consultants across the Equal Experts network, to help our customers understand how to speed up innovation and reduce total cost of ownership at scale. Sometimes, our customers refer to this broadly as ‘scaling agile delivery’. 

We’ve helped a lot of organizations to scale agile delivery successfully. Forrester Research recently published a Total Economic Impact (TEI) study that shows partnering with Equal Experts achieved a 123% ROI and 60% reduction in time to market for:

• A food franchise scaleup: 10 teams, 40 workloads
• A consulting organization: 10 teams, 100 workloads
• A high end retailer: 40 teams, 75 workloads
• A government department: 80 teams, 900 workloads

It’s hard to implement cross-functional, outcome-oriented teams delivering complementary product capabilities. The good news is success leads to a faster time to market, better quality, reduced risks, lower costs, and better user outcomes which improve your bottom line. My colleague Jon Ayre recently talked about how to iteratively scale agile. I’ll take that a step further. Here are four ways to scale up your delivery capabilities:

• Set teams up to have alignment with autonomy
• Introduce a You Build It You Run It operating model
• Focus on frictionless onboarding
• Create paved roads to allow teams to focus on delivering business value.

Create alignment with autonomy

Teams make faster and better decisions when they understand the intent, purpose, and constraints behind their work, and when they can act for themselves. Teams need to be aligned to deliver on strategy and execution, and autonomous to deliver outcomes without handoffs. 

The problem is organizations often implement alignment as command and control. Teams are forced to treat alignment and autonomy as opposites, and they become stuck in one of two scenarios:

• Autocracy. Teams have high alignment but low autonomy. They incur delays because they can’t make decisions. At a media conglomerate, I saw 8 teams who constantly had to wait for 2 shared product managers to make all their decisions for them.
• Anarchy. Teams have high autonomy but low alignment. They’re unaware if they’re making good decisions or not. At an insurer, I saw 10 teams spending ~80% of their time on unplanned BAU work, because they’d implemented 10 different services with 10 different AWS runtimes. 

The solution is to replace command and control with contextual alignment, and give teams the freedom to make good decisions in aligned autonomy. See why you need alignment with autonomy at scale.

Adopt You Build It You Run It

Teams achieve higher throughput, greater reliability, and a continuous learning culture when they build and run their own workloads. Teams need to become accountable for reliability as well as functionality, and focussed on outcomes rather than outputs.

The problem is organizational inertia towards using a central operations team to run differentiated digital services. It’s not possible to achieve a high throughput, high reliability baseline when delivery teams and an operations team are set up to work at cross-purposes. I’ve seen many organizations struggle to innovate because handoffs, competing priorities, and misaligned incentives occur every day. 

The solution is to adopt the You Build It You Run It operating model for differentiated services, and keep your operations team for foundational systems. Make your product managers accountable for reliability, and put product teams on-call. See You Build It You Run It sounds great but it won’t work here and the You Build It You Run It playbook. 

Focus on frictionless team onboarding

Teams are more effective when new engineers can make meaningful contributions as soon as they join up. Teams need a friction-free onboarding process that allows people to join a team and be productive on day one. 

The problem is organizations usually treat onboarding as an afterthought. The onboarding process is disjointed and time-consuming, because it lacks a clear owner and is split between multiple organizational functions. I’ve seen engineers on a new team wait for weeks to commit their first line of code, because they’re waiting for the necessary permissions.

The solution is to automate onboarding tasks and reserve team capacity for knowledge sharing, so new joiners are immediately productive. Replace gatekeeping with trust and verify, share business domain knowledge, and establish a Bring Your Own Devices (BYOD) policy. See seven onboarding tips to accelerate productivity.

Build paved roads

Teams can deliver many user outcomes at pace when a majority of technology challenges are solved for them ahead of time. Teams need tasks such as microservice creation and telemetry provisioning to be self-service, fully automated, and fault free. 

The problem is centralized technology capabilities are rarely designed to be user-centric. Teams can’t accelerate because they depend on platform teams focussed on infrastructure standardization, rather than the needs of their consumers. I’ve seen teams wait for weeks for a microservice provisioning ticket to be actioned by a platform team.  

The solution is for platform teams to partner with product teams to create bi-directional feedback loops, and deliver self-service paved roads formed around engineer user journeys. Create a positive engineering experience for teams, focus on solving business problems with minimal cognitive load, and prevent platform teams from becoming service desks. See the Digital Platform Playbook.

Find out more

If you’d like to know more about how to successfully scale for agile delivery, get in touch! We’d love to hear from you.