And what does this have to do with you as an engineer?
What is context?
Context is a set of information we use to guide our decision-making. Any decision you make is made within a given context. The quality of the decision largely depends on the context at hand, as well as how you deal with what you don’t know.
Why is context important?
Imagine a company where engineers are told exactly what they need to build, and nothing more. Would you feel good in such a company? Incentivized? Empowered?
That is leading with authority.
On the other hand, leading with context allows the leadership to set a direction, and let the teams decide what to build and how to solve customer pains. Of course, there have to be some limitations and alignment on what outcomes are acceptable. In this case, context is information about the company’s vision, strategy, and general direction.
Context provides a certain level of autonomy to engineering teams. Autonomous teams are empowered to choose the opportunity to work on, and how to do the work. People on these teams feel incentivized, and valued and want to speak up and actively contribute to the company and the project they work on.
On which team would you rather be?
Simplified example
We are all in a hurry sometimes and want to get someplace as fast as possible. One of the options is always to get a cab. When you take the cab, do you simply tell the driver where you want to go or tell the driver when to turn left, turn right, or press the gas pedal?
One of these is leading with context.
How does leading with context work?
At the heart of the autonomy teams get is trust. The organization has to trust that the team has the best intentions at heart, and tried it’s best to achieve a set goal.
At Netflix, when a team would not achieve the goal, the managers do not blame people. Instead, they ask a question “What context was the team missing, so they made the decisions they did?”
What does this have to do with an engineer?
A lot. If you are missing context, the best thing you can do is speak up. Ask your product owner to tell you why is the feature being built. How will it solve the challenges users have? What are the challenges users have? How do we sell this?
Go even further. Talk to customer support, sales, and marketing. Break down silos between departments.
Get the context, and share it with others inside and outside your team. Start the discussion.
Real-world examples
Talking with sales departments
Over a lunch break, I talked with a sales rep. Starting with the questions above, the discussion steered about time to value for the customers. And we found something that improves those metrics, which took a couple of hours to build.
Talking with customer support
During some informal conversations, a colleague mentioned that they spent 30 minutes every time a specific job had to be done. This job included a lot of manual testing. A couple of hours later, the problem was solved. The customer support colleagues are happy, and we saved the company months of wasted time on this specific task.
Fun fact
Some organizations are so poorly led that this kind of work is simply not possible. Even if you find a way to save a lot of time or make a cheap feature that improves the metrics, a counterargument often heard is: “We are an agile company and have to stick to our agile board.” There is a lie in that quote.