The short answer is no.

The way you described a grind is *within* a system. There are a fixed set of rules, inputs, and outputs. With a system design you are generating the rules, inputs, and outputs.  There are cards in the games you referenced that change the rules, but the truly powerful cards, which undermine the tricky balance that makes the game fun, are quickly banned or removed.  Describing a system is a different game then working within a system.

The best advice I have about how to get better at system design systematically is to do a retrospective design on a system you are familiar with. My guess is that at this point your understanding is at the "what" a system or service does.  For the services and components you own, do you know the "why?"  As you pick up these concepts you start to see them pop up everywhere, and more importantly, you start to notice places where they are missing. Usually there is a reason.  Time and experience are really the only ingredients here. I've noticed very few prodigies that are able to make a contribution to a complicated system with less than 3 years of experience. Not that it can't happen, my thesis is that you have to be burned a couple of times before you really learn lessons here.  It takes a while to burn yourself the requisite amount of times.

And when it comes to soft skills, what you're really talking about is people. Humans are not deterministic robots. What I would recommend is finding resources to work on your EQ. What happens when you work on yourself is you start to become more compassionate, a better listener, and notice more social cues that you may not be picking up on today.  It took me a long time because I started later in my career and I'm not where I'd like to be, but this work has done the most for me to up-level my soft skills.

\-Steve

Principal Software Engineer at Amazon

Steve Huynh

You have two obligations while you are oncall:

1. Field tickets.
2. Effect change so the system that you own runs better (and therefore generates less tickets).

If you're working on a bug but continually get pulled off, is it an operational bug, i.e. the source of the alarms that are going off? Or is it an an impactful bug but doesn't get in the way of operations? Maybe it's a CX defect that doesn't generate tickets. If it's the former, maybe your team is getting buried in ops, and it might make sense to do an ops sprint to clear things out. If it's happening to you it's likely happening to your team members. If it's the latter, STOP. You should only be doing 1 and 2 above. Non-urgent bug fixes should not be worked on by the oncall.

The difference between seniors and non-senior staff is not technical ability but rather visibility. With a micro-service architecture, junior and mid-level staff tend to only have visibility in the services they own. At my company this is a feature, not a bug. There are at least 2000 microservices in my organization.

So to increase your understanding I would:

1. Start with understanding the services adjacent to the ones you own. Don't try to learn about every service all at once. If your service calls theirs, or their service calls yours, it's likely that those systems will be easier to understand for you.
2. I would focus on a conceptual understanding of why these services exist rather than what they do or how they do it. This can usually be summarized in a sentence or two but is sometimes difficult to get at because the folks that work on these systems want to talk about the finer points of how they do things.
3. I've found that in a microservices architecture, when trying to draw a box and arrows diagram it's easiest to collapse several services together that share similar responsibilities. Once a diagram goes beyond 10-12 elements it gets too complicated to be useful.
4. Give yourself time to internalize things. This is complicated stuff, if it was easy to understand then anybody could do it.
5. I know I have enough understanding with a system when I can read a document produced by another team and understand what it's saying. When trying to figure out what a suite of services does, see if you can't get access to some of their documents. Note the terms you don't understand, and then try to figure out what they mean. I have found that people are happy to help if you make a concerted effort to understand what they work on and batch your questions so that you are respectful of their time.

Hope this helps.

\-Steve

I'm interpreting what your saying as you are effectively acting as a senior engineer by being the SME on your team's services by doing things like fielding queries from other teams, and this is leading to you having to choose between acting in this capacity or addressing your team's ticket queue.

The simple answer is that a senior engineer is expected to do both at a high level. There are three paths forward

1. Work extra time. This isn't sustainable in the long-run, will lead to burnout, and potentially will introduce performance problems for you down the line.
2. Transition away from being the SME. I'm going to assume you want to be a senior so we'll rule this out.
3. Get more efficient, deep dive on root causes, and drive long-term fixes. It seems that you've started doing this on the SME side by creating documentation and wikis. Realize that this type of work is long-term and pays dividends in the future. You should apply this thinking to your team's ticket queue. If your team gets the same class of ticket, spend your oncall time and spare cycles working on fixing the root causes. Make sure your ticket queue doesn't boil over, but prioritize fixing bad alarming, getting finer grained metrics, and code-level problems rather than only focusing on ticket-level resolution. This may require some extra time and effort in the short term but it won't be permanent. Eventually, like the documentation work you are doing, things should get better over time and there will be less on your plate.

Realize that the way out of this is by taking a longer-term perspective and by making sure your day-to-day is chipping away at making yourself and your team's processes more efficient.

Hope that helps.

\-Steve

Another approach, if you have access to it, is to poke around at the client code base.  Often times, if the service code is difficult to grok the code consuming code may be easier to understand. 

Another advantage I've found with poking around client code is it often reveals the true behavior of APIs if there is weirdness like operations that do something different than their name.  You will often find comments lamenting these oddities there rather than in the service code itself.

\-Steve

An ambitious SDE-I!  You will go far if you keep this up.

If you are having problems understanding your team's system design documents, I recommend that you proceed no further until you can understand your team's documents.  I would try to read a document several times and highlight the acronyms, concepts, and sentences that don't make sense and do your best to figure things out on your own.  If you get stuck, I would schedule time with folks on your team that can parse the document to walk you through it.  Repeat until you've consumed all of your team's documents, understand the problems each document is addressing, and the solution that was recommended.  This may take some amount of time but it's critical.

The reason I recommend this approach is that system design is a high-dimensional space and it's easy to get lost. You're unlikely to stumble upon a book, article, or video that's going to address the unknown-unknowns you currently have. At this point you likely both have gaps in conceptual understanding of general system design concepts *and* gaps in understanding your team's existing system, its endemic problems, and historical context.

Once you have a retrospective understanding of your team's software and systems, only then would I recommend that you attempt to write a prospective system design document.  The good news is that you need to search no further than your team's document repository and your team members to grow in this area.

Good luck!

\-Steve

The reality of the situation is as you get higher and higher in level scheduling becomes more and more of an issue. I wish I could show you the ridiculousness of my outlook calendar.  I often have triple and quadruple booked time slots and I have to make a judgement call about who I'll let down.  It sounds like your director is prioritizing his own time over your convenience but you should understand that you need him more than he needs you and his calendar is likely a circus like mine is.

I am allergic to reoccurring 1-1s.  My philosophy is the optimal time to meet mentors/mentees is on-demand because the necessity of the discussion is likely not going to be evenly distributed across time. When you had major issues to work through he had no problems meeting weekly.  When things stabilized the urgency left and his prioritization shifted.  

My recommendation is to proactively cancel meetings when there's nothing urgent to talk about. For weeks there is something meaty to talk about, I would recommend that you update the meetings agenda to reflect the value and urgency of the conversation that you'd like to have so he has a reason to shift his priorities around.  

\-Steve