What does thinking about the big picture mean?

Question

I’ve been told a couple of times that I’m not thinking about the bigger picture during my 360 feedback. I’m not exactly sure why (and intend to ask my manager).

How do you think about the bigger picture when on a project at work?

What questions do you ask yourself?

How do you keep track of your surroundings to keep the bigger picture in mind when on a project?

Answer 1

It's a very good idea to ask your manager for some examples of taking the bigger picture into account. Here are some things that people who worked for me have done that showed they weren't thinking about the bigger picture:

• interrupting coworkers for help to get their lower priority (on a team wide list) tasks done, so they could be proud of being done, but keeping the coworkers from finishing higher priority tasks by insisting on being helped
• doing something the easy way, even if that might make it harder to maintain in the future (eg hard coding something instead of using a value that could be changed on the fly)
• doing everything the most flexible and future proof way all the time, for pride reasons, regardless of how long the product will be maintained for or whether the budget can cover doing it that way
• arguing about every change in order to minimize their own workload or bug count, rather than working to create the best possible product for the user
• arguing for a larger scope and more work, even paid overtime, to produce more than what the customer was paying for, out of personal pride and wanting to make a great product

You may notice that some of these contradict each other. That is to be expected. Life isn't made of simple rules like "always do things as quick as possible" or "always make the best possible product." Instead, you need to know things like budget, schedule, the importance of the particular feature under discussion, the connections between features, the history of the project, and so on. Often, developers don't know all these things, but someone -- the project lead, the product owner, the business liason, the manager -- does. Asking about these things and taking them into account when making decisions - or asking that someone about what you should do -- is how to take the big picture into account.

Answer 2

The big picture emerges when you step back and view things with some distance.

What does that mean? Ask yourself these questions:

• What consequences do my actions have in the long term? In five or ten years?
• How do my decisions affect other departments and the overall company goals?
• What is the effect of my work on other people and stakeholders?

The criticism of not looking at the big picture is often used to shift focus on the common good instead of your narrow self-interest. It can also be levelled at people so they help the self interest of the person doing the criticising.

Answer 3

It's hard to say exactly what your boss meant without actually hearing the entire meeting. However, it usually means you're focused too much on making the smaller bits right rather than the larger picture of how it all comes together.

However, here's my take on it through personal experience. If after asking for specifics and he's unable to answer, then it means they're just writing a negative for the sake of writing a negative. It's a broad statement that cannot be proven otherwise. If you're being denied a promotion or pay raise, then this is probably it.

Answer 4

I’ve been thinking about this for a while now, and although I’ve not got a response from my manager yet, I think after doing some introspection it’s down to two things:

1. Not gathering the requirements and having the full context of things;
2. Which is down to possibly not being able to think on my feet and asking the correct questions and communicating my thoughts.

Therefore it can be perceived as me not stepping back and seeing how the task could affect everything else.

So for me I need tackle the thinking on the feet aspect which I feel only comes with lots of practice.

Answer 5

and intend to ask my manager

This is the best thing to do so you can pinpoint his specific concerns.

In general the big picture is a more wholistic view of a project rather than a part of it. But in varies in context. In some cases it means potential interactions between your portion and other portions, so for instance I may be able to solve an engineering issue quickly one way, but the solution will interfere with something else or create a problem somewhere else which would then need solving.

Answer 6

Usually it means you think in terms of Tactics instead of Strategy.

Let me give you a clear example - take a look at this Code Review question and some of the first few answers: https://codereview.stackexchange.com/questions/88190/survivor-programming-challenge

There was a lot of focus on tactics there. Whether to use Arrays, ArrayLists, or whatever. How to form the loops. Removing vs Flagging. Etc, etc.

But I was the only one who said, "Wait, let's step back for a second. What is it we're trying to do, and what's the best way of doing it?" Everyone else was focused on Tactics instead of Strategy.

And that's ultimately the Endgame for quality software engineering: continuously trying to see if you can solve the problem better by making it one level more abstract:

• Level 1: "Well, this uses two loops and a recursive function call..."
• Level 2: "That recursive call is expensive though. But if reorder it like..."
• Level 3: "But this function isn't needed, because when we do this sort of request..."
• Level 4: "Why is this request serviced in this code? The floobar process already handles..."
• Level 5: "Wait, the business area needs this because of X. But wouldn't it be better to accomplish X through Y instead of what we're doing?"

When we jumped from 1 to 2, we improved the run speed of a program. When we jumped from 2 to 3, we not only improved performance, but we also removed unnecessary code. When we jumped from 3 to 4, we reduced the proliferation of duplicate code company-wide. And when we jumped from 4 to 5, we improved how the fundamental method the business needs were met.

You can't always do this. Sometimes you have to actually program in level 1. But... as you get more experienced, you'll find that the more time you spend in the upper levels and the less time you spend in the lower levels, the more productive/valuable you'll actually be.