Be Descriptive, Not Prescriptive

Developing direction that is descriptive of an end goal or outcome, rather than overly prescriptive of a solution, can be challenging. Military culture includes a concept known as the commander’s intent, a succinct description of what constitutes success for a given mission. It contains the five Ws: who, what, when, where, and (most importantly) why the mission is being executed. Notice that the commander’s intent does not specify how the mission will unfold. The reason for this is simple: a commander is situated far from the action on the ground, ignorant of the realities of terrain, weather, logistics, and more. Central command is responsible for driving large objectives that may be made up of interlocking missions, such as controlling a specific bit of territory by one group to defend another. Units on the ground often lack the larger context of other units, and so the chain of command leaves them a certain amount of freedom to act to achieve their objective, but not to invent their objective themselves.

I find this metaphor helpful when crafting direction for collaborative teams. It speaks to lines of authority that are useful, rather than micromanaging, while allowing teams to act with a degree of autonomy in a loosely coordinated fashion. Especially in large organizations, this interdependence is critical to being efficient with resources and allowing for the interchange of data and information, whether literally in terms of APIs and subsystems, or figuratively in terms of what’s true across the organization. Establishing a commander’s intent–like objective gives teams the freedom to decide how they will achieve the goal, but also allows for cross-coordination about the what, why, and when involved.

When working with leaders who tend to be overly prescriptive in their objective setting, invoking the five Ws of the commander’s intent can help bring clarity, and has the advantage of making the team look like they’re trying to make use of the chain of command rather than undermine it. If you think about some of the less helpful directives you’ve been given, they often consist almost entirely of overly detailed “hows” while being quite light in the other dimensions. Help leaders and teams alike to describe the objective better and get everyone off on the right foot.

Have a Sense of Urgency

Good objectives will help teams understand what’s at stake in the effort and provide a sense of urgency to keep it from devolving under pressure. One example of how a sense of urgency is helpful comes from John Rosenberg, an ER doctor serving patients in Oakland and Richmond, California. He supports a lower-income population that faces tough challenges daily, many of them life-threatening. Not only does he treat patients who are suffering the effects of a trauma or major illness, but he also sees those grappling with mental health issues, domestic violence, and more.

In this setting a doctor like Rosenberg is expected—and required—to work with many different kinds of people, from technicians to nurses to administrators, to handle a case. In some cases, say a problematic pregnancy that requires immediate intervention, he may have upward of 20 people directly involved in the care of the patient: NICU specialists, OB specialists, nurses, family members, and more.

When asked how collaboration happens in an environment with that many stakeholders, many of them experts in their field, with the clock ticking and someone’s life on the line, he said, “It comes down to having clear roles and clear guidelines for what we choose to do.” He describes his mental model of emergency medicine as a type of “algorithm,” where the team looks at evidence and then considers a small number of possible actions in response. Rosenberg says what enables the team to work this way is the clear focus on the life of the patient above all else. The ER can be an intense setting with a lot of moving parts: “It’s really chaos in there, when everything is happening. There so many people and things move so quickly, but we know that the patient is our main focus. When I am the primary doctor on the case, I need to make sure that no one loses sight of them,” he says.

Most collaborations in business aren’t literally a matter of life and death, but almost every objective in business seems urgent. Certainly pressure to “deliver” is omnipresent in business. But the drive to complete things quickly often masks the actual reasons why solving the problem is critical. Looking deeper at collaborations that struggled to engage a wider group, I often found that there were real things at stake, but the “brief” given to the team focused less on those critical outcomes and more on outputs. Teams must know what happens if they fail, or if they make poor decisions, to be properly motivated to overcome interpersonal dynamics and keep up their stamina for the duration. Consider that “failure” for many collaborations may mean that a siloed Band-Aid solution is created, or that the group loses steam or is consumed by conflict until it dissolves and people retreat back into their silos. It’s helpful to think about what would happen if you did nothing as another way to understand what’s at stake.

Ground Objectives in Solving Real-World Problems

We may often think we have a sense of urgency in our efforts because of that dreaded workplace reality: deadlines. While timeboxing and deadlines have their place, they alone aren’t enough to create the radical clarity and alignment that Rosenberg sees in the ER. Sara Ortloff Khoury, head of UX for Google Hire, found herself facing great pressure when she joined a startup that, like many, had a general sense of the domain they wanted to serve but hadn’t yet developed a clear focus on the product offering. The team had done enough investigation to know that the current tools used by recruiters, HR professionals, and hiring managers were overly complicated and disliked by many—a market ripe for disruption. Their competitive analysis was thorough and clearly pinpointed places for improvement. But, as Khoury began to realize, while knowing what you aren’t doing might be helpful, it’s hardly a rallying cry.

Khoury knew that the team needed a better objective, and her experience in the industry taught her a sure-fire way to find one: focus on the users who will be served by the collaboration, rather than on the competition. She knew that understanding people who do hiring would help the startup focus on alleviating those users’ frustrations, and that her team needed to feel that frustration firsthand to have a sense of urgency about something other than “ship fast and frequently.”

Defining objectives as the solving of specific problems for specific users is one of the best ways to create alignment and purpose in a team. User-centered design and “talking to users” are a core part of many teams, especially those that include experienced design- and UX-focused members. But in many of the collaborations I have seen and studied, that work can happen off to the side or be done by specialists, and isn’t always taken to heart by the team. Khoury decided to change that and enlist her team to identify more deeply with their users.

At the same time, the startup was being acquired by Google, which brought in a whole new set of stakeholders and opinions that needed alignment. Clearly, Khoury wasn’t going to bring dozens of people into primary research with potential customers, but as it turned out, she didn’t need to. When the team came back together to look at what they had learned, they found they had a clear, focused objective that had been there all along: people didn’t want more features or a better version of the tools they had; users were frustrated by systems that had very rigid flows and business process rules to support work that was often personal and highly varied. The team saw how tools meant to help a process had in fact slowed things down as users added head count and workarounds to support the tools, instead of being supported by them. The problem wasn’t with the tools themselves, but rather the gaps and walls between them.

Getting a team to understand what’s at stake can be challenging when specific problems or opportunity costs aren’t clear or haven’t been quantified. Grounding your work in solving problems for people and understanding the stakes (as exhibited by the “pain” users experience) is a better way to make objectives real than meeting specific metrics or leading indicators.

Derive Objectives from a Problem

While the commander’s intent is a useful construct to think about setting direction, we can be more specific about what exactly an objective that isn’t overly prescriptive looks like. Figure 6-2 shows a framework I use to create objectives. You can use this to create your own objectives and set a vision from scratch, or to back people up from solutions to divine more helpful objectives.

Figure 6-2. Deriving objectives from the problems you are looking to solve and the vision you want to bring about

First, ground your team in a problem (see the sidebar “Defining the Problem” for tips). That’s a good way to ensure that the work holds value. In the previous section you saw how understanding the customer you’re serving helps you create a compelling vision of the future to aim for. (That said, there are times when you’re not so much facing a clear problem as trying to avoid opportunity costs.)

Turn Problem Statements into Objectives

Once you have a clear understanding of what problem you’re solving, you can flip it around to create a vision statement. What would it look like if that problem were solved? What would be enabled? What would be avoided?

These two pieces are helpful to express clearly because the team can turn back to them when they’re stuck or if something they tried doesn’t work. The problem and vision statement don’t say what the solution is, but they describe the outcomes that are needed.

Next, frame useful objectives by having a clear sense of who benefits from the objective, what that benefit is, and what root causes have been addressed. If possible, set a goal for when the problem will be solved.

The template I use is shown in Figure 6-4.

Figure 6-4. A template for stating objectives

Here are some examples of objectives that use this format:

By 2020, Californians will impact climate change by transitioning to fully renewable, carbon-free energy sources.

Customers who are financial novices will have increased savings and greater confidence in their ability to save money when they see suggestions for less expensive products and services that they regularly buy.

Employees who commute more than 20 minutes each way to work will be more productive when they can choose to work remotely, or use transportation that allows them to work while commuting.

Finally, success criteria are also important to state clearly. The simplest way to think of success criteria or key results is to ask, what indicators would tell us that the problem is solved or getting better? These can be very quantifiable or qualitative, depending on what you can actually measure. Don’t throw away leading indicators that you think would be good success criteria, even if you can’t measure them. With time and persistence, you may find a way to get that data, and then you can replace criteria that aren’t good predictors but are easy to measure.

Refine Objectives to Be More Useful

In his book The Logic of Failure (Basic Books), Dietrich Dörner shows how goals can be formulated in useful and productive ways. He lays out key characteristics of goals, and their strengths and weaknesses, along some key axes:

Positive or negative

Goals can be statements of what you are trying to achieve, or conversely, what you want to avoid. It’s better to specify goals positively, however, because they will be more specific (see the next point) and will serve the team as a more productive starting point.

General or specific

General goals are often where we start out—stating a view of what we’d like to see, but without a lot of details. Being as specific as possible without being overly prescriptive helps teams focus their energy and makes outcomes more measurable. Where possible, create specific statements of the objective, even if that specificity evolves over time as you better learn what will support the objective.

Singular or multiple

Some goals stand on their own, with a single outcome being chased. But very often, we are dealing with complex systems where one objective relates to another, and not always in a straightforward way. Look to simplify or prioritize complex goals where possible, but avoid oversimplifying goals in pursuit of clarity.

Implicit or explicit

One of the biggest traps teams fall into is having implicit goals that go unstated, only to arise as a key factor once they begin testing their solutions. Where possible, strive to clearly state goals, even if they seem obvious or are assumed to be shared.

These refinement techniques can be applied to objectives that you have developed or to objectives that you have been given as a starting point. For example, imagine you are asked to create a system that:

• Helps charitable organizations grow their audience and raise funds from more people

• Is easy to use

• Is less expensive than currently available tools

The first goal seems clear enough; it’s positively framed and mostly singular. But it’s a bit general, and could benefit from some details about how much more money and people we are talking about. There’s also an implicit idea that all charitable organizations are actually seeking to reach more people, rather than raising more funds from a smaller base. Those two things are linked objectives here, but ones that we might want to learn more about as we go.

The second goal more obviously needs help. “Easy to use” is a goal teams are given often. We acknowledge that making things that are easy to use will help us sell them and gain loyalty from customers, but can we do better here? What about “Requires no training”? That’s nice and simple, though it is negatively framed. It might be better to add, “Self-guided exploration is enough for people to use successfully.” That’s clunky, so keeping the headline of “Needs no training” may be preferable, but you can use the more specific, positive expression when you’re evaluating whether your solutions actually need this objective.

The last objective is general, but it does have some comparison points to existing tools. It’s not very useful for a team getting started, however. This might be an objective to keep an eye on to understand what drives costs and then state that more clearly, as in “Requires only X customer service agents per Y customers.”

See the sidebar “Refining Objective(s)” for further advice on structuring your objectives to be more useful.

Use the “Whitepaper Approach”

Under Jeff Bezos’s guidance, teams at Amazon take a very thorough approach to capturing and sharing objectives. For major initiatives, especially those with a lot of context, teams produce a short, three- to five-page whitepaper laying out the challenge and the objective for their work and use that to plan and review different workstreams. This approach is also used by Michael Sippey, Head of Product at Medium, to help himself as leader keep track of many interrelated efforts at a macro level. The whitepapers his teams use are simple arguments about what work the team thinks is necessary, and why. The whitepapers also describe a theory about what tactical moves the team can make to achieve their goal. While writing a short essay may seem like a lot of work, this technique is embraced in many companies because it forces the team to fully think through their argument, rather than writing a few bullet points.

One benefit Sippey calls out is how it changes the dynamic in the room so it’s more conducive to good critique than using slides would be: “Slides suck for actually helping people comprehend an argument, because the only person who has the context is the presenter. It always feels like trying to ask a question results in, ‘Wait for the next slide, I’ll get to that,’” making it hard to put the full picture together. He also appreciates the use of time together more. “Being together [in that way] reminds you of the camaraderie in the team; it makes people act better, and forces me to be more thoughtful,” he says. This isn’t to say there isn’t dissent, but it will tend to be “the thing about the thing,” rather than personal attacks. If he does have particularly harsh feedback for a team or an individual, he tends to communicate privately to avoid “trashing anyone in public.” This, in turn, bolsters the quality of critique without sacrificing rigorous debate.

At Google, many product teams use the whitepaper approach to guide executive reviews of work being planned. Given the scope of what the org covers—billions of users, tens of thousands of employees—they need a way to build a shared understanding of priorities, and support executives in making critical decisions or approvals. Teams are charged with developing whitepapers about who they served, what key insights they’ve discovered about the market, and what types of features should be developed to best meet the demands on their product.

Those I spoke with had many different ways of creating whitepapers, such as empowering a single author that asks for input on drafts or having a team fully co-create the paper from notes on a whiteboard through to a finished draft. For teams who don’t have some stability and experience around the work they are doing, co-creation may be a great way to build that. For teams that have fewer unknowns about the future of their product, it might be fine to empower a single author who gets reviewed.

If the whitepaper approach is one you want to try or one you are already doing, consider shifting the dissemination and reading of the whitepaper ahead of the meeting time you have set up. Especially for those with learning disabilities, those first 10 minutes of silent reading may be disquieting and unproductive. Dyslexics are quite capable of reading many pages of material, but they may prefer to do it through their ears by using text to speech, or to have their own time and space to process, rather than reading in public. This can also be helpful for nonnative speakers of the dominant language who, having to rely solely on a presenter or a short, fixed time to read, could be at a disadvantage.

It is also a good idea to make sure that the request to write a whitepaper is framed as an exercise that serves the team—and it should come from those closest to the problem, not a lone product manager laying out their view or seeing it as a long-form status report. When teams write whitepapers for executives, rather than to get clarity for themselves, the quality of the argument may not be as high. Besides, a thesis generated by and for the team will naturally satisfy executives too.

There’s nothing wrong with stating objectives in a short format versus the whitepaper approach. What’s important is to develop clear objectives and know how to measure them. How you choose to socialize them and help others internalize them can vary.

Overly Prescriptive Direction

It’s very common that when faced with a question, people offer specific solutions versus general criteria about what a good solution looks like. For teams who need to be able to explore different possibilities and gather data about what works from a realistic trial, this can be challenging—especially when the solution is given by a senior leader or expert whose opinion is respected, or whose authority is intimidating. More often than not, when the CEO tells you their solution to a challenge, they are offering an example meant to inspire investigation, not an order. I’ve watched teams jump through hoops to implement a leader’s idea, only to be surprised to hear them say, “I didn’t mean it literally!”

The tendency to speak in terms of tangible solutions also results in a run-off between different guesses about what will work, even if they aren’t easily comparable. This can turn discussion into a popularity contest between ideas or those who offer them.

Consequences Not Clear

When the team doesn’t know what’s at stake, the interpersonal dynamics can turn into conflicts when things get challenging. If the group doesn’t have the equivalent of a patient whose life is in danger, fear of failure can make them turn on each other.

Constant Questioning of Objectives

In some groups friction arises that keeps them at square one, continually debating assumptions rather than developing hypotheses that can be tested to turn unknowns or guesses into something concrete. At its root, this behavior stems from fear—fear of being wrong and facing the consequences of failure. At times, this can also happen when the group lacks experience with developing hypotheses and experimentation.

Juking the Stats

The epic television drama The Wire, about crime and life in Baltimore, has several great set pieces about “juking the stats,” where cops focus on getting the numbers right, by any means necessary. “You make robberies into larcenies,” says one of the characters. “You juke the stats, and majors become colonels.” Watch out for teams that chase the numbers but lose sight of what those metrics were really supposed to indicate.

When I led product management and development at GreatSchools, a Yelp-like website with ratings and reviews for every school in the US, we worked hard to get schools to supply more information about themselves on the site and engage with their families to strengthen the school-home connection. Our target of having a certain percent of schools claim their profile online was ambitious, and reaching schools difficult. The team hired several people to scrape the web for information to display on the site. While it increased the data we had, it failed to reach the real goal—connecting schools and parents.