Emergent versus Top Down Strategy

Clayton Christensen has influenced my thinking on strategy more than any other single source. He distinction between emergent and top down strategy formulation calls out one of the critical blocks to innovation faced by existing organizations.

The top down approach looks at past performance over time, identifies trends, extrapolates them into the future, and projects the impact of possible actions on future outcomes. History heavily influences confidence in a proposed plan. When based on years of successful experience organizations can view these projections as truth, beyond challenge.

Organizations can’t succeed without developing strong competencies in formulating top down strategies, but those strengths create barriers to pursuing any significant innovation, making it much harder to commit the required resources. Entering new territory or re-envisioning familiar ground means leaving the comfort of high confidence based on long experience and shifting from top-down to emergent strategy formulation.

Rather than extrapolating the past the emergent approach starts with setting a desirable future state (in 5 years we’ll have X% share of a $Y market), identifying the riskiest assumptions on which that future depends, and defining near-term actions that test those assumptions and based on the results, adjust the approach. Execution focuses on learning and adapting. Confidence depends on small-scale confirmations that the desired future can be reached. Sustaining that confidence in the face of always beckoning incremental opportunities in the existing business requires real and rare discipline.

Allocate Blame up front

A long time ago I identified the key steps to a successful project kick off:

1. create a separated space for the new team (so they don’t get pulled back to ongoing work)
2. recruit team members to enlist, don’t draft/assign them
3. come up with a catchy code name
4. create a cool t-shirt
5. pre-allocate the blame for the project’s likely failure (since most do)

Getting the blame game over with up front helps the team take an aggressive swing, to accept that doing something new is risky, and hedging your bet to minimize getting blamed if things go wrong makes zero sense. The leader’s t-shirt should say, “It’s my fault” and be done with it.

Dialog Mapping

Again, not a big fan of meetings, but sometimes assuring that people can behave in alignment with each other requires getting them together to agree on a course of action. Dialog Mapping is a technique to facilitate these types of meetings.

The way I’ve applied it is pretty straightforward. You start by identifying an open-ended question, like “What should we do about Iran?” (rather than one that forces a single yes/no answer, like “Should we attack Iran?”) As participants speak the facilitator captures what they say as one of these:

• ideas: a proposed action, like “bomb them.”
• an argument for or against an idea: “bombing them will start WW3” or “the claims that Iran is building a nuclear weapon is false, so we don’t need to bomb them.”
• context (facts like “Iran borders Afghanistan” if it’s not mentioned as an argument for or against an idea)
• parking lot: things that are worth capturing but not on point for this meeting (“Let’s bomb North Korea”)

The facilitator isn’t a passive scribe; they interact with the speaker to make sure the ideas/arguments are captured accurately, they ask the speaker to identify what’s different in what they’re saying and what’s already been captured (to minimize the beating of dead horses), and they assure all of the participants are heard.

The capture is shared with all of the participants in real time—projected, displayed, shared through the virtual meeting shared desktop, or the like. This allows everyone to stay in sync, to challenge the accuracy of the capture, and to self-censor the desire to keep making the same points. There are software packages designed for Dialog Mapping; I frequently used some outline/mind mapping software. 

Once ideas and arguments have been captured the meeting can shift to prioritizing, evaluating, and selecting actions.

I recommend learning more via the link above and/or reading the book. 

Rules of Conversation

One of the benefits of working in major corporations is the training and development experiences they provide. Both Apple and HP made significant investments in my career development (and deserve appropriate credit and none of the blame). Some of the tools and concepts made a big difference in my ability to respond to the critical coaching I received years ago: “Do you want to be right or be effective?” 

The Conversation Meter (from HP Dynamic Leadership training delivered by Conversant in 2001 time frame) is one such tool. I haven’t read it but believe this book is the authoritative source of this model:

Hopefully you’ll encounter pretense infrequently. I’ve found that saying the same thing in all circumstances, not slanting the message for the audience, increases the effectiveness of the communicator and the message immensely. It’s so easy for the shading and nuance to slip into falsehood.

Sincerity is highly common in the technical community. The difference between being right and being effective depends on moving beyond sincerity. My coach way back when told me, “You say things in a way that require anyone who would disagree with you admit to being either stupid or evil. You might want to give folks a bit more room.” The point of interacting with others isn’t to be right, but to get to the best shared understanding of what it right.

Separating fact from interpretation allows considering evidence that you have your facts wrong, and where the same facts can be interpreted in multiple ways. This allows considering the relative merit of various interpretations.

Once you let go of the idea that someone is keeping score and rewarding the person that was right (I told you so!), you can actively seek out diverging views. There’s also a better chance that others will seek yours out, as if by magic….

Overcoming Resistance to Adopting Innovation

Organizations resist change. Even in an industry like technology that attracts neophiles most people prefer to stay with what they know.

Makers and Managers

Making (directly working on a problem in a domain) differs fundamentally from managing (planning, organizing, directing, and controlling work on a problem in a domain). The related activities of making and managing mix together poorly. This article describes their different cadences, why they drive each other crazy, and the importance of segregating them.