[lojack]

> is probably one request in a long queue of requests that team is dealing with

You've explained away the crux of the problem without even identifying it as a problem. Queues are an inappropriate construct for managing work. If something urgent & important takes weeks to even get looked at then there is a prioritization problem. If something that isn't urgent or important even gets worked on at all then there is a commitment problem. Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order. Similarly, the work OP is doing may be much less important than they think it is.

Now, I agree that it's important to understand how the system works, but IMO it's equally as important to understand how it can be improved. Long lead times is definitely not a good thing, and also not a foregone conclusion at big companies.

[bastijn]

The queue can be WSJF-t and still be long. Crux of the problem is OPs issue might not be as important as OP thinks.

Now if there are too many people waiting on the central team and all requests are valid the company should address the single point of failure. Grow the central team, train more externals to become contributors or agree to have duplication to a certain agree. Not everything is worth a platform with today's tools and (SaaS) services.

[fknorangesite]

> If something urgent & important

Who said OP's task was particularly urgent or important? Maybe it's getting pushed down the list because they don't have a prioritization problem. We don't know - all we have is OP's (limited) perspective.

[lojack]

I also said:

> Similarly, the work OP is doing may be much less important than they think it is.

[mateo411]

> Queues are an inappropriate construct for managing work.

I disagree. A queue is used to assign priority to a project. When there is more work than people to do the work, you need to prioritize and triage. Just because there is a queue doesn't mean that you can't handle urgent work. You can move it to the head of a queue.

Usually what accompanies a queue is a ticketing system. Nobody like these, but when the organization reaches a certain size, you need this. Tickets are good because it forces the requesting party to put down in writing what they want. This is a necessary step to ensure that right work is done, and it leaves and audit trail, for future people to see what decisions were made and what work was done.

I've worked in an organization where we used a stack based method. In that case the most important thing was the last request. This isn't a good way to work, because it's hard/impossible to maintain focus.

[HatchedLake721]

> Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order.

How can OP, as an engineer, or anyone else, that just joined a much bigger organisation, have any clue that a company is doing work that they shouldn't be doing AND they are doing it in a wrong order?!

[lojack]

Good leadership that sets clear direction and initiatives followed by good middle management that takes these initiatives and disseminates it into something relevant and actionable by the teams doing the work. If you're lacking this then its worth trying to ask for this information to help inform your decisions.

For the record I fully acknowledge that this may not be possible and they very well may need to work within the system in a less-than-optimal state. Understanding the root of the problems help you navigate and ideally enact change even if it's more localized.