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.
Tools to Create Clear Goals and Objectives: Refining Objective(s)
Once you’ve got a clear statement of the problem and the objective(s), go through and refine them along the axes that Dörner’s research identifies. The framework in Figure 6-5 can help structure discussions about objectives to make them even sharper.
Positive or negative. If you have an objective that is expressed as something to avoid, try to frame the objective positively instead. Having negative objectives or a sense of what to avoid can be useful, but try as well as you can to pair negative goals with positive ones. Can you frame the objective as something to be created, with the negative objective as a limitation or threshold to keep in mind? For example: Create new sales channel while not reducing the existing channel more than X%.
General or specific. Rephrase general statements about the outcome, like “improve the experience,” in more specific terms. This is a good place to bring the success criteria you’ve identified into the picture and see how specific you can make them. You might make an “easy to use” ordering system objective more specific by describing things like responsiveness, time to learn the system, how well users understand the status of their order, and so on.
Singular or multiple. If you (likely) have some interrelated goals and success criteria to address, see if you can prioritize or rank them. You may also need to model how multiple goals relate. For example, if you want to introduce new capabilities to the market, you may also need to pay attention to decreasing usage of existing offerings and impacting revenue adversely.
Implicit or explicit. Look for implicit goals by asking what is being taken for granted. List out things in the environment or system that would be problematic if they didn’t exist, and make sure you acknowledge them as explicit parts of the solution.
Additional audiences. See if there are other users or interested parties that weren’t originally identified that need to be taken into consideration.
Figure 6-5. A framework to help you refine objectives to be more useful and specific
Learning to refine and express objectively more clearly is a key part of mastering collaboration. This can and should happen up front, as you are getting started, but as we’ve seen, many times we need to revisit our goals as we work to incorporate what we’ve learned. It’s also common that we don’t see our implicitly assumed objectives until we get into the work and start to see things we took for granted at the outset. Make time not just to set clear objectives, but also to revisit and refine them as you go.
Keep Track of Knowledge and Assumptions
Especially at the beginning of an effort, setting objectives may require the group to make some assumptions about the problem, its causes, and what a vision of success would look like. This can feel uncomfortable for some who fear making a misstep. Others are all too happy to make assumptions and never look back. Keeping track of the assumptions you make and supporting them with data and facts as you go is critical (see the sidebar “Expressing Assumptions” for more on this topic). Assumptions are often made implicitly and left unstated, which can lead the group astray. When assumptions are met with evidence to the contrary, they are hard to change if they aren’t made explicit. Instead, the group can tend to devolve into debate about the evidence that is more visible. It’s a good idea to always pair stated goals and obj
ectives with key assumptions. If we revisit the earlier example about helping charitable organizations, some key assumptions are being made that people understand the value of giving to charity, and that we can acquire customers by converting them from existing services easily—both things that could easily be tested to see how they hold up.
Tools to Create Clear Goals and Objectives: Expressing Assumptions
Having good raw material about your problem is key, but it can also be helpful to express the problem in a consistent way so the different components are transparent to others. Refer back to the simple template in Figure 6-3 for stating problems clearly.
The next step is to analyze how you know what the problem is and what causes it. There’s nothing wrong with making guesses or hypotheses about what’s happening, as long as you keep track of them. Lead the team through a discussion about what information is based on evidence, and what is anecdotal or assumed. This allows you to refine how you express your problem and keep assumptions top of mind (see Figure 6-6).
Figure 6-6. Analyzing how you know what the problem is and what causes it
Now that you understand the problem and have expressed it clearly, you can invert it to create statements about what you want to achieve to solve it.
Define the objective(s).
What is the inverse of the impacts you’ve identified? What would the world look like if the problem were solved? What benefits will people derive from the end result?
Which of the causes you’ve identified can the team work to stop, slow, or improve?
Identify success criteria.
What are some signs of success that you would expect to see if we achieved the objective? (See Figure 6-7.)
Figure 6-7. A template for including signs of progress
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.
Keep Objectives Visible, and Revisit Them Periodically
Objectives need to be actively maintained, and can’t be taken for granted after you’ve learned something new. “You have to actively question your starting point,” Michael Sippey says, “because the context changes, and too often we leave that unsaid.” He uses the stated objectives and assumptions as a touchstone, and takes time to make sure they are shared and understood by everyone who wants to participate.
Keep objectives visible, perhaps posted in the working space, and refer back to them at the start and end of sessions working together. As the group internalizes their objective, they can use it to provide focus and urgency when the going gets tough, or to inspire ideas and critique rather than always starting from a blank slate. Over time, objectives can shift, especially as assumptions are tested and the team learns more. Take time at the beginning of every cycle of exploration to use what you’ve learned to refine the team’s direction. And be sure to always take stakeholders, and any others who aren’t fully immersed in the effort, through the evolving objectives to ground them and provide the needed context for decisions and feedback.
When Learning Is the Objective
What about when there isn’t an actual urgent problem facing the team? Obviously not every engagement contains the threat of serious consequences if it goes wrong. Often these situations are really about helping a group learn a new way to operate, something that is very en vogue with the push toward “digital transformation” in business. Companies looking to create a less hierarchical, order-taking culture often see collaboration as a way to bring about the change they want. And they aren’t wrong. However, setting teams up to collaborate on such a challenge invites their first efforts to seem like yet another annoying bit of change management; no one wants to feel they are the ones rearranging deck chairs on the Titanic.
For those teams who need to develop new muscles, there’s nothing wrong with doing the work for the sake of learning. You just need to be very explicit about it. Collaborating when learning to collaborate is the goal just means that there are some fundamental shifts i
n how you frame the work and set up the team:
Short challenges with a known “answer”
Emphasis on helping everyone get to the answer together
Showing your work
When I observed kids learning collaboration in the classroom, that was certainly the case. In Ms. Susan’s fourth-grade classroom in the Bay Area, kids often work in groups to solve puzzles and teach each other different ways to get there. These efforts tend to be more of a learning or training opportunity, which also holds great value, than true collaboration. But putting teams and students in this situation means that leaders need to be clear that the outcome is to learn, not necessarily to produce.
Because he needs his teams to work as flawlessly as possible under tough conditions in the ER, Dr. Rosenberg says working in a more “academic” setting to practice for the real thing has incredible value. “We run drills for some of the most complicated situations we may see,” he says, “that way we can make sure everyone understands their role in how decisions will get made, as well as addressing some very basic information needs.” This might mean a nurse learning how to power up an infrequently used piece of equipment, or finding the right collection of phone numbers to call when situations go from bad to worse.
Mastering Collaboration Page 12