Over the years I’ve observed one common trait across all high performance teams: they have high context. Context is one of those traits that you know when you see it. A high context team knows their customer, what problems they solve for them, how they use the product, what they want to see in the product, and how they are working around missing features. A high context team also knows the technology underneath the features they own, including detailed knowledge of the frameworks / modules, the tools by which their software is developed / deployed / supported, and the architecture and designs behind their software. High context teams can move fast, because they know what they need to get done and how to do it.

The goal of all product organizations should be to create and maintain as many high performance teams as possible. To do this, the organization needs to support and enable teams and individuals in climbing up the context ladder, increasing their subject matter expertise and gaining a greater mastery of the ways and means by which they drive business value.

Types of Teams

Using context as a guide, you can classify teams into one of three types:

Forming - Forming teams are still learning business and/or technical context. Their ability to drive more value for a business is constrained by their need to acquire additional subject matter expertise. Almost all new teams will start as Forming before progressing to Operating.
Operating - Operating teams are executing at a mid to in some cases a high level. They have solid context around the business and technology, but seek to acquire more to continue to improve their ability to drive more value for their businesses.
High Performance - High performing teams have deep expertise around the business and technology. They can move fast, solve harder problems and drive the maximum value to a business.

Below is a matrix by which you can classify a team:

A product organization will have teams spread across these nine boxes at any given time. The keys to a healthy product organization are:

All teams and individuals must be actively working to move up and to the right (limited only by time, experience and ability).
Teams and individuals should be incentivized / measured to increase their context.
There should exist roles and programs to support increasing a team’s context.
While teams and individuals can start in Forming, they cannot stay there (a team that stays in Forming is a failed team).
Not every team will achieve High Performance.

Assessing Business Context

Below are sample questions you can ask yourself and your team to assess your business context. Note: since teams always have members with different levels of experience and tenures, it is the median context across all team members that is reflective of the overall team context (e.g. a team of 5 high context engineers with a new low context engineer is still a high context team).

Who is your customer?
What are the key roles / titles of the people who use your product?
Why does your customer need you to solve the problems solved by the software you build?
What are they doing today to solve or workaround these problems?
What constraints does your customer have that impact the way you design, develop or deploy your software?
Name five customers and a key champion at each one for the software you build today?
Can you give a demo of the product and key features for which your team is responsible, talking to how customers can take advantage of them to drive value to their businesses?
Are you capable of working with a prospective customer and/or customer to show them how to use the software you build to solve their specific problems?
Do you know why customers can’t use alternatives to your product / feature?.

Assessing Technical Context

Below are sample questions you can ask to assess the context level of you and your team:

What are the key software frameworks / modules that support your team?
What does each framework / module do?
Describe the architecture and design for each of the frameworks supported by your team, including dependencies to other frameworks / modules?
Given any specific feature in your backlog, describe at a high level the changes you would need to make to one or more of the frameworks / modules to support that feature?
For most stories, can you immediately start developing to your stories, or do you need time to ramp up on the underlying technology supporting a story (e.g. research spike)?
Are you recognized as the subject matter expert for two or more of the key software frameworks / modules in your team?
If you had a critical issue, how quickly could you triage to identify the root cause?
Are you an expert with the supporting tools and technologies critical to developing, deploying, operating and supporting your software?
What are potential alternatives we should consider to the existing software frameworks / modules owned by your team?

How Context Impacts Process, Roles & Artifacts

It’s important to consider context when considering the right process for a team. A Forming team will often need more process and supporting roles than an Operating team; an Operating Team will need less process and structure than Forming; and a High Performance team often needs very little process and structure. It can also be useful to adjust roles within a team to support the acquisition of context. A dev lead is almost always non-existent in a High Performance team, but can add real value in driving up technical context in a Forming or Operating team. Scrum Masters may be essential to enabling teams to move from Forming to Operating, but may become less valuable to am Operating or High Performance team.

It’s also important to consider context when constructing teams. Forming a team of all low context players with no one at a medium level for business and technology is a recipe for failure. The same is true of assigning a single high context player to a team of low context members. This person can feel isolated and unable to grow and learn. In many ways, team formation should always consider a Rule of One, in which a team should ideally not have members that are two levels above them in context (it’s harder for a team to learn from this high context person and for the high context person to feel effective).

Context is also a critical consideration in reviews of key artifacts (e.g. epics, stories, requirements, designs). Inner-team artifacts (e.g. story) should always be reviewed by reviewers with at least one level higher of business or technical knowledge that the average of the team. Intra-team artifacts (e.g. epics, requirements, cross-functional design) should always include at least a few high context reviewers.

Roles should also be adapted to include supporting the uplift of teams and its members. Product owners should be incentivized in Forming and Operating teams to support increasing the business context. Dev leads should be elected within teams that have the next level of technical context to help support and drive increased knowledge and high quality decision making. The central role of all managers should be to create High Performance teams, and as such, it is essential that they have a high to medium level of business context and a medium technical context to help drive their teams and people up and to the right.

Conclusions

My first experience with a high performance team came out of college at a company called Easel Corporation. I joined as a low context player, lacking a deep understanding of the problem domain and technology in which we were building a product. I was fortunate to have on the team colleagues who had high business and technical context. I worked hard to learn everything I could from them to help me become a better engineer, and a more effective creator of software for my customers. In the process I acquired a passion not just for the craft of software engineering, but also the business, the customers, and the technology. I also learned that there is nothing more enjoyable professionally than working in high context teams. They challenge you every day, make you learn constantly, and quite simply make you better at your profession. As fyi (brag alert) this team has been forever memorialized in a few blogs and books over the years (e.g. The Leader’s Guide to Radical Management). My personal blog on the team is called 8 Lessons Learned from the First Scrum Team.

While High Performance teams have many traits and attributes in addition to high context, there are no high performing teams without high context. Context is the key to great software. Context is the key to driving consistently great value for customers. Context is king.