How Sharing Context Early (and Often) Engages Your Engineering Team

There’s a common misconception that software developers just want to write code. Their co-workers are wary of annoying them, interrupting them, or wasting their time. I’ve often been asked “what’s the best way to ask a developer to do something without pissing them off?”

When you’re managing a team of developers, you can’t let these stereotypes fool you. After all, they are just people, motivated by the same things as anyone: they want to connect with their peers, build cool stuff, and feel good about their work. And as studies in behavioral science have shown, people produce higher quality work and have more job satisfaction when they feel a sense of ownership in their work. Remember, developers interact with the product all day, which means they spend a lot of time thinking about how it works and how it could be improved.

So, how do you, as an engineering manager, encourage your team to cultivate a sense of ownership and keep your team engaged? You share context early.

context (noun): the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed

In other words, give an explanation for the ‘why’ of the work.

Typical engineering task definitions spell out the “what” of the work: What functionality needs to be developed in which subsystem? What are the symptoms of the bug? What are the test acceptance criteria?

The thing missing in these definitions, however, is the higher-level context of the task, or explaining Why does this matter? When your team understands how the tasks they’re working on fit into the larger picture, their day-to-day work is imbued with stronger purpose and meaning.

When your team to understand the “why” of the tasks they’re working on, they’ll be significantly more engaged in and take ownership of the solutions they implement. Netflix calls this out explicitly in their culture deck where they describe the goal of “giving context, not control.”

And why is it important to share context early?

The earlier you share context for the project, the more engaged your team will be.

Benefits of Giving Context Early:

• Developers have time to digest new information, which allows them to contribute to planning discussions.
• Newer employees get a chance to understand a problem they may not feel comfortable asking about.
• You’ll have a more successful problem-solving team because they have a background on where the problem came from, who’s invested in the solution, and what ideas have been proposed already. (This can be particularly important for projects that address long-standing technical debt or features that “people have been asking for forever.)
• Everyone on your team has a more equal shot at having their contributions heard.  Some developers hear a proposal, break it down quickly, and come up with improvements and objections on the spot. Others need to sit quietly for a while, draw on a legal pad, or even sleep on it before the good ideas start to form.
• Your team will be more invested in the continued success of the software they’re shipping.

Simple Ways to Introduce Context Early:

• Begin your next sprint planning meeting by sharing some overarching goals for the sprint.
• Before a meeting to go over the architecture of a new tool, send an email introducing the idea and invite anyone who is interested.
• Don’t make participation mandatory for the whole team, but leave the door open for feedback and discussion.

Sharing context early shouldn’t require much extra work on your part if done properly and thoughtfully and you’ll have a team of developers who are engaged and determined.

Do you have experience with sharing context? Comment below!