The Ticket Hell
Problem
If all you have is a hammer, everything looks like a nail.
Why do I start with this well-known phrase? First, I want to give a bit of background, and then I’ll explain why I mention it.
Over the years working with infrastructure teams, I’ve had the great fortune of meeting some very insightful people who have always told me:
“Never let the infrastructure team operate solely through ticket requests.”
Position
What’s the rationale behind such a strong stance?
- You need an extremely strong culture from end to end to decide which ticket is more important than another.
- The infrastructure team must inherently grow as the tech and product teams expand to new features.
- It’s extremely difficult to keep the infrastructure team motivated.
- Innovation is impossible in a ticket-driven infrastructure model.
There are many other reasons, but these are the most relevant ones — let’s go through each.
1. Extremely Strong Culture
Infrastructure and QA teams are rarely included in roadmap and sprint planning. If they are, it usually happens at the very end — “when everything’s already cooked.”
So, when the infrastructure lead receives two tickets and needs to prioritize based on execution capacity, the obvious question arises:
Which ticket should I prioritize?
Good luck with that — because for every internal team (your “clients”), their request will always be the most important thing in the world.
2. Meaningless Growth
Let’s assume the previous issue is somehow solved. You still can’t escape this one.
Why do we say the infrastructure team must inherently grow?
If you fall into the pattern of having infrastructure handle all ticket requests, then as the company launches more products and features, you’ll need more infrastructure engineers to handle the growing ticket demand.
Congratulations — you’ve created an execution bottleneck.
The “solution”? Hire more infrastructure people.
3. Motivation
Let’s assume points 1 and 2 are solved.
But… are infrastructure engineers human? (They are, last I checked.)
It’s hard to stay motivated in a role that should be driven by creativity but instead is reduced to just closing tickets — with no room for questioning or discussion.
What happens next? High turnover in the infrastructure team and growing frustration among product or tech teams. And if those teams happen to be toxic, they might even start labeling infrastructure as slow or a blocker.
And what can I say about that? Keep calm — and here’s a big hug.
4. Innovation
Finally, even if the previous three points were somehow resolved, innovation is still impossible.
Why? Because a team that only closes tickets — that only participates reactively in projects to “build infrastructure” — will never have the space to innovate.
Back to the Beginning
If all you have is a hammer, everything looks like a nail.
Throughout this post, I’ve explained the reasoning and main consequences of running infrastructure management through tickets.
And I want to be clear: Working with tickets in an infrastructure team isn’t necessarily wrong. What’s absolutely wrong is managing infrastructure and platform operations through tickets.
So what does the “hammer” metaphor have to do with this?
It means that many companies misapplied agile methodologies to their infrastructure teams. It’s time to pause and reflect on why things aren’t working well in so many places.
How can we avoid it?
We must inject a product mindset into infrastructure teams — offering high-quality abstractions and user experiences over the underlying platform chaos, enabling product engineering teams to become self-sufficient in managing their software and its infrastructure.
I hope my experience helps you rethink how to build culture and work processes for infrastructure teams within your company.
If you have questions or want to discuss any of this, I’d love to connect.
See you soon! 👋🏽