The Ticket Wall: When Centralized Teams Become Bottlenecks (and How to Fix It)

The dreaded ticket wall. Your team depends on a centralized team, and now their ticketing policy prevents even basic questions from getting answered. Suddenly, one of your engineers tells you this team will no longer answer any of their questions directly. Everything has to go through a ticket.

You think to yourself, that can't be right. This engineer must have just misunderstood the process. So, you try talking to the manager to clear up the misunderstanding, only for them to double down and tell you that their team has been overwhelmed with ad hoc requests, putting their own deadlines at risk. From now on, everything (no matter how seemingly small) has to go through a ticket to get planned in their sprints.

I recently saw someone asking how to handle this exact situation on LinkedIn. Unfortunately, I forgot to save the post and lost track of it.

I've been on both sides of this scenario. I've been on the team trying to deliver on our own critical priorities, facing the seeming roadblock of the ticket wall. I've also helped coach managers under me how to solve the real underlying problem when they've tried the ticket wall defense themselves.

You Can’t Break Through the Wall by Fighting It

You can't break through the ticket wall by fighting it head-on. This manager has instituted these changes to try to protect their team. They're doing what they think is right. You might be able to bypass the ticket wall for a specific issue by escalating around or over the manager, but ultimately, creating conflict with the manager of a team you recognize as critical to your team's success isn't a viable long-term approach.

I'm a huge believer in always leading with trust. Most managers aren't going to institute a rigid ticketing process out of a desire to exert control and stifle communication. Processes like this are born from stress, pressure, and seemingly unmovable constraints. This manager likely feels their team is understaffed, they likely feel like the volume of requests coming from various teams is unpredictable and hard to plan for, and they may have even been recently reprimanded for missing commitments. The ticket wall isn't about control. It's about survival.

Start with Gratitude and Recognizing Shared Goals

A genuine expression of gratitude can go a long way towards building a bridge with the other manager. If you recognize that your team's projects depend on the work of this other team, then you should realize how important they are to your success. The only viable solution for this challenge will involve forming a strong partnership to improve cross-functional collaboration and ensure both of your teams are successful.

It's important to remember, above all else, that you are all part of the same team. Your teams may have different domains, and your specific objectives will be different, but you're still a part of the same broader organization at some level. This team's purpose is not to work tickets, just as your team's purpose is not to work user stories. Your company has a deeper mission, your products have end users with problems, and both of your teams' overall objective is to serve those users and achieve your organization's greater mission.

Why Centralized Teams Exist and Why They Get Stuck

Centralized teams like DevOps, security, cloud infrastructure, etc., are both a solution to and the cause of scaling problems as organizations grow. The function these teams serve is critical, and as organizations grow, it's important to establish consistency in how their function is implemented. It's not feasible for every team to develop the necessary level of specialized expertise, so it makes sense to establish centralized teams for their function.

At the same time, as the organization grows, it's incredibly common for these teams to become a bottleneck, especially if the work they handle is bursty or cyclical, such as supporting new product launches. When the work isn't steady, it's impractical to staff these centralized teams to support the high-water mark of their workload, which often leads to the teams feeling short-staffed and under pressure.

The Real Problem is Toil, Not Process

Managers of these teams often fall into the trap of thinking the only solution is to implement a strict ticket management process to attempt to throttle the workload and control expectations. Creating a ticket queue isn't actually a solution, however. It's not solving the problem. It's just deferring the systemic failure. If the centralized team doesn't have capacity to keep up with the high water mark (which is impractical) they'll just accumulate work faster than it can be completed, some things get infinitely deprioritized, and your ticket queue becomes a ticket black hole.

This is one of the most common engineering collaboration bottlenecks in growing organizations. The root cause is toil. Managers of these teams implement strict ticketing processes because they feel like their teams are drowning in work, but a ticket queue isn't going to change the volume of work. The real problem is that their team has become a single point of failure for actually doing the work associated with their domain. They've accumulated toil, manual, repetitive, automatable work that scales poorly. The solution isn't tickets, it's eliminating the toil.

Centralization Without Enablement Doesn't Scale

It's too common for organizations to recognize the benefits of centralized teams but create them by taking all the people with the specialized expertise from distributed teams (frequently doing a reduction in force simultaneously) and putting them together on a single team. They've made a centralized team, but still do all the work manually. On top of that, the number of teams they support will likely grow faster than their team, but they're still expected to keep pace.

If a centralized team is just juggling toil, it'll never be successful. Centralized teams need to act as governance groups, developing and documenting best practices and creating systems and processes to allow other teams to operate self-service. This could involve creating CI/CD libraries, infrastructure as code templates, security scanning systems integrated into build pipelines, or full self-service vended compute portals.

Approach the Other Manager as a Partner, Not a Critic

It's important to approach the other manager as a partner, not a critic. Even if you have a background in their domain area, don't assume that the other manager doesn't understand the need to eliminate the toil. Come to the table with empathy and curiosity. Ask them about what self-service capabilities they've considered to be able to shift left while still ensuring proper governance and best practices. There's a pretty good chance they've already thought about it. If they haven't, explain that you want to help reduce their team's workload without subverting their expertise.

If they've already considered how they could reduce their team's toil, try asking them if there's anything you can do to help. Often, even when a manager realizes their team is growing in toil, they'll feel like there's some roadblock preventing them from prioritizing the actions needed to eliminate the toil instead of just suffering through it.

The Typical Roadblocks: Time, Skills, or Buy-In

The usual culprits are time, skills, or buy-in. The manager might recognize the need for long-term solutions but feel so buried in the toil that they can't prioritize them. Maybe they recognize the need to build self-service mechanisms, but their team lacks the software engineering skills to build them. Or, maybe they know the solution but need budget or approval to dedicate capacity for implementing it.

The key is to lead with trust, assume that the other manager knows their domain, even if they don't see the solution, approach the problem with empathy, and act as a partner in identifying a path forward. Try thought exercises like "If you could wave a magic wand, what manual work that your team is doing today would have the biggest impact on your team if you could eliminate it?"

Partner on Solutions That Eliminate Toil

When you and the other manager have identified the roadblocks to reducing their toil, figure out what you can do to help. If their issue is capacity, is there any room for you to shift some of your roadmap that relies on their team to free up capacity so their team can focus on long-term work to reduce toil? If they need skills outside of their team's expertise, is there anyone from your team you could loan them to fill in the skill gap? If they need budget or approval, can you be a champion for them, advocating to your senior leadership or PMs?

The important thing is to establish that you're here to support them in addressing the root of the problem. You're not just trying to pressure them to work tickets faster, prioritize your team, or circumvent the process.

Centralized Teams Should Scale Through Enablement

Centralized teams have a place in helping organizations scale efficiently while ensuring consistency and excellence in specialized functions like DevOps, security, or cloud infrastructure. However, to avoid becoming a bottleneck, centralized teams need to be focused on governance, tooling, and support instead of simply doing the manual work for all the other teams.

If you find yourself dependent on a team that's drowning in toil and trying to solve it by throttling intake, partner with them to tackle the root of the problem instead of fighting their process. Centralized teams can't scale by just increasing capacity, and they definitely can't scale by trying to protect the team with a ticket wall. If you can help the other team overcome their toil challenges, both teams walk away better positioned to achieve your organization's mission. That's the best win you can ask for.

Have You Been There?

Have you been on either side of this issue? How did you solve it? What worked (or didn't work) for you? I'd love to hear from you in the comments.