> This has been my life at work every day, because I have consciously kept myself away from medication for a variety of reasons.
This doesn't make any sense to me, especially in light of your traffic analogy. I have ADHD as well and getting medicated has been probably one of the most impactful things that I've ever done for myself. I'm very curious: why would you want to avoid something that's so helpful?
> This post is an attempt to learn more of these structures and hopefully with enough practice, I'll become efficient in utilizing these structures so much so that it requires less effort and latency to maintain and execute them on a daily basis.
Structure and process only go so far if your brain chemistry is fighting you. If you want to lose weight, diet AND exercise is the solution. If you want to regain executive function, IMO, medication AND processes are the way.
To answer your original question: most of the processes that I have are based on distrust of my brain. Therefore, most of my processes for getting things done rely on getting things out of my head (a la GTD, but without so much accounting). Things and Obsidian represent the bulk of my toolset. In particular: I have a pretty specific workflow for capturing stuff that I want to read later + a template that results in a lot of notes being taken from any given source material. In order for an article (or whatever) to get into my system, it has to be worth the effort to fill out the template + take lots of notes. That's been a good filter for me because my previous tendencies were to read ALL the things. I process my email and Things inboxes as often as needed, but at a minimum, once per week. Getting to Inbox Zero once per week is a necessity for me or I start having anxiety about the stuff that's in my inbox that I might have forgotten about. For email, I unsubscribe from as much as possible, delete the bulk mail stuff, archive things that I'm directly involved in, and capture any tasks in my Things inbox.
Then, Inbox Zero in Things is simply making sure that each task is actionable and has relevant context ("Fix issue #1234", "call so and so at xxx-xxx-xxxx to talk about xyz", etc) and then sorting it into the appropriate area of responsibility and/or project. I don't do anything with tags or anything like that. Once per week, I go through all of my Things lists and make sure that everything in there is still relevant (and delete what isn't), assign a "When" value for things that I'd like to do this week on some particular day, and assign a "Deadline" value for things that ABSOLUTELY MUST get done this week. If I have to reschedule the nice to haves, it's not a big deal.
> It becomes exponentially tougher for me once it goes beyond 2 work items.
Don't take on more than two work items at a time. If there are more, they go in a queue. You can't be actively working on more than one or two at a time anyway.
> it becomes overwhelmingly difficult to focus on my subproject without trying to understand everything it touches upon.
So don't do that. Embrace selective ignorance. Learn what you need to learn when you need to learn it and no sooner.
> There are new terms, new things very slightly unrelated to my smaller project at hand that I don't know no matter how much I learn.
Ask about these and write them down somewhere. If someone is using a term that you're unfamiliar with, politely interrupt them and ask for clarification so that the conversation is valuable to you. Start a wiki page or a gist or whatever that just lists the terms that are relevant in your organization.
> Once I get started on any task, it takes a while for me to get going, and even after finishing it up, it takes a while to start on another task as well.
This is executive dysfunction. Medication helps here.
> But when the project involves interacting with multiple stakeholders in an async manner, it gets split into tens of small units requiring immense willpower to start and stop.
Schedule a recurring check-in with these stakeholders and hold all business until the check-in. Recurring meetings suck, but you have to communicate, so you might as well consolidate all of the communication into a timeslot that works for you. Social pressure (in this case, to join a meeting and use the time productively) can be a great tool to use. You can do this with programming too: pair program with somebody (especially if you know of another person on your team who has ADHD -- you can help each other by creating social pressure to perform).
> This problem is easily avoidable at junior/mid level engineer, but at senior level these are prerequisite rather than a choice.
This is not necessarily true. There are many organizations where stakeholder coordination can be handled by somebody who isn't expected to be writing code.
> But at senior level and above, most if not all software companies require work that's less research/depth in nature and more planning/organizing/breadth in nature.
This is also not necessarily true. There are organizations where senior engineer != junior management.