[AtlasBarfed]

Ticket walls are an unfortunate outgrowth of continued management incompetence in software development.

Unfortunately, once it starts it spreads like the plague, and combined with defensive internal service monopoly empire building, results in anything being done taking 10x more as a task passes through a half dozen first layer and who-knows-how-many second layer ticket walls/SLOs.

[malwrar]

What competence would make ticket walls go away? I’ve only ever had dayjobs with large orgs and ticket walls have been a useful defense against folks who insist on sending low-quality help emails or DMs the moment they encounter a problem. Sometimes I consider taking a massive paycut to work in a smaller company specifically to lessen the probability of needing to work with those sorts of people. If there’s some alternative model for dealing with these people I’m excited to hear about it.

[AtlasBarfed]

Aligning resources predictively to the needs of applications/projects. So if a project is about to go into intensive database development, you align a group of your DBAs to them for "preferential access".

Not just viewing the workers as completely interchangeable cogs, but getting them insight into specific applications, so requests can be processed more quickly.

Transparency into who is handling a request.

Managers scheduling and accepting enough "float" or unplanned work time to accommodate requests.

Educating developers to plan out their resources and requests.

Aligning support personnel to release schedules.

[phkahler]

>> What competence would make ticket walls go away?

I dont mean this as snark but how about making quality software that is easy to use and has good documentation.

More jokingly: Take down the walls and let some users actually bother developers with their problems until the developers fix those recurring annoyances just for their own sanity. This is probably going too far.

[dkersten]

The "ticket wall" I was talking about in my original comment had nothing to do with quality software, but rather getting a team handling a different competency to do or answer something. The example I gave was actually for the "cloud automation" team, they handled such things as AIM roles/policies, cross-account AWS permissions and various other AWS/cloud services that other teams used. Other teams had similar "go through tickets" ways to interface with them, for example the team that handled the servers that CI got provisioned on. Developer-services teams that provide services to development teams internally, basically.

So making quality software would not eliminate the need for them or the need for them to manage incoming requests.

[xapata]

Don't change jobs for that. Same problem everywhere.

[0xbadcafebee]

'Ticket walls' can be used as efficient pipelines for work. The problem is the teams who are asking for tickets aren't managing them correctly or don't have a good working agreement with the users. This is unfortunately very common with internal service providers.

But it can be changed. The users have to have a conversation with the service provider about what's wrong with the process, how it's affecting the users (& the business), and how they'd like it to change. If the service provider stonewalls them, they can go up the management chain. Often upper management has no idea what's going on and will get something done if they hear enough people complain.

[dkersten]

I liked it though because you could track the progress on the ticket instead of pinging people periodically to see what the status is. Once I got used to it, I found it was a much simpler way to get things done across teams.

[jasonpeacock]

What's the alternative to ticket walls? What would competent management look like in this case?