How can I improve at solving ambiguous problems and developing a deep understanding of complex dependencies?

Can you draw a block diagram of your system, API endpoints, subsystems, etc. with API calls to your dependencies? Do you know what your call volume budget is? Can you enunciate which are hard dependencies for which of your operations, which are nice to have, which you can survive on cache for on a limited basis? Do you know know which systems can be used async via queues and which must be sync? Do you know where your data is stored and if any other systems access it directly? Do you know what impact slow or failing requests against your APIs has on your callers? Do you know what circumstances may lead to your dependencies load shedding, and how your systems respond? Do your systems shed load, and if so how is this signaled to callers and how do they respond? Do you know steps to onboard a new caller to your system? To add a new dependency you call? Do you understand the lifecycle of each of the requests that come to your system, and where you’ll scatter-gather, versus making certain calls in serial? Do you have a dashboard to see your own traffic, broken down by caller, and the traffic you are generating to your dependencies, including error rate and latency?

It is a lot of stuff. Depending on the system maybe it is too much to stuff into your head, but your runbooks and architecture diagrams should enunciate this, and you should be able to refer to it quickly. If you are creating a new design, and you’re going to be adding a dependency or adding calls to an existing dependency from a new context, you need to be able to identify this, ensure they are aware and you begin onboarding or adjusting your budget with enough time, knowing how you test, etc.

Lee shared a bunch of great, specific questions you should do. I'm going to zoom out and focus more on principles:

1. Talk to a bunch of people
2. Don't be afraid of looking dumb (embrace it!)
3. Ask follow-up questions
4. Learn how to ask great questions to begin with
5. Build deep relationships with people so they'll put up with your silly questions
6. Participate in as many system design meetings and documents as possible
7. Keep an eye on code reviews, particularly those that are being rejected by more senior engineers than you (why are they rejecting them?)

So how to do these 7 things? I recommend these (and following the related resources there):

• "What’s the most effective way to switch domains in tech?"
• "How can I become more independent and better at unblocking myself with tricky technical issues?"
• Asking Effective Questions That Get Great Answers Quickly
• [Masterclass] How To Build Deep Relationships Quickly In Tech