How do you avoid missing the big picture at work?

If there are specific parts of the big picture you're not seeing and should be seeing, you should be told -- with reasonable clarity -- what they are, or at least given some very concrete and actionable examples.

If the implication is that you're just not understanding your industry domain, there's no substitute for experience and independently motivated learning. This takes time, and you can't bake the cake faster if you set the oven to broil, impregnate 9 women and get a baby in one month, etc. Your manager will just have to be patient.

Richard Feynman was famous for asking dumb questions - sorry about the dumb article but it was the quickest one I could find (1). There's more if you Google, he wrote about it autobiographically.

Life outside of academia requires this kind of emotional grit - and it's absolutely something you can learn. It takes practice and reflection, and accepting that nobody starts out with the answers.

1 - https://philipliao.com/feynman-and-dumb-questions (edited to add the link)

What would be the worst thing that could happen if you did ask again? Would you get fired? What if you don't ask, and make a mistake for lack of knowledge?

> Has anyone felt like me?

I have. And I know what it feels like to be reluctant to ask for help. I struggled with it for years. I had the attitude that knowing all the answers was part of my job, and not knowing meant I wasn't qualified.

I was very wrong for a lot of years.

Here's how I think of things today: asking is honest, pretending to know when you don't is a lie.

Of course it's not as simple as that though.

You still need to do your part.

If someone says "The QOS process that the Triage team rolled out last week is broken and flooding the POC terminals with bleep blorp alerts," you need to find the balance of what's "askable" and what's "researchable."

How you find that balance takes practice, and probably depends on how you learn.

My rulebook:

If it's domain specific, I don't waste a second not asking. I'll interrupt executives in meetings asking for clarification and understanding. It'd be dangerous not to, since I trust that they know how to do their job as much as they trust me to do mine. If I don't ask, I risk delivering work that is based on whatever my imagination came up with to handle something I know nothing about. Asking someone who knows is always less expensive than trying to answer it myself. The answer I'll get is also much more likely to be accurate than if I draw my own conclusions.

If I need to know how to do my job better, it depends. As a programmer, there are things I must know that have nothing to do with the domain I'm working within. Stuff that I bring to the table as a programmer. Stuff that transfers to jobs in totally different domains. As an E8 staff engineer (think highest level senior engineer at a company), there aren't a lot of people I can talk to about my programming question though. For those kinds of questions, it's my job to find the answer on my own.

More junior? Ask every time.

Not senior but not junior? I'd want to compare what it costs me, in time and money, to find the answer on my own compared to what it costs in time and money for me to ask someone who knows. Almost always, it's better to ask.

The reason?

As an E8, it's also my job to answer questions from junior engineers. It's the best part of my job too, because it means I get to help someone grow as a person and in their career, but also be better at their job, which helps me and the company I have equity in.

My advice to you specifically: ask questions until you understand. When you do understand, immediately offer to give a presentation on what you learned so that others can learn too. There's no single thing that's more effective in helping yourself learn something then to agree to give a presentation on the topic.