School was easier: the path is laid out for us and we just need to, more or less, follow it. At work, not so much. Everything is ill defined and you're sort of expected to "learn by osmosis" (by going to meetings, listening to your team chatting and then forming an understanding). I'm terrible at this and the consequence is that I don't always prioritise my effort and work well.
The obvious answer is to ask, but I'm not always aware of what I'm missing or the explanations come with loads of other lingo and assumptions about my current knowledge. After failing to understand an explanation, I feel I shouldn't ask again for fear being labelled "dumb" (after all, everybody else seems to be doing well). I also try to take notes, but after a while I just end up with a pile of disjoint pieces of information.
Has anyone felt like me? Have you found techniques and strategies to cope with this that you could share?
Or anything really. Points of view and opinions are very much appreciated as well.
In my opinion, some companies are just not set up to allow employees to see the big picture. For example:
> The smartest and most productive employees are given the most tasks. It can be hard to see the bigger picture when you're drowning on multiple complicated projects with no occasional breathing room to assess and reflect and make good long-term decisions.
> Information is siloed. The only communication you ever have with customers or decision makers might come strictly from your boss who might be a project manager. If they don't think that one piece of information is necessary for you to hear, you'll never come up with some amazing insights into the business. The failure could be your bosses, not yours.
> Employees are micromanaged to death. Every decision that you're not specifically authorized to make puts your job at risk. If you treat employees like children, they're not going to stick their neck out and are only going to do what they're told.
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.
On a more important note, do you know the big picture of your own life? What do you want to do with it? How do you see yourself in 10 years? Are you a better person today than you were yesterday? Knowing what you want to achieve in your life is thousand times more important than knowing what others want to achieve. Focus on what is within your control, not outside of it.
1) Relentlessly pursuing all that I could to learn 2) Having a come-to-terms moment that yes it was okay to not know and not feel bad for asking questions
Work is different than school. In work, it is more important to be self-motivated. What this tangibly means is that if I'm working on something that I have questions about, I go to the person who has the answer to my question to ask them. I'll do this many times throughout my day if I don't already know the answer. If you are feeling afraid to feel "dumb", I don't know exactly how to force it, but you need to have a moment where you accept the fact you will not know things and will have to ask questions to get the answers you need. It becomes easy to ask questions once this moment happens.
Also, be the one who initiates change. Don't wait for your manager to tell you what to do [once you have a good idea of your tasks]; be self-motivated and say yes to everything and dive into everything and learn as much as you can. The more you do this, the more you are exposed to, involved in, and talk with others and can pick up enough "background noise" to understand more of the big picture [without explictly asking what the big picture is]. I would say after about 2-3 years you get a good intuitive understanding of your job and role, but I assume that runway depends on various factors that vary by individual.
I need to staple this (or maybe the whole answer) to my wall and read it many times a day. Thanks :)
Among developers the most common missing big pictures may be things like micro-optimization, over-engineering things 'just in case', inappropriate creation of or elimination of tech debt. Refactoring can be a large sink as it sometimes means rearranging earlier teams' work to fit current team's sensibilities rather than along the lines of where flexibility/speed is needed for upcoming/anticipated areas.
As for suggestions, not focusing too closely on particular aspects, thinking pragmatically with the opinion that each thing "is not important" until you can find solid pragmatic reasons for them to be with some leeway for important things you feel but can't exactly pinpoint. It's not easy, takes lots of practice. Do your work 'in the open', share early, share often, get feedback from both devs and non-devs. Participate in non-technical discussions. Maybe lots of pair programming with someone seen as getting the big picture would be valuable. Then you can experience exactly when, where, possibly how that a picture was recognized and acted upon.
Also realize that even if you only get medium sized pictures, that's ok too. Not everyone has to be good at everything. Lean into your strengths while putting some effort into other areas, don't let it be a perceived/imagined failure.
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)
Did you stakeholders not share quarterly/annual roadmap?
> the explanations come with loads of other lingo and assumptions about my current knowledge. after a while I just end up with a pile of disjoint pieces of information.
Do you have 1:1 setup with your manager, stakeholders, skip level? It’s a perfect topic for those meetings and regardless of you bringing it up, it’s their responsibility and part of their job - to make sure the org vision is shared and understood by everyone in their team.
Or, maybe check in with your professional circle, if the problem is unique at your workplace, then it’s time to move on.
One thing I hate about performance reviews is their perverse need to point out your weak point and suggest fixing that, disregarding whether it makes broader sense for the individual's career and whether it may undermine their strengths.
During recruitment I have been looking for big picture oriented people lately, but most of my colleagues are detail oriented and do not recognize nor appreciate it in potential hires.
The big picture is the business. Big picture thinking is being told to do X but convincing everyone that Y is better--but at the business level, not the technical level.
I think better terms than big picture people are ones that think abstractly, conceptually, or analytically. These are the folks who are good 'at naming things'. That means they understood both the business aspect of what areas to separate and iterate upon, as well as isolating technical factors that minimize code quantity and maximize flexibility. If they can do this with a minimal amount of abstract machinery/metaprogramming, that's golden.
This is what I aim for, too. Seems to be working fine for me. Some tips for OP:
- Try to get a lot of informal chats with relevant departments. Being in the office or at events s.t. you can join conversations + talk face to face helps.
- Be a „yes man“ whenever other departments have some technical issue that needs to addressed. Or even if it's nothing technical.
- Think more from a business perspective during technical planning and implementation. Does it really create value to code more than the most basic MVP here? Do we really need that fancy technology and scalability?
- Get good at communication and soft skill in general. If you're smart but „difficult to work with“, you'll end up doing mostly specialized work.
- Get good at note taking and knowledge management. Where was that link to the product roadmap that was shared two months again? What was the context for that design decision two years ago? It's useful if you're able to answer questions like this with your notes.
Having people around with specific biases together with people who can intermediate (another type of skill) can still make a fantastic team is my overall point.
If it is a small one then find out people who have had some part to play from the beginning and talk to them.
However if you are conscious of appearing dumb, then that's the first thing you need to solve. We are all dumb in some way. Being conscious of it prevents you from learning.
My "big picture" was not so big. It's just to get enough context to do my "mundane" work well. I forgot to say that I'm only a mid-level engineer. For instance, to give good opinions/high-level solutions during ticket refinement sessions, realising when a ticket is not clearly written and things like this.
Also, there's always this debate about the level of detail that goes into a ticket. Lots of detail makes refinement sessions take ages (and they aren't the place to "solutionize".
However, tickets with fewer details (just the business outcome), can be challenging as we may not yet know all our service's logic or we may not know enough about the organisational structure of our company (for when we need to interact with other teams with different competences).
If someone has now explained the "big picture", do you see a path to have seen it earlier?
Another approach is to consider the work you are assigned more deeply before you begin and understand the various different ways it could be done. Each assignment will have multiple parts or aspects and those aspects each can have more or less time spent on them to achieve various qualities. Quick, superficial breadth first vs deep depth first, etc. Getting something precise and correct vs getting something good enough, etc.
If you can understand and articulate the choices that are available to you in how the work is to be done between the various approaches- basically understanding how much time to put into what aspects to get what values or qualities- then you can form a hypothesis about what makes sense and then you can take that hypothesis to your manager. Asking them for direction on what to solve/optimize/prioritize for given 2 or 3 alternatives before getting too deep into the work is a good, valuable question. Through those answers and conversations you will more directly start to understand the qualities and outcomes that are important, and how important they are (inferring from how much time/depth should go into them).
Most times there is no single "big picture" at large organizations, rather there are many individually authored narratives that may allude to shared facts but also are highly personal and often involve hidden agendas that are held close by individual managers. All human organizations involve politics, and this is what politics is. Even organization-scale planning tools like OKRs are highly contextual and cannot be taken too literally.
For any given person, understanding the near term choices available to them in exactly how their time is spent, and what the results of those choices are in terms of qualities of outcomes, and then asking for help selecting the right outcomes, then executing on those choices, and following up if new learnings present themselves or if things are not as expected, is a good, politics-free approach.
It can be hard to do this, to not just barge ahead doing the work but to think about various ways the work could be done. Hard but worth it. This approach of understanding every situation/assignment as set of choices, is big picture thinking in disguise.
Hope that helps. Good luck.
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.
It's about "reputation" and about what your peers think of you. I feel that how others perceive is very important for career progression inside a company. It's common for managers to ask team mates for feedback during performance reviews. This was (and is) my fear.
You need to overcome learning challenges, be tenacious in seeking understanding, and share what you know with others. That's what makes for a confident high performing employee.
**
For better or worse, you want people's perception of you to be accurate.
To do that, you need to figure out how to understand the concepts or bigger picture and demonstrate that understanding through your actions.
To be able to do that, you really need to figure out how to best understand and retain the stuff you're having a hard time with. That probably means being more proactive and noisy in meetings where these concepts are shared. If you don't understand something, you have to advocate for yourself and fill in your gaps by asking.
When your peers are thinking about your performance they will either see you making choices that are well informed and aligned with the bigger picture, or they'll see you making choices that are just guesses.
Right now, you should be figuring out why you're having a hard time understanding and retaining things. Start with a good foundation. Healthy sleep, exercise, and anything physiological that stands in the way (learning disabilities, ADHD, dislexia, etc.).
Then focus on the process. Does taking notes work? What if you record meetings and slowly listen later on, repeating parts as needed?
If you learn well with guidance and curriculum, seek out professional courses to help you learn. If the knowledge you're lacking is very domain specific or unique to your company then make the curriculum yourself. Make a goal of teaching other people the things that are unique to your company and not only will you learn it, you'll teach others.
I can't stress this enough: ask questions, take copious and clear notes so you don't need to keep asking the same questions. Ask more questions if you have gaps. Restate the concept out loud, then ask if you're getting the concept. Repeat until you've got it. If you approach it with the intent of helping others learn, you'll be much more diligent about reducing complex ideas into easier to understand chunks.
You'll also be helping your peers. Someone in the room will inevitably be just as confused as you were before you began asking questions to help improve your understanding. Do you think those peers will think you're not capable, or do you think they'll be grateful you had the guts to ask?
If you're working for a company where asking questions is discouraged then maybe start looking for a new role somewhere else. It's not just a red flag for how your experience will be at that company, it's a massive red flag for the viability of the entire company. A company that isn't an expert within their domain is one that's always reacting to market forces, but never leading.
Don't convince yourself that asking questions is a sign of weakness. It's part of your job.
I literally just got out of an hour long meeting with a CTO of a fintech company where all she did was ask questions. The reason: she needed help getting up to speed on something that wasn't even all that difficult to understand but had a broad impact on her organization. It's part of her job to ask questions so she can make informed decisions.
