Habit 2: Cover and Move
#managing_others Teamwork makes the dream work, but ?
This article is Part 3 of 4 in the 3 habits of highly effective organizations series
As I write this, a war is happening between Russia and Ukraine, so I want to use my military references with care and acknowledge that building software, managing software teams, and building a business has none of the stakes of an actual war.
However, I think it’s useful to acknowledge why military terms are often used in software development and why Habit 2 refers to a military concept called Cover and Move.
Military operations can be complex, involving multiple people tasked with the mission they need to accomplish and the broader goals of the campaign they are involved in. Sometimes individuals or teams of individuals can operate independently, but more often than not, cooperation is necessary to support each other’s objectives to advance the broader goals of the campaign. Imagine a group of soldiers running opposite directions to achieve their objectives while the enemy shoots at them. They may be running hard, but they are going nowhere fast!
Similarly, software organizations - from the six-person start-up to the multi-hundred product development organization - have similar dynamics. Software is, after all, produced collaboratively. For non-technologists who ask me what writing software is like, I ask them to picture writing a compelling story, without grammatical mistakes, cohesively and coherently with several people in a giant Google Doc. This is not easy to do well, certainly without cooperation either as an individual or as a team presenting a functional area. The unfortunate trend that has pervaded the industry since as far as I can remember is that an engineer’s work is measured in the volume of their output in terms of lines of code produced. It isn’t. In truth, it is measured by the impact of the code’s expression on the team, the organization, the company, and its customers. Like co-authors writing different parts of a book, an organization whose engineers are not in sync will produce something that won’t be a great product even if you get a lot of output.
One of the most popular business books to acknowledge similarities between operating a military mission and running a business enterprise is Extreme Ownership: How U.S. Navy SEALs Lead and Win by Jocko Willink and Leif Babin. In the book, Jocko describes the first law of combat as “Cover and Move,” which refers to how the military solves the challenges of having individual teams advance their objectives while supporting the broader collective.
In the military, teams or individuals coordinate and decide who is moving and who is covering (supporting). When someone moves to a new position to advance their goals, someone else delivers suppressing fire to protect them. In a different moment, the roles could be reversed. While not everyone moves simultaneously, identifying who is moving and who is covering eventually allows everyone to advance their objectives. Whereas if everyone went ahead and moved without coordination, they might get hurt and ultimately fail in their mission, and collectively everyone fails.
When organizations fail to identify who has priority and who the supporting cast is, they are just as likely to fail as the military unit that moves without cover and adds more unknowns to the complex battle space in which they compete and operate.
Cover and Move in Software
Before we discuss how highly effective teams implement Cover and Move, we need to go over some prerequisites and assumptions. From there, we review how the Cover and Move orchestration works.
Prerequisites
For this discussion, we assume that roles and teams are durable. That is, people know who to go to for what. If individuals or teams have continually shifting responsibilities, it will be impossible to orchestrate work systematically.
Further, we assume that there is someone who can decide who covers and who moves and that this person doesn't shift for any given project. Decision-maker shift creates an environment where nobody knows who to follow anymore.
Finally, we assume that the decisions are generally durable. For simple projects, the cost of changing your mind is relatively low. However, as complexity increases in the form of more people involved, more dependencies between people, and more limiting steps, the cost of changing course skyrockets.
If you don’t meet these prerequisites, the uncomfortable truth is that you have a management problem. Hopefully the challenges aren’t above your pay grade! If you’re ready to scale, then read on.
Step 1: Identify who does what
Before you begin, it’s important to identify the actors involved in a given project. There’s an entire section in Wikipedia dedicated to these frameworks under “responsibility assignment matrix,” but for the purposes of making this discussion concrete, I will use DACI.
Driver - Who is the person that is accountable for making sure the project succeeds? In some organizations, this individual is also called the responsible party. This should be one person.
Approver - If there are decisions the driver isn’t allowed to make unilaterally, then who approves?
Contributors - Who are the individuals doing the work?
Informed - Who would notice or needs to know about this project to do their job?
For small projects, you can get away with a handshake agreement. However, I strongly advise leaders to document a DACI at every opportunity, regardless. A DACI that is documented is an artifact that provides context on the origins of the effort and the initial set of actors, which is useful for those who build on top of the project later.
Step 2: Sequence the work
In an ideal world, you want to do as many tasks in parallel as possible. Perhaps at first blush, critical dependencies abound. A product marketing team won’t be able to generate marketing materials for a new product launch if a demo-ready build isn’t available. A front-end team may need a back-end team to implement a set of APIs that return data to complete the customer experience.
Teams must communicate with each other to deeply understand how many of these perceived dependencies are true, and if there are ways to do work in parallel strategically. Perhaps the marketing team doesn’t need a demo and needs screenshots. The front-end team may be okay with calling a public endpoint with mock data.
Thankfully most projects are not all linear, and there are usually more steps than there are teams or people to pull off the project. So invariably there is a decision to make: What do you do first? Which sets of challenges do you tackle earlier in the project?
Fortunately, Ryan Singer at 37Signals has an elegant solution for helping us decide in the following “Hill Chart” via the Shape Up development framework:
Singer observes that most projects have two distinct phases. There’s the initial part of the project where you’re figuring things out; as core problems are resolved, unknowns are uncovered, uncertainty is reduced, and the project begins to have momentum. Once you’ve crested this hill, progress suddenly feels easy.
In light of this, leaders must sequence core tasks and novel problems ahead of ancillary problems and known work, or risk taking on unnecessary uncertainty. The reason is that delaying what seems hard extends the time the project will spend figuring things out. During this period, it should be expected that any estimates a team provides are only loosely trustworthy.
Inexperienced leaders often use burn-down charts and ticket resolution rates to prove a project is progressing. In truth, the number of tickets is almost always proportional to the people you have on the team. The predictability of any ticket getting done within its estimate has more to do with where that ticket is on the hill. As a result, burn-down charts only take on meaning when you’re going downhill and making it happen.
Highly effective organizations and veteran leaders understand this; they invest the time to sequence the work and encourage teams to conserve energy and resources to climb the hill as quickly and effortlessly as possible.
Step 3: Gather Guesses
Once you have identified who is doing what and in which order, the final step is to gather guesses as to how long each step will take. The more common term “gathering estimates” belies the fact that there is significant uncertainty at the early stages of any project.
However, these guesses are collectively useful because they serve as way points for the project. If the steps are sequenced correctly, the earlier way points will likely be less accurate and require more frequent resets along the project journey. Still, the precision will increase as the journey approaches its end, creating predictability for when the project completes.
For these reasons, gathering guesses need not be a high-precision exercise because precision comes naturally if novel and core milestones are scheduled early.
Step 4: Traffic Control (Optional)
For organizations comprising multiple teams, products, or even companies, several cross-cutting initiatives and projects may depend on the same company, product, team, or even individual!
As a result, you might not only find yourself in a position where you are trying to understand who does what and when for a given project:
Who x When
You suddenly are solving this problem times multiple projects!
Who x When x # Projects
The complexities of this type of optimization exercise should be avoided as much as possible, but it is understandably unavoidable.
Assuming you have to operate several projects at once, you will find yourself in the business of traffic control. Just as traffic control coordinates planes in the open sky and ensures that each plane lands at a certain time so that customers can catch their connection, you will also need to do the same for your organization. Instead, you’ll be working with teams to make sure they are tracking to their plans, getting revised guesses as appropriate, and re-balancing schedules as needed.
A central planning function such as this typically compromises of four motions:
Data gathering: The office works with teams directly to execute Steps 1 - 3 above.
Monitoring: On a regular cadence (perhaps as often as bi-weekly), teams are audited to understand if they are trending in the right direction.
Reporting: Progress is summarized and reported to all stakeholders or the entire company regularly (perhaps as often as weekly), situation depending.
Re-routing: For material changes to the plan, the office escalates the incident to the executive team and other senior stakeholders and works with the DACI and executives on the remediation plan to course-correct all in-flight initiatives.
As a CTO/CPTO, I’ve experienced situations where the business has had more than 30+ priorities. The rationale is often that if we have so many people, why can’t we do several things simultaneously? Hopefully, as this article attempts to demonstrate, the devil is in the individual project details of each ask. Moreover, traffic control can be bureaucratic. By definition, having to do multiple things at once is fundamentally inefficient; invariably compromises will need to be made regardless of how well you orchestrate multiple projects to use the same resources. One of the axioms in warfare is never to fight a two-front war, but the modern company will often take on multiple fronts simultaneously.
On the other hand, focused organizations have outsized outcomes, and I am grateful to have experienced this firsthand.
Years ago, I was hired to work on mobile at Netflix before the streaming boom. We had a fledgling iOS application and Netflix was primarily a DVD-by-mail company then. Our application constantly suffered from poor reviews because customers wanted to manage their DVD queue in the application. However, every time I approached Reed Hastings (then-CEO of Netflix) about this he would deny my request and urge me to focus the team on our streaming effort. Reed believed in relentless focus; in his mind, streaming was the company's future. Ultimately, Reed was right. By focusing the company on building the world’s best streaming platform, Netflix has grown manifold since the times I was there.
Big Dreams, Bad Teams
Have you heard of the phrase, “Teamwork makes the dream work?”
This phrase comes from the book by the same named authored by John C. Maxwell. What many people don’t know is the full quote:
Teamwork makes the dream work, but a vision becomes a nightmare when the leader has a big dream and a bad team. - John C. Maxwell
Highly effective organizations realize that having big lofty goals is a necessary condition for success, but fancy speeches and big dreams aren’t enough to achieve extraordinary outcomes. Some may wonder if extraordinary individuals will guarantee success? Unfortunately, the start-up world is littered with stories of unicorns who built teams of geniuses who accomplished nothing.
A big dream and a bad team is one of the worst working environments a person can experience. This is why effective organizations invest in enabling teamwork and consider it critical to their success.