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.
Autonomy without alignment
What happens when people know where they’re supposed to end up, but don’t have a shared sense of how they’ll get there? Imagine two families who’ve decided to take a vacation together. They both know they’re headed to Disney World, but they haven’t discussed when they’ll head out or which highways they’ll take. Are they leaving on the 5th or the 6th? Where will they stop for dinner along the route? Are they meeting up at the hotel or in the Disney World parking lot? The possibilities for miscommunication are practically endless.
Now, consider an engineering org that’s decided to move to structured logging with a standardized schema. Historically, each team has generated logs in whichever format they preferred, but the architecture has reached a scale at which this multitude of logging formats makes it difficult for engineers to understand what the system is doing in production. In response, leadership has charged the platform team with leading the migration to a shared logging schema.
After some initial planning meetings, the team comes up with a schema for the logs, along with a roadmap for the migration: They’ll create a shared logging library for emitting logs in the new standard schema; deprecate usage of existing logging libraries, requiring teams to use the new library for any new logging calls; create adapters to transparently map the deprecated logging calls so they emit the new structured format; and, over time, replace usage of the deprecated logging libraries with the new structured logging library.
When the platform team announces the initiative to the rest of the engineering org, they focus almost entirely on the final destination. The message is essentially, “We want to migrate all systems over by the end of the year, and we’ll need your help to get there.” They neglect to share the roadmap for achieving this end goal, mistakenly assuming it would be an unnecessary level of detail.
What happens next? An architecture free-for-all. Two product delivery teams rush off in excitement and start building their own logging libraries based on the new schema, unaware that the platform team was about to roll out a common library. Another team dedicates a sprint to converting all of their existing logging calls to the new format, not realizing that the platform team’s plan to create adapters will render this work unnecessary. The absence of aligned autonomy, in this example, leads to a whole lot of wasted effort.
A coherent, organization-wide understanding of both what needs to be done and why it needs to be done is fundamental to aligned autonomy—and clear, intentional communication is the key to achieving it. Engineers should be able to connect the dots and transition smoothly between levels of detail. Low-level tickets in an individual team’s backlog should link back to program-level objectives in the strategic roadmap; decisions laid out in design docs should refer back to overarching architectural principles. When engineers can connect specific tasks to a comprehensive set of goals, they become empowered to work both independently and with a sense of shared purpose.
The journey and the destination
Most of the examples I’ve laid out here describe larger architectural initiatives, but you can harness these communication and documentation strategies for projects within a single engineering team, too. These principles can support smaller technical projects, like building out a new data caching mechanism, as well as process and organizational changes, like moving from scrum to kanban, or from a centralized data engineering team to an embedded model.
Even the best-laid plans are likely to evolve over time. But when we start from a place of shared understanding of both the strategic goals and the roadmap, teams can evolve in tandem, working toward their objectives with alignment and focus. No roadblock is too big to handle, and changes in the plan are part of the adventure.
This article further explores some of the ideas put forward in the author’s blog post “Roadtrip!”