\+1 to Alex's advice. It's nothing personal. 

Some added thoughts & a couple practical suggestions as someone with a "glue person" personality, so you can learn from this faster than I did without thinking you need to change yourself:

When others don't see your role as a "glue person" role, questions outside of your daily tasks can feel like someone is usurping their responsibilities or undermining their value to the company or like you're shrugging off your own tasks. 

Sometimes it is an unintended effect of the delivery style, or a difference in team culture, or folks who are sensitive from previous experiences in different ways. 

It can take time to be culturally embedded and accepted into a workplace, especially if you're cross-functional and there's historical friction between pillars or teams that you might not be fully aware of. 

I don't know what your reprimand looked like, but one of my favorite supervisors in college would word such feedback as, "FYI this is how that's received, but also don't do that again." Maybe it can take some of the sting off to internally reframe your feedback that way too.

I hope that over time, management & non-engineering teams come to see that you're genuinely inquisitive out of love of learning, but even if it doesn't, I hope you find a pace of work that you can enjoy & find other ways to scratch that itch! Maybe you can keep a running list of questions you have that don't block you from doing the bare minimum at work, and then update it when you get the answers indirectly, and/or bring them to your manager towards the end of check-ins.

Mid-Level Data Engineer at Nonprofit

Weily Lang

I find that the top skill for staying organized is **categorizing** the information you're managing on behalf of your working memory.

What categories work for your needs & your brain is going to be **different from other people's** and they're **going to change**.

You're probably going to start off with categories that don't work for your needs. It's okay! Treat it like code:

1. **You're capable of improving your skills.**
2. **Reiterating is necessary to see incremental progress.**

Categorizing actual notes is great, but categorizing information mentally as you take it in is also helpful because it **creates associations for long-term memory storage & retrieval**.

So, how do you get better at identifying what categories work best for you?

- **Meet yourself where you are.** Recognize your strengths as well as your gaps. Over time, you'll get better at figuring out what you need to accommodate yourself. \
  \
  The goal **isn't to turn yourself into someone you're not**. Maybe you'll never be able to memorize context for each part of a system (or maybe you will!), but for right now you *can* create a system where you store the info you need to **1\. jog your memory** (retrieval from long-term memory to working memory) and **2\. easily find that info again** (manual retrieval). If your categories aren't working for either of those functions, then they're not working & you can create better ones. Nothing is wrong with you.\
  \
  For example, I compensate by building & relying on my understanding of bare concepts & my ability to transfer them across different contexts. The flip side is I know I need to 1. communicate those bare concepts upfront to build trust, and 2. utilize those bare concepts as a building block to keep track of details for each project or system.
- **Document & review to find commonalities.** It can be similarities between the knowledge the senior engineers have, similarities between the type of information you find new or confusing, or similarities between the types of situation that cause you the most confusion. Similarities are why categories work. \
  \
  For example, you mentioned senior engineers have an easier time grasping mental models. Do any of these models share similarities? I can guarantee you they do *and* that they can be distilled down to some core tenets. Are these mental models usually reflections of design patterns, business use cases, or something else? **Try not to focus so much on some objective perfect truth, but rather on what would help you make sense of things in a repetitive fashion.**
- **Address your inner monologue.** What comes up mentally during these working sessions with senior engineers? What comes up internally when you run into blockers that lead up to asking senior engineers for help? When we see others grasping things more quickly or more easily, those comparisons can be easy way for our inner self-talk to become concentrated on self-doubt. \
  \
  If there's a lot of internal chatter, that drain on your executive functioning can get in the way of you asking & answering self-learning questions like, **"If I were in this senior's shoes, how would I have arrived to this understanding using what I have in front of me? What would that exploration look like for me?"** \
  \
  You can ask them how they arrived to their understanding (& I encourage you to!), but I find that not everyone is good at recognizing all the steps they take in their own self-learning. Things can come a lot more naturally to some people than to others, which is just a part of having different brains that have different needs. \
  \
  I can, however, guarantee that you yourself have asked & answered these types of questions before in different, less overwhelming contexts if you've gotten to the point of becoming a mid-level engineer. You've been able to learn before & you can do it again! **How can you transfer your past learning habits to this new situation of learning to be like a senior engineer who works on system-wide problems?**
- **Set reasonable expectations for your categorization system.**\* Whether it's what you're trying to achieve or how long it will take to create or tweak your system, make sure not to fall into perfectionism. \
  \
  A lot of workplaces will be willing to let you take some time out of your workweek to organize your notes, but when you're just figuring it out, **you might need to take some personal time for reflection & organization.** \
  \
  When you say seniors are "managing to remember a lot of context", is it context *you* should reasonably know? Is it context that you've been working in for a long time, or have been told multiple times before, or can easily figure out? Or do they just have a lot of experience that means they have built muscle memory over the YOE that we don't have? I find both things are usually true to some extent! So sometimes we just have to remember that more **senior folks are there to know a lot of things we wouldn't know**! :)

I asked every step of the IC engineering ladder a simple question: "What is the most important skill for success at your level?"

The result is an engineer from each of the 7 levels sharing their candid reflections about the most important skill, along with advice. Companies represented: Meta, Slack, Qualcomm, Gusto, Instacart, Cruise, and Pinterest.