Context, context and more context
I work as an engineering manager these days, I am also the parent of two inquisitive kids, and I regularly volunteer at school and other activities where I interact with other kids and parents.
A theme that’s been in my mind for the last few weeks is the importance, fundamental importance, of context.
I’ve organized teams for the Tech Challenge a few times in the past (maybe will do it again this year). A couple of years ago the theme was “No Roads, No Problem” with the goal of building a functioning hovercraft that could go over three different tracks of increasing difficulty.
The Tech Challenge instructions are intentionally vague, while still being specific on the constraints and limitations of what can or cannot be done, but they always associate the challenge to a real world problem (context). In this case think about a vehicle that can move and reach places where there are no roads to be used in emergencies, or simply to reach remote places.
We as advisors to the teams (kids from fourth grade to high school) cannot really participate beyond helping organize and probing questions. In my experience the real world problem provides a fertile ground to derive those questions during the design sessions, and provide context and boundaries to what the teams are designing and creating.
More amazing to me is that context helps a great deal when going deep into a specific topic. From the same tech challenge the teams realized that batteries were important, and that they really do not understand how batteries work, why would a hovercraft lift at some point and then maybe 2 minutes later not work at all… Looking at the datasheet for a AAA battery its one dry lecture; now if you are trying to understand why the batteries only work for a minute or so, then it’s the most exciting thing in the world to find these discharge charts and finally figure out, well that’s how those batteries are supposed to behave, so something has to change, and then spent the next 2 weeks trying different batteries, arranged in different serial and parallel combinations, until you get what you need. That context both focus and drives that curiosity and effort to a whole new level.
As a software engineer context comes in many different shapes, and in my experience the best engineers tend to understand and piece together the different and sometimes competing contexts and steadily move the projects forward to completion.
Technical Context
Let’s say we are building a new feature for an existing service. Understanding what else is already available, how the different teams work/interact with this feature, and how they do with existing features is just as important as figuring out the solution that is O(1) and not O(N!). Existing languages, support for production, and available expertise on the technologies also all part of the context.
For example: in a place where everyone is doing python development, and deploying kubernetes, it might be that Haskell was technically a better language for the feature at hand, but it fails to take into account the whole environment (context).
Taking that road often means less support, less people available to bounce ideas or debug problems, less feedback, less well understood tools for deployment, monitoring and metrics among others.
That’s not to say to never introduce something new, but when you do, then you have to provide the new context to all the other people that does not have it, or they will be hopelessly our of context, and not fully understand what’s going on, or how to help.
Business Context
We as engineers sometimes get just a piece of the puzzle to build, and it’s common that the whole puzzle comes from a few levels above, understanding how that piece fits in the whole picture allows engineers to better implement it, to ask the appropriate questions, to understand it’s place in the critical components, and to deliver a better feature. Many times this skill of understanding not only the technical side of a feature, but how it fits in the business, is what feeds the engineer’s growth.
Time Context
What’s important when is yet another one of the competing contexts. Priorities often switch from the time of initial design to the launch date, or even after. Often as the world moves, decisions change and the context of what we are working on does too, recognizing this and clearly sharing with the team is a must do for leaders.
This is true also based on the life cycle of the projects, as projects near completion, stability, supportability, and the drive to zero bugs need to have much higher priority than maybe what they had early on a project.
Your Part as a Leader
For team leaders, providing context is one of your (many) main responsibilities, letting the team know what’s important, what is the end goal, how each engineer’s part fits in the full plan, and how that plan fits on the business unit. Just as critical is to also provide context on what’s important when during the life of the project.
As a leader, you are not just a participant on discussions, you are actively leading them, sometimes a little nudge at a time, sometimes with bold proposals and moves, and in all cases providing context helps align and enabled and empowers the team to make the right moves in the desired direction.
A word that I often associate with context is transparency, I cannot count how many times teams have expressed being thankful for the transparency, and the more I think about I realize that this transparency is also about context, when we clearly communicate what are the thoughts from our leaders, and their leaders, a fuller picture can be made, in sharing the thought process that led to a given decision, or the compromises that were made and why, engineers are able make finer decisions keeping the same line of thinking.
So there you go, providing context to your work team, your Tech Challenge team, your kids will help their growth, keep this in mind next time you are having a discussion, or a one on one, or leading a team to produce results.
