We have all heard the common sense1 saying that “context is everything” at some point of our life. It’s a reminder to consider the circumstances before making judgments or decisions.

Especially in consultancy, “context is everything” is a famous adage. What is true in one company, almost never applies directly to another. We always need to do major adjustments to the new context and the different realities.


But what if I told you that we can take this idea even further? What if I told you that nothing has advantages or disadvantages, only characteristics?

At first, this might seem like a strange notion. After all, we are so used to consider pros and cons when comparing different products or services.

Take, for example, someone in the market for a home safe. Most suppliers will brag about how resistant to tampering theirs locks are. An advantage, right? After all, that’s what all homeowners will be looking for: protection.

But what if we are talking about a burglar? Now, that same characteristic is a big disadvantages when looking for a home to target.

Still with a burglar in our minds, what if they are looking for a safe to take home and practice breaking into? It’s the same person but now that same characteristic is again an advantage.

We can see many more examples like this in the software development industry. It’s common to find technical analysis of frameworks, libraries, or programming languages. They are usually filled with positive and negative evaluations, advantages and disadvantages.

But what context are the authors using to assess them? Most of the times this is absent, which can lead to controversy and people talking past each other.


What the above examples illustrate is the implicit context we all have that is very often not said out loud. Not clarifying this full context is the most common pitfall of comparisons.

It’s the implicit context that “the purpose of safes is to protect”. It’s the implicit context that “frameworks should be stable”, or “performant”, or “easy to use”. Same goes for programming languages, where implicit contexts are many and sometimes contradictory. If we dig a little deeper, we will find that all these comparisons are only meaningful under some context.

Everyone has their own implicit context in their minds. In society, within cultures, we share common implicit contexts. This all bleeds in when we talk to each other.

So, what’s the solution? We need to make the implicit context explicit. Even if it seems redundant! Even when “everyone knows this”.

Always question yourself and be aware of the context you bring to every conversation. This include your goals, your constraints, past experiences and values. These are the “tinted glasses” you see the world through, and everyone else has their own.

Be curious about how other people’s implicit context differs from yours. You can gain a better understanding of their perspective and work better together.


If you analyse something by yourself, the danger of misunderstandings isn’t there. Implicit and explicit context tend to mix since it’s all internal. But looking for that implicit context might surprise you and shed new light into the “why” of your choices.

When analysing with someone we know very well, relying on a shared implicit context is possible. Misunderstandings are less likely but can still happen. Be very attentive and default to clarifying and making it explicit at the first sign of trouble.

Not relying on implicit context becomes crucial when working in larger collaborative groups. It’s impossible to rely on implicit context because everyone has a different one. This is especially important when working in multicultural environments, which bring even wider implicit context differences.

So, when preparing for a group discussion by yourself, start by gathering the different characteristics of the topic. Aim to do it in an impartial way, devoid of context. Then, with the group, define together which context to assess those characteristics under.

If you’re in the middle of a group brainstorming going sideways, go back to ensure that the context aligns. Clarify what is the agreed-upon context and, if there’s none, define it. Give everyone a shared frame of reference to assess the different solutions.


Next time you think about pros and cons of something, take a moment to consider the implicit context.

Remember that nothing has advantages or disadvantages, only characteristics. We can assess them under different contexts, and yours will likely differ from someone else’s.

Make all context explicit and be curious about other people’s perspectives. This way you can make work more effective and make better decisions together.


Update 2023-05-17:
(via Andy Kemp)

Interesting research supporting this notion of implicit context in the Scientific America article People Differ Widely in Their Understanding of Even a Simple Concept Such as the Word ‘Penguin’:

“The probability two people selected at random will share the same concept about penguins is around 12 percent,” Kidd says.

The reason is people’s different life experiences:

For example, “people disagree about things like whether penguins are heavy, presumably because they haven’t lifted a penguin.” Here, Kidd hints at where a lot of these differences likely come from: they boil down to a person’s life experiences “If you’ve spent time watching penguins walk, you’re maybe more likely to think they’re heavy from their waddle,” Kidd says. “If you’ve spent time learning about anatomy, you’ve maybe learned birds have light skeletons and so think penguins are light.”

And the differences can be quite numerous:

…the team’s results suggest that at least 10 to 30 quantifiably different concept variants exist for even common nouns such as penguin.


Shared to…

🔒 (groups)


  1. I know, sometimes “common sense” is not that common 😏 ↩︎