[jasonblurb]

Engineering manager here.

As other commenters have said, this situation is common. That's not to say it's okay - it isn't. The question I'd ask you is, "before you bail, what can you learn from this experience?"

One of the primary duties of a manager is to act as a diffuser of potential stressors. Given your experience level, all the inputs you are receiving should be landing on your managers desk first. Those inputs should then be filtered, grouped, prioritized, contextualized (to whatever extent is necessary for you to understand what you're being asked to do) and then handed to you at a rate that enables you to complete work and learn the systems you're interacting with.

It's okay to push back on requests. It's also a good idea to develop a system for doing so.

One of the things I repeat often with my direct reports is, "everything has a place." Every request, every escalation, every task we're asked to work on - it all goes into a ticket system. Everyone on my team knows to accept the input and inform the source of the input (often another engineering manager) that their requests will go into our work queue and will be prioritized against our other objectives at the appropriate time.

You seem to be operating without those systems in place. What I'd suggest is that you develop a queuing and prioritization system for yourself. The next time someone asks you to do something, maybe try saying:

"I'll be happy to dig in. Let me get a few pieces of information from you and I'll put this in my queue. Mind if I follow up with you next week?"

A couple things could happen in response. They could escalate and use their coercive power (they outrank you) to force you to do the work immediately. This is when you can invoke your manager. You could respond with,

"Understood. I will inform my manager and we will prioritize accordingly."

Usually these situations won't escalate. If you appear to have your act together, others will recognize that. If you have a system of note cards or an issue tracker you're using to capture their requests, they may be more inclined to leave you to manage your own work queue. If you're also equipped with a prioritization rubric (it can be arbitrary, just start with org chart hierarchy of the requestor if you don't have anything else to go on), even better.

As the saying goes, "manage your time or others will do it for you." No matter how stressful this may seem now, this may be an opportunity to learn some time and work queue management skills. The earlier in your career you begin cultivating these skills, the better.

I'm happy to elaborate on any of the above.

[kwiromeo]

I agree with this. Definitely learn to push back. I've been in a similar situation albeit in aviation systems engineering. The way I dealt with a lot of incoming request was to always point out that I had things that were already on the back burner. I would phrase it along the lines of: "I am currently doing Y, and was planning to do X and Z next. Is A you're asking me to do urgent? If yes, I can do it after Y of you're okay with X and Z being delayed." This usually got me a response that indicated want the priority was. I would also really try not to let the current work I was doing being stopped. Stopping something midtask would always make the same item I was working on take longer, so I would push back if they tried to stop current work midstream. I would say: "I'm X hours away from accomplish this task. Can item A your asking wait until then?" That usually got me some good relief.

One item to note that this is also an opportunity to request some training, either formal or informal. Find the skill that if improved would easily increase your task output, find formal training for it in the area or nearby. If you can put a cost benefit analysis on a 1 page word doc, you might be able to take this opportunity to improve your skills as well.

[samstave]

>It's okay to push back on requests. It's also a good idea to develop a system for doing so.

THIS is important, and understated.

There is a lot of oppotunity to learn from the situation you are in, but this skill in particular will last you a lifetime if you learn it well.

Specifically later in your career when you are looked upon to lead a team, manage THEIR workload and be able to accurately communicate priorities, load, risk etc upstream.

As an example, at the director/eng mgr level, a very common interview question set will be around "how do you manage competing priorities or requirements for your team" and even better "How do you say no".

Get a solid system of tracking requests, priority and decisions. Take the next while at this current position to find your voice in structuring the flow of how these requests come to you - and build relationships with your boss and other team-leads who either depend on you downstream, or are making requests of you.