It is quite astounding to me that an astonishing amount of work is done and code written without any knowledge, view or understanding of the bigger picture. And yet no-one seems to have taken the time to consider just how remarkably ridiculous this common situation is. How can people be expected to perform at their best and create the best products when they have no clue as to what the big picture or goal is?

And yet that seems to be the norm.

I started thinking more about this topic yesterday when discussing the work our Quantitative Analysts were doing with them. They were keenly focussed on figuring out the best and most correct way to calculate the results asked of them, but were struggling to understand what the results would mean and how they would be used. Without that understanding, they were unsure whether they were even thinking about the problem in the right way. What they needed was context, the bigger picture. Once they understood how their numbers and results would be used in the business and how their code would be used on a calculation server, they were far clearer on what they needed to do and how to architect it better for the business. And a whole lot more.

I really do not understand how or why the big picture should remain such a mystery, but being the nerd that I am, here’s my weak attempt to codify the reasons for I think folks hide the big picture:

• They don’t know: The person setting the task also has no idea about the bigger picture, commonly in a dystopian bureaucracy gone mad or larger organization (Can you tell the difference?)
• They don’t care: The person setting the task is just trying to get paid and cannot wait until the 5PM go-home alarm, otherwise known as “It’s just a job” or “I work in the public service” syndrome.
• They have no time to explain it: The person setting the task is under pressure to get it done, has a hundred other things to do and is handing off a piece to get it off their list, pretty much like every overworked Business Analyst out there.
• You don’t need to know: The person setting the task does not work for an intelligence agency and likes to play power games, or “I’m the boss, just do it.”
• You should already know: The person setting the task honestly assumes that the big picture is clear and has been communicated in the past, the home version being “I’m having a fight with my partner and they keep saying I should know why” scenario.
• It does not matter if you know: The person setting the task is a control-freak douchebag, believes themselves to be a superior being and is just acting like a middle ages noble.
• They don’t know that you need to know: The person setting the task genuinely does not know that sharing the big picture is a good thing. Point them at this post and they will receive a good, healthy dose of wonderful karma points.

From first-hand observations, the impacts of not knowing the big picture are many:

• Duplicated or unnecessary processes, workflows and code because the folks involved had no idea that it was so. If they knew, they would find better things to do.
• Inconsistent deliverables, products and results, where different groups producing the same things come up with different answers. Look at any large firm with multiple accounting groups and try to get a single picture of how the business looks.
• Signs of disconnected, fractious, people fighting against each-other over small fiefdoms when the whole purpose of an organization is to work together to achieve the bigger picture.
• Frustrations between groups and departments where the “other” is always getting things you asked them to do wrong, a refrain we programmers are so used to hearing.
• Outright conflicts where one team’s work-product negates another team’s work product, and neither knows about the other.

Whereas, in the situations where the big picture and context is communicated first, I see:

• Better architected business, workflows, processes and systems as everyone involved understands and is working towards the same big picture.
• Requests, deliverables and systems better tuned to meet the needs, not the stated wants, reducing rework and frustrations.
• Combines the intelligence and domain knowledge of the requester, programmer and worker/user to find the right, optimal and useable solution, not a quick and dirty one decided by a manager.
• Gets the work done better as all involved have “bought in” and are motivated to succeed as a team.

Next time you set a task for someone else, start with the big picture and explain to them how the task fits in, how, where and by whom the deliverables will be used, and how it will make things better for others. Then, and only then, explain the work needed to be done. You will find that they will understand the task better, deliver better solutions, enjoy what they do more, and most importantly, give feedback insight into ways of doing it better.

Follow the author as @hiltmon on Twitter.