Management: Sailing on the Sea of Context

By Jeff Schwaber

December 13, 2021

“Managers need to share context,” they say.

But what is context? Why does it sometimes make sense to people and sometimes not? Why can’t we just post everything to Slack, and everyone will be fully informed? And why do some important facts stick with people and others don’t?

When managers get together and talk, the word “context” comes up a lot. Managers have a lot of context. Managers provide their reports with context. Managers guard their reports from distracting, useless, or harmful context. The politics of why this project went forward, the concerns that have been suppressed, the possible alternative work that might get shoved your way, all of this is at least distracting and often worse. There’s a difference between transparency in service of trust and transparency that creates problems. To be an effective manager, we have to know what context is and how it works in our heads. So let’s talk about what it actually means.

Here are some dictionary definitions:

• Google: the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.
• Merriam Webster: the parts of a discourse that surround a word or passage and can throw light on its meaning.
• BusinessDictionary.com: background, environment, framework, setting, or situation surrounding an event or occurrence.

I don’t think any of the above captures the thing we mean when we talk about managers having context. Here’s my working definition:

• Context is a graph of facts about the world—the project, the organization, the users/customers/personae, etc. These facts create or embody constraints, and from these constraints and facts, opportunities arise.

I want to break that down a little:

Context is a graph

Every fact that you know could be part of the context of something, but individually, a fact isn’t hugely contextual. It’s much more likely that the fact is contextual when it’s in relationship with other facts. For example, imagine building something and having to choose between using wood or steel. Steel is stronger than wood for a given thickness, but a piece of wood the same weight as steel can be stronger than the steel in some circumstances. Engineers don’t choose materials based on a single fact about them, whether their strength or their density, but rather about all of the constraints, interwoven pieces of the context graph, that affect the choice. Strength, density, fire resistance, ease of putting a nail through, etc., all combine to help determine what choices are allowed.

Facts about the world

It might seem like context should include more than just facts—maybe decisions, preferences, opinions, and other such information. The engineer in me prefers to simplify and acknowledge that all sorts of facts are valid facts, whether they are what we traditionally think of, like facts about something physical, like the properties of a material, or facts about someone’s preferences or predictions, like when someone expects the project to be done in a few months, or there’s an executive who’s known for not taking others’ opinions seriously when making decisions. Most facts and data can be engineered around with sufficient cleverness. However, if you prefer to phrase your definition of context around facts, decisions, preferences, or opinions, you wouldn’t be wrong!

Constraints and opportunities

Facts by themselves can feel constraining when we’re trying to create or change something, but it really is the web of relationships between facts that create the most interesting constraints, like when a physical material is the perfect one but vastly too expensive for the use case or when a programming language is super efficient at solving the problem in front of you, but few people know it.

The same is true with the opportunities that arise out of networks of facts, like when you recognize that if you can make a software task an order of magnitude faster or require less skill to use, it doesn’t just make the task faster for users. Sometimes making a task faster or easier also unlocks regular use that allows the user to make frequent use of something that was just a little too frustrating before. That is exactly what Canva and Figma did with visual design tools. What previously required expensive and hard-to-use Adobe software that regularly frustrated users turned into something that anyone could use, especially for making simple designs and sharing files among a team.

We all swim in a sea of context all the time because when we describe context with this definition, what we’re talking about is nearly the same thing as our entire knowledge base. Skills, facts, random tidbits and trivia, things you overheard, all of these have the potential to become the context for some goal. We each just swim in a different sea.

That is why it’s so hard to transfer context efficiently from one person to another because it isn’t a bucket of information about the project, context is a component of the graph of everything you know, and you run multiple risks trying to transfer a portion of that graph:

• You can’t figure out where to stop, and you try to transfer too much or too little—basically what always happens. For example, I share the deadline for the presentation, but I didn’t tell you the board will be at the presentation or enough detail of what they’re expecting to see.
• Your brain isn’t designed to query all the context you’ll need for some project. It is designed to be looking at one fact while trying to solve a problem and pulling up other relevant facts. It’s tremendously difficult to get every piece of relevant context out of your knowledge graph and provide it to someone else.
• You try to transfer a piece of context only to have it land in the wrong place on the graph. For example, warning someone about a risk that seems minor to you but becomes the driving factor in their decisions because they connect it to previous project failures they’ve seen.

Sometimes context encourages you to believe in constraints that you should not believe in. There are no perpetual motion machines, but if you allow that constraint to dominate, you’re likely not to recognize that heat pumps, with greater than 100% efficiency, are possible. Or, you’ve heard rumors in one part of the organization that people have tried to solve this problem and failed, and you absorb that they failed because they chose the wrong database, but actually their database engineer didn’t know the database well. Or they got halfway into the project, but a super-urgent priority came at them, and they had to drop half of it and then ran out of time. Or they were trying to solve a speech recognition problem that was hard two years ago, but now someone offers a service that solves it for you.

Stories like those start as rumors and then become legends. And then the legends become their types of constraints on the actions of the organization, and often your job is to learn from that gathered wisdom of others, but sometimes if you want to achieve success, you have to deliberately ignore these “legends.” We can’t relitigate every decision, but we must revisit a few of the right ones if we are to make progress.

In other words, common knowledge is neither common nor always knowledge, and many of the things that you think everyone knows, you still have to communicate.