Making the Implicit Explicit: Tactic for Improving Team Execution

As an engineering leader, one of my favorite tactics for building effective teams is making the implicit explicit. 

How We Work

If you think about how we work, there are countless steps we’ve developed to be effective in our roles.  By default, this is implicit and varies by team.  Imagine when an early career developer joins a new team.  The way the team works would be new to them.  They will likely get onboarded and work with the team to acclimate.  How much of what they need to learn is explicitly defined?  From my experience, very little.  It’s expected that the new hire will pick it up.  Consider whether there's a more efficient approach.  Senior developers are likely to adapt quickly by recognizing patterns that are familiar or unfamiliar to them.  Our new developer won’t have that wealth of experience to draw upon.  More concretely, they wouldn’t know what they need to learn, let alone how to do it if everything is implicit.

Making the implicit explicit addresses this directly.  I compare this approach to cookbook recipes.  To someone with basic cooking knowledge, a well-written recipe enables them to learn how a dish is made and ensures that they follow the steps in order with the right technique.  A less effective recipe will be vague which forces the cook to decide how to execute a specific step.  Not only will this slow down the cook as they try to make sense of the step, but they are also prone to choosing a different technique that may lead to inconsistent results or ruin the dish.

In thinking about helping our team members be more effective, we lay out the specifics of how we do our work. I’ll give an example that I’ve used with my teams over the years.

Team Guides

When I ran my software consultancy, I started an apprenticeship program. We developed team guides that explicitly defined the work the team did so that entry-level developers would have structure to follow.  I think of these as SOPs (standard operating procedures), and they are the essence of making the implicit explicit.  To an early career developer, this was gold.  They could read through the steps and ask questions about anything they were unfamiliar with.  It worked ideally when they paired with their mentor.

I’ve brought this approach to my teams over the years, it evolved at HashiCorp into what we called the Project Lead Guide. It was a collection of steps and techniques for the technical lead of a project.  It functioned like a checklist for experienced developers and a how-to guide for those new to leading a project. It led to consistency of execution and more predictable delivery on several teams.     

Adoption

Now you may be thinking that building these explicit SOPs is too much work that you and your team can’t afford to invest in.  I’d agree that the time commitment and effort may feel too high if you were to ask one person to write up all things implicit.

Luckily, there’s an easier approach you can adopt that yields results immediately.  When someone new joins your team, have them document the steps they go through to perform a common team task.  There may be some lightweight documentation in an onboarding doc to build upon.  Great.  Have them flesh this out with their onboarding buddy.  As a new team member, they can verify that these steps allowed them to complete the task.  Have another team member review it to see if anything is missing.  Then share it broadly with the team for final review before updating the onboarding materials.  Pick the next common task. Rinse and repeat.

Benefits

There are many benefits to doing this.  

First, it will supercharge the addition of new team members and help them become effective contributors faster.  It will reduce the cost of onboarding as new members can self-direct their activities effectively.  If they get stuck, it’s a sign to improve that part of the docs.

Second, I’ve seen many times that existing team members realized they weren’t following all the steps consistently.  Conversations would start about a specific step and why we do it a certain way.  A healthy and informative debate would follow where all team members gained understanding.  

Third, by having work explicitly defined, the team can easily review and change a step.  They can get a baseline for the effectiveness of a step, propose a change, and measure the improvement.  If it improves the process, they can adopt the new approach.  If not, now they know. 

Fourth, this is empowering.  The collective team can own the improvement of how they work versus it being a top-down directive from leadership.  As an engineering leader, I’m there to guide them on the process and help things along if they get stuck.

While I’ve focused most of the improvements on team effectiveness, there’s another benefit that has been the secret sauce for my teams and is dear to my heart: it helps people grow. With explicit structure, team members can identify steps that they would like to improve.  Oftentimes, there are success criteria they can use to assess the quality of their work.  This makes it easier to have coaching conversations about how to grow.

Specifically, I’ll touch on the Project Lead Guide above.  One of the biggest shifts I saw with my teams was that it made leading a project less mysterious.  This gave developers confidence to try leading their first project knowing they had this step-by-step guide they could refer to.  We supported this with general encouragement for developers to try their hand at being the project lead. We’d pair them with an experienced lead who would mentor them as the project progressed.  As I mentioned above, it led to more consistency in project execution, fostered leadership skills, and brought the team closer together.

This pattern of making the implicit explicit is a strong tactic for building culture, improving execution, and growing your team.  I encourage you to explore how you can incorporate this into your team today.