Road to somewhere

Leading a group of engineers toward a strategic goal is like planning a road trip. You need to articulate the final destination: We’re going to Disney World! (We’re moving to Kubernetes!) You also need to determine the route: Are we going via Montana or Texas? (Are we going to port our monolith to run on Kubernetes, or are we going to break it up into smaller services first?) Finally, you need to provide detailed directions: We’ll stay on highway 90 until Sioux Falls, then we’ll get on 29. (We’ll start by running our notifications service on managed Kubernetes infrastructure, then incrementally move our more business-critical systems over.)

A successful road trip requires that everyone in the car understands the journey and the destination. How else will the kids know whether to pack swim trunks or parkas, or the grown-ups know which towns to book motels in? Similarly, when executing on a strategic initiative, engineering teams must be on board with the end point, or strategic goal, as well as the roadmap for getting there. But that’s not as easy as it sounds. Plans can become inflexible, leaving engineers incapable of taking shortcuts or avoiding roadblocks. Teams might lack a clear sense of how their work ladders up to the company’s objectives, making it difficult for them to make progress or support one another.

Intentional communication, including providing the appropriate levels of detail at each stage of the journey, can help avoid these pitfalls. Prioritizing clear direction empowers engineers to bring their unique strengths to a plan, work with purpose, and act autonomously. The goal is for teams to understand a plan so innately that, even when acting independently, they’re acting in concert what I call “aligned autonomy.” This sense of frictionless alignment can transform a plan from fragile to robust, just as it can turn a road trip from a stressful experience into a marvelous adventure.

Plans without goals

Imagine a driver who’s only been given detailed directions for the first few hours of their trip. They know which highways to take, but not where they’re supposed to be by nightfall. Suddenly, they encounter a traffic jam. They can either stay the course, hoping the traffic will clear, or try another route in the hopes that it will get them where they’re supposed to go wherever that is more quickly. If they guess wrong, they might end up on a faster route to the wrong destination.

A similar scenario often plays out on development teams. Engineers might receive a detailed plan from leadership including epics and stories, perhaps with detailed design documents but aren’t given enough context to understand the strategy behind those plans. Maybe leadership wants to avoid “distracting” them with the broader objectives, or maybe they believe that by sharing a plan’s individual steps, they’re also sharing its ultimate goal. This is a mistake. Assuming teams don’t need a clear objective to work toward, or that they’ll correctly infer the overall strategy by squinting at a collection of Jira tickets, is like handing a list of turn-by-turn directions to a driver and expecting them to understand where they should end up by nightfall.

Say an engineering team has been handed a plan to migrate their service’s data store from MongoDB to Postgres, but they lack a clear understanding of the rationale behind the migration. If they run into problems during the process performance challenges with the shift to a relational model, for example how should they adapt? That depends on the objective. If the migration’s goal is to standardize on Postgres, they should probably power through and invest in learning how to add indexes or denormalize their schema. But if the aim is simply to move off of MongoDB, they might consider another data store with different performance characteristics. Determining the best path forward is difficult when you don’t know the desired result. 

Communicating strategic goals can be tricky, and doing it well takes care and forethought. This includes selecting the mediums best suited to articulate the strategy. Formats oriented toward the mechanics of planning Jira task reports and Excel sheets, for example aren’t great for illuminating a plan’s objective. In contrast, structured documentation like requests for comments and product requirement documents are able to convey design decisions alongside the reasons those decisions were made. Likewise, a technical diagram or wireframe can encapsulate the entirety of an idea in a way a list of acceptance criteria never will.

Distilling a strategy into one or two core visuals or catchphrases that can be shared across contexts, such as wiki pages, all-hands presentations, and planning meetings, is an effective way to communicate overarching objectives. At one company I worked for, the VP of engineering started every presentation with a slide sharing the engineering organization’s mission statement. Within a month or two, pretty much everyone at the company understood exactly what the engineering org was there to do.