How to work efficiently as a resource bottleneck
Anyone who works in some kind of production pipeline (which is pretty much everyone) can become a resource bottleneck. When working in these roles, our responsibility is to manage how we interact with our upstream resources efficiently so that we don't get blocked and therefore block our downstream.
Perhaps the most intuitive example of this is a team lead or manager whose communication and decision-making is an upstream resource for the people they are managing: Their reports need them to make decisions and provide clarification before they can proceed with their work. Another example is working customer support, where we typically have a queue of customers waiting for answers and solutions. A less obvious example is a developer working with time-consuming resources like CI and CD pipelines. When they're running, we're waiting for their output to complete some task, so they're effectively upstream of us, and since all of our work goes through those pipelines, and they're going to take time to run, we're effectively bottlenecked by the rate at which they run.
Get tasks off your plate quickly to take advantage of parallelism
One can really only do one thing at a time, so when we're the bottleneck we should aim to get work off our plate quickly so as to not block the next thing. In our last example, we saw that we're a downstream for our CI/CD, but, of course, we're also upstream since it starts running as soon as we put something in it. Most real-world production pipelines are bidirectional in some way, which helps us to take advantage of parallelism, since very often when we receive something from an upstream, there is something that needs to be kicked back (further clarification, the next CI iteration, etc.).
With CI, we can't really push code through and expect it to pass unless it's code-complete. But what we can do is surface different kinds of failures earlier in the process; if there's some nitpicky CI thing that's surely going to come up at some point in the process, then you can either know about it earlier or later. Knowing about it earlier means fewer corrective iterations and less time spent waiting on CI once everything else is in place.
When we do development work, we're often blocked by questions that we have for other people (this is pretty much always a bidirectional case). In this case, it's much better to "sound dumb" and ask things that we could figure out on our own, but that another person already knows. We're trading a tiny bit of their time for a sizeable chunk of ours (this works in reverse, too: Say things that other people could figure out to save them time). Sometimes people get really weird about this, but IMO it's just good teamwork.
On customer support, don't be shy in asking people to provide links, screenshots, and clarifications. Many people find this to be a little bit off-putting, but issues are resolved much faster this way. Engineers often make the mistake of treating customer support queues as unidirectional. They're not. Asking pointed questions and listening to the customer frees us up, and we'll also spend a lot less time per ticket in the long run.
In general, the rule is that if there's some combination of extra movements up or down the pipeline that results in less time spent overall on an item, then take advantage of that while making good use of the time when the item is in someone or something else's hands. Remember, too, that it's useful to break up work and send pieces up or down the pipeline; being blocked on one part of a thing doesn't mean that we need to be blocked on the whole thing.
Resolve small tasks quickly
When issues can be resolved quickly, it's better to resolve them immediately than to track and resolve later. This applies even when something is slightly lower priority -- if it's going to take five minutes, then the overhead of tracking and communicating about status really isn't worth it. Not tracking it might also mean that we forego some parallelism which is fine since the tracking/switching overhead is not justified. Usually, things that fall into this category feel like "chores".
Enable other people rather than taking over
Often, when people are waiting on someone, they get frustrated and do it themselves. When you're a bottleneck (you probably are), this is a recipe for disaster because everyone will be waiting for you all of the time. When other people aren't doing what you want them to, there's often a good reason for it. Talk to them and figure out what it is, and then do something to enable them to keep moving. This is often kinda like forcing better parallelism on their end -- often they're trying to figure out something that someone else could easily tell them. It might sound like I'm giving management or leadership advice, and it's partially that, but the rule applies more generally: It's better for everyone when people fix their own workflows ('nuff said).
Keep a separate note for each working context
The note should contain all of your bookmarks, reference numbers, etc. Bookmarks should include links to relevant conversations, cards, and documentation. This makes switching contexts easy, which in turn makes repeatedly shuffling things off your plate easy. Ideally, this note should feel like a dashboard for a body of work, and with everything relevant immediately accessible.
P.S., if you're interested in working more efficiently, then you should check out Sapling