As companies grow, context can become a scarce resource. As more variables, people, teams, products, customers, and coworkers create an increasingly infinite combination of possible ways to move forward, deep context on what to do and how to do it should be thought of explicitly, because its thoughtful allocation can make, or, notably, break, a company’s productivity.
What Is Context?
For the purposes of this post, let’s scope context to the following: the unique information inside a software company that is necessary to make good decisions while delivering a product.
Here’s some examples of context:
- Goals, missions, OKRs
- The history of the company
- The competitive landscape
- The people in the company, including their strengths, weaknesses, opinions, and preferences
- The history of the codebase
- The architectural design of the software
- The code itself
How It Can Go Wrong
A classic description of not having context is Chesterton’s Fence - one person proposes to tear down a fence they get no use out of, a wiser person says to know its use before doing so.
In software companies, the classic example is the rewrite - new engineers arrive, say the current system is trash, propose a rewrite, and then spend all their time figuring out that they need to reimplement things the old system was accounting for that they didn’t know about.
However, context is much more fluid than decisions on fences and rewrites. In fact, framing context as something that is critical around certain decisions reduces the reality of context - in reality, it’s like an energy and resource that shapes everything teams do.
With that framing, a more common example is the context that any given team has - teams can be high context, low context, or anything in between. A common antipattern in rapidly scaling companies is having teams of diminishing context that eventually operate in a sort of perpetuating cycle of mediocrity: they’re so low context that they redefine what good and bad looks like, and operate in some sort of amorphous nothingworld, recreating existing functionality, making easy things difficult, not knowing where true complexity lies.
The Diagnosis
This happens in companies because the allocation of high-context individuals doesn’t keep up with the complexity growth of the organization. People don’t take enough effort to reduce the context needed to operate or limit growth. People underestimate the power of context.
Solutions
There are only two solutions for this problem: more effective allocation of context and reducing the amount of context needed to operate.
Allocation of high context individuals
On the first front - you can specifically think about who are your high context individuals and think about ways to get teams to rely on their knowledge.
Often companies attempt to solve this problem with architecture or product review, getting the most high context individuals into positions of approval. This approach alone is bound for failure. Without context embedded in teams, high context individuals become gatekeepers, not enablers.
The simplest rule for scaling high context resources is: you should have at least one very-high-context engineer per team. This can be the manager or an IC. But, if you try to scale faster than this, you’ll end up trying to patch context into teams via process, and things will get messy. It’s better to have no team than a low-context team.
Reduction of necessary context
The other approach to solving this problem is the healthier, long-term solution: reduce the context needed to operate. You can and should do this in many ways, including:
- Create very clear goals (that don’t need major context to understand what good looks like). For example, a low-context-needed goal is “increase metric X”. In comparison, a high-context-needed goal is “increase metric, while not cannibalizing other revenue, while focusing on the enterprise cohort, while aligning with go-to-market stakeholder strategy that you have to go ask them about, while balancing the priority of 12 other things.” The highest-context-needed goal is “just figure out something valuable.”
- Modularize your architecture to give teams smaller amounts of, and more isolated, code. Microservices are popular way of attempting to reduce needed-context and cognitive load.
- Modularize your org chart, give teams clear lines of ownership, and group teams in ways that give groups similar context requirements. For example, having directors manage disparate product areas requires them to have more context; having directors manage teams that have technical and product similarities requires them to have less context.
- Use popular, common technologies, allowing you to hire people who already have context.
- Have good documentation
Conclusion
As you grow, think about context and context collocation explicitly. Make sure to have your highest context teammates dispersed and training others. Know that the context of your team will make growth behind a certain rate unproductive, unless you spend the time to reduce the amount of context needed. Know that this is true not just for common software development problems (e.g. service architecture) but also decision making in every other aspect of building software.