Bridging Present Capabilities and Future Success with @MichaelTushman Organizational Ambidexterity

Advertisements

Change Sprints Will Get You to the Finish Line

Change Sprints

Change projects often suffer from a surplus of good intentions and a deficit of disciplined effort. You get a senior leadership team together for a few days, assess what needs to change, build a plan, and get everyone aligned. If the workshop is good – our clients tell us that Change Logic runs outstanding senior leadership team sessions – then the organization can harness the excitement that the event generates. Leaders speak honestly about their challenges and commit to making change happen.

However, the following day, the ‘tyranny of the now’ can intrude and make it difficult to sustain the level of focus and intensity necessary to lead a successful business renewal. Day-to-day operations – customers, employees, product development meetings, business plan reviews –consume your time with legitimate and important demands. This sets up the familiar competition between what you’ve agreed is important and what is immediately urgent.

An extra twist on the important-urgent tension is that you are likely dealing with how to change deep-seated routines, behaviors, and mindsets. Even if you have time to complete the tangible actions that come out of a change workshop, it is still difficult to recreate that sense of commitment and motivation that made you believe ‘big’ change was possible.

Having lived through this a few times at Change Logic, we designed a method that would help our clients stay focused, engage a broader base of leaders in owning the change initiatives, and do so in a way that would energize the organization as a whole. So, the Sprint process was born. Borrowing some of the techniques and language of ‘Agile’ software development and embedding the insights from Mike Tushman and Charles O’Reilly, we have now led over twenty sprints across multiple industries. It’s enabled our clients to build new innovation businesses, embed new operating models, and rebuild go-to-market practices and processes, to name just a few of the change efforts using the Sprint model.

What are Sprints?

Simply, Sprints are how Change Logic clients create and maintain momentum to address their most critical strategic change priorities. Sprints allow clients to balance the practical mechanics with the social dimensions of change, the two elements that comprise the most intractable challenges organizations face today.

Sprints are the perfect antidote to the organizational inertia and resistance that so often haunt big transformational challenges; they recognize the complex, multi-dimensional nature of change and address the systemic barriers that other, more traditional approaches fail to address effectively.

Change: hard and soft

A key distinction is whether a change is purely about the organization hardware – process, structure, system – or whether it touches the software – people, capabilities, behaviors, and mindsets. If you only have to change “hardware”, then momentum, commitment, and engagement are not on the critical path; it’s a simple cause and effect relationship between action and result. Examples would be implementing a new IT system or managing an office move.  There is still an important human dimension involved in this kid of shift, but it can be addressed through standard methods such as strong project management, training, and communications.  We don’t need to change leadership behavior significantly or the social system of the organization. These are primarily “hardware” projects, in the realm of the knowable.1

However, most changes that we work on at Change Logic involve a response to uncertain market dynamics that may have implications for the core capabilities of an organization, and may confront power relationships between senior leaders. We are now in the realm of complexity, and that requires a different approach to managing change.

The critical part of this type of change is that we don’t know the answers at the outset.  It requires an exploratory approach – one where we test potential solutions through smart experiments which address both the formal systems (processes, organization, skills) AND the social systems of culture and leadership.  A typical client example would be moving from functionally focused ways of working to a collaborative model where multiple units need to align around shared priorities, often on a strict timeline. This will only work when we identify and shift the existing organizational dynamics and informal power structures. This is where we have found the Sprint Process to have significant impact.

How do Sprints work?

Sprints have several key elements/characteristics:

  • They address the most strategically critical and stubborn transformational challenges
  • They focus on identifying and addressing root causes for performance issues, not the surface symptoms – these are often cultural as much as they are procedural or organizational
  • They operate at speed – using 30/60/90 day cycles to drive rapid progress
  • They use experiments to test & refine solutions before rolling out big implementations – so people learn, not just to experiment, but to accept that failure is both a necessity and a learning opportunity in complex transformation
  • They leverage skills, knowledge, and enthusiasm from across the organization – Sprint teams typically consist of highly empowered middle managers with a senior sponsor who acts as team advisor and coach, not as a director
  • They focus as much on learning how to do complex transformation as they do on actual transformation-delivery
  • They focus as much on the cultural and behavioral shifts needed for success as they do on the mechanistic process and structural shifts.
  • They leverage standard change and project management methods to ensure effective governance, but they add a layer of leadership development; they help senior leaders to adapt their behaviors and help more junior leaders to take on broader responsibilities


PastedGraphic-1

As a result, Sprints enable organizations to define, test, refine and implement complex transformation while avoiding the endless debates and political resistance that go along with these types of adaptations.  At the same time, the organization learns how to shift on their own by developing the ability to continue managing transformation effectively and to continue adapting to the needs of today’s world. 

The Change Logic Sprint approach can provide companies with real competitive advantage – we help them develop the ability to change and adapt faster and more effectively than their (often disruptive) competitors.  To understand more about what we do and how we do it, please contact us at info@change-logic.com

 

1Dr Dave Snowden has written about a powerful distinction between ‘Known’ and ‘Knowable’ problems where cause and effect applies: Complexity, where you only know what happened in retrospect, and Chaos, where there is not cause and effect.
by Peter Ainley-Walker

Balancing Feedback with Feed-forward

ChangeLogic01092013-1674bw (2)

Follow @ajmbinns

My recent work with CEOs in technology and media firms has exposed a common question: how do we continue to deliver consistent business performance and explore new sources of growth? One CEO described to me the tremendous efficiency of his manufacturing organization: “we adopted total quality many years ago and have driven defects to an incredibly low-level.”

Another is proud of his organization’s operational efficiency: “we dominate our market, with a third more output than our nearest competitor, but at about half the costs.”  However, both are frustrated that they cannot replicate this success with innovation and growth initiatives: “we have the ideas, but we can’t seem to execute them fast enough to capture the market.”  One Head of R&D told me: “our need to perfect products before we launch them slows us to a snail’s pace.” He laments that fear of introducing risk into core markets was preventing his team from achieving the aggressive time-to-market goals that he had set.

In all these cases, there are well-honed mechanisms of ‘feedback’ that contribute to the operational performance of the business ­‑- what is lacking is a balancing capability for ‘feed-forward’* that anticipates opportunity. The more successful and profitable a firm becomes, the more sophisticated the feedback systems become; they help to detect variance from a plan, so enabling manages to control and eliminate error. However, innovation is about learning by mistakes; you don’t want to control error as that is a source of learning.

Feed-forward is vision-driven; it seeks to anticipate what is possible, what opportunities a company might create. Start-ups are rich in ‘Feed-forward’–some might even say full of it! The whole eco-system of Silicon Valley trades in possibilities; some of them, like driverless cars, strike us as disconnected from the world we live in today, yet, as we know, many from this dreaming has come many multi-billion dollar businesses.

Unfortunately, this sort of dreaming typically has no place in an operationally efficient business and executives with the capacity to dream tend to make their peers nervous. Okay, established, successful businesses may not be able to tolerate the level of risk and failure associated with the Silicon Valley model. However, they can balance the necessity of feedback with mechanisms for ‘feed-forward’ that focus management attention as much on growth possibilities as on error correction.

I want to ground this distinction in some examples:

Feed Forward Chart

Feed-forward also taps into human motivation in an interesting way. Human beings are far more likely to change because of an anticipation of something attractive and desirable. Fear of failure or loss causes people to withdraw and even avoid reality. A classic study of heart bypass patients found that only 10% adjusted their diet post-surgery; a critical enabler to ensuring longer-life. The research found that many simply discounted the fear of death as being too gruesome to consider. Despite all the feedback, there was no feed-forward to motivate them.

*I first learned this distinction from Dr Peter Robertson of Human Insight. 

Bruce Harreld Q&A

Last week, Bruce Harreld and the Harvard Business Review conducted a webinar on How to Drive Risk Out of Your Growth Initiatives, based on his article in the July-August issue.  Here are the key points:

1) Failing to provide the appropriate oversight
2) Not putting the best and most experienced people in charge
3) Assembling the wrong team, and “staffing up” prematurely
4) Taking the wrong approach to performance assessment
5) Not knowing how to fund and govern a start-up
6) Failing to leverage the organization’s core capabilities

Afterwards, participants were given the opportunity to ask questions. We’ve summarized a few of our favorites below.  If you have more questions, feel free to post them in the comments box, and we’ll give you our best answers.

Q1) If you’re going to take most senior people to run the new business initiative, who’s going to perform the day-to-day work?
A1)  We’re not talking about taking all senior leaders off of the core business, just one.  Don’t underestimate the magnitude and challenges of risks–you really want to dedicate significant  time, if not all of the time, shepherding and pulling the senior management team into the process.  Then, you’ve gotten the process started.  If you don’t have anyone you can pull out of the day-to-day, there will be problems. Maybe now is not the right time to start. Wait until you have more momentum in the core. Then find the one person who can lead the new business.

Q2) Are you suggesting getting started without knowing which processes are right?
A2) Yes.  You don’t know what processes you need in the beginning.  If you put the experiment through the core process, it kills creativity.  The existing process is built for the core; what do new growth initiatives need? Eventually, you’ll standardize and scale, but only when it’s been proven and you know what you’re doing.  Get some experience, step back after you’ve built a few, ask “what did we learn”, gather insight about what the process should be, then think about  how to institute a system.

Q3) Do projects at different stages need different governance?
A2) They all need senior- level care, but you’re not using the same metrics at each stage. Lay out the steps a typical start-up goes through. If you don’t have clarity of strategy, you can’t build a product. A year in, after prototyping, you can start figuring out where power points are for scalability, how to handle financials, and what types of metrics you’ll use.  Each stage will be different.  I had review cycles—3-4 hours for each new start-up a month. The topics of discussion were different depending on the stage of the new initiative.

Q4) Funding: funding fights are tough. Should there be a pool for investment, or should other lines of business come up with the money?
A4) You need a pool of money so the senior person who manages growth can invest.  The money comes from existing businesses. Be sure not to advertise how much is in that pool, though, because then, everyone will want a piece of that x amount of money.  And, the pool is much smaller than you realize.  If it’s large, you’ve prematurely scaled.  The real issue is off-cycle funding. Without CFO support, you’d have to wait till the end-of-year budget cycle to get the issue on table. Then, it would be too late to go to market. So, you need to figure out a different funding cycle for these projects.

Q5) What if Senior Management is risk-averse and people aren’t into your project? Will stealth innovation work?
No.  If innovation is lip service at your company, you might want to think about finding a better place to be.

8 Tips for CTOs to Create a Successful Requirements Process

ChangeLogic01092013-1748bw_2

Elspeth Chasser, Principal
Follow @ElspethCL

CTO Digerati Wannabes, I love you but AND … the Requirements Process, c’mon!

Try this out. Grab a random person standing near you. Smile politely so they don’t become alarmed. Go on. Now, give them a piece of paper and pen and this instruction: “make an accurate drawing of a house based on my verbal description”. Now go ahead and describe your house. Ok. Stop. Pens down. Look at what they’ve done.

Is it anything like your house? Nope.

This rant blog is about the Requirements Process, the crucial set of activities that encompass:

1. Understanding a customer need

2. Translating that need into instructions for development engineers

3. Testing to see if the product works and meets the need

If you’re a CTO Digital Wannabe, i.e. a leader of a technology department in an established firm that is developing more digital products, it’s likely that your Requirements Process is a bit of a mess. It’s also likely that if you don’t fix it, even though you’re not responsible for half of it, you will continue to have failed projects, and you will never gain the business credibility you deserve. Albert Einstein said it best: “Crap in, crap out”.

Actually he didn’t say that, but he totally could have.

So, why is it so very, very difficult?

Part of the reason is often an ill-defined Requirements method with as many different templates as you have teams, but lest you think this can be fixed by a shiny new process, let’s go deeper.

Fundamental Attribution Error, or "Everyone Else is an Idiot"

Fundamental Attribution Error, or “Everyone Else is an Idiot”

There’s a pesky phenomenon called the Fundamental Attribution Error. We code our behaviors as rational, yet we blame others’ on their faulty personalities. We all do it. How does it show up in the Requirements Process? You get a set of requirements; you do your darnedest to develop them, but the line-of-business leader is not happy. Repeat this often enough and both sides start to infer (ungenerous) things about one another’s intelligence. A wall goes up between them (the business) and us (IT). It’s “silo mentality” and it gets in the way of the kind of collaboration you need to make a Requirements Process work. But lest you think that this can be fixed by a bit of team building, let’s go deeper.

The Requirements Process is a manifestation of one of the trickiest of human activities (and, no, it’s not stopping to sing “it’s a small world after all” once you’ve started, although, god knows that is hard): sense-making, my friends–getting what’s in your head into theirs. In other words, it’s trying to get someone else to draw a picture of your house. It is *hard*. In this case, we have to get the description of what the customer wants into the heads of the product managers, and then into the heads of the development teams and then the QA/ Release guys. Do you understand how difficult that is?

We all have heuristics (mental short cuts) to solve problems. That’s great because those shortcuts save us a lot of time, particularly if our goal is to escape a sudden threat (say a hungry tiger). But they also get in the way of understanding because bias (including the good ol’ Fundamental Attribution Error) pops into our heuristics; we jump to conclusions without fully understanding. For instance, when you’re talking, rather than really trying to understand you, I’m thinking “yup, gotcha, understood… god those [fill in the blank with a role] types do go on a bit, don’t they … his left eye looks a bit funny … what’s for dinner … ‘It’s a small world after all’… damn”.

And if this game of “Telephone” wasn’t difficult enough, we do it on conference calls and record the output with that tool well-known for capturing the richness of the human experience: Excel.

So,

Implement one consistent Requirements Process

  • Launch one consistent, simple process across your portfolio with one set of templates:
  • Ensure it can scale to the size/ complexity of the development but don’t allow exceptions
  • Have a clear “go live” date where you symbolically “turn off” the old practices

Clarify decision rights

Use your cross portfolio Governance meetings to deal with issues in partnership with the business (see CTO Digital Wannabes, get control of your pipeline)

Use storytelling & visualization techniques to immerse all teams in the customer’s “job to be done” and then in the product development

A picture tells a thousand words. Tell a story, draw pictures, spend a day at a customer sight, just observing. Once you’re in development, regularly share wireframes/ screen shots with the business, QA teams and hopefully your customers. Remember, they won’t really know what they want until they see it.

Make sure you have application, business model, experience and functional requirements

I know it sounds obvious, but only yesterday I was talking with a team that hadn’t built billing functionality “because the business didn’t include it in the Requirements”. It’s a tragic case of “common sense lobotomy”. Your new process has to include at least these four requirements types and a big picture “how is this actually going to work?”; no one can answer that better than an actual customer.

Hire Project Managers who are hounds, not bureaucrats

For this to work, you must have really proactive Project Managers. Detail-orientation is “right to play”. Much more important is their ability to hold people’s feet to the fire. And don’t get me started on running good meetings. That might have to be another blog – but how about at least capturing and communicating decisions?!

Name the elephants in the cubicles

The Fundamental Attribution Error is natural, but it gets diluted when we connect to each other as human beings. You might need to start by “naming the elephants in the room”; being honest about the frustrations. Better yet, get the teams to do this. Then, agree new trust-building working practices. One wonderful CIO I know will now only accept escalations that are created jointly between the Business and Development teams.

Honor the nerd!

Even if you have outsourced a lot of the coding work (see a later blog), make it a core capability. How about implementing something like Github so that engineers from different teams collaborate on building, re-using, and managing code? How about coding competitions anyone can work on?

Use the Requirements Process to implement your Technology Strategy

You have to balance responding to the Requirements of the Product Managers (e.g. our customers use PC technology) with the Requirements of your Technology Strategy (we need to also build for Tablets because Gartner says “at this rate, tablet shipments could surpass PC shipments in less than a year”. So, use your cross portfolio Governance meetings to ensure that the final Requirements list gets the balance right. (see CTO Digital Wannabes, get control of your pipeline)

Bless you. Future rants blog posts will include:

Agile vs Waterfall, blah, blah, shoot me now!

Talk to me like I’m 6 years old…is Service Oriented Architecture a bit like Lego?

How’s that outsourcing working for ya’, huh?

Exploring and Exploiting Your Way to Growth

*Originally posted in the Harvard Business Review blog:

So far, 2012 has been another banner year for the ‘tyranny of success’ as once great companies slide ever closer to the abyss. Kodak’s bankruptcy, Nokia’s vanishing profits, and the continuing struggles of Blackberry maker Research In Motion to find an answer to the iPhone, show how rapidly heroes lose their edge. Each of these firms is struggling to respond to and lead disruption in their industries. Nokia and RIM have watched as Apple and Android have wiped away their leading position; each attempted to respond, but neither could execute. The question though is, why didn’t they move earlier? Why are companies often left flat-footed when competition strikes?

This is a challenge that has long fascinated me. Last week, I taught an Executive Education program at HBS, with my colleague Bruce Harreld, on “Building New Businesses in Established Organizations.” We addressed the question of how leaders turn great invention into business innovation that generates organic revenue growth. Across the forty or so companies from across the world, there were consistent issues and experiences. How can you adapt management systems that are used to managing short-term performance to become capable of supporting a “test and learn” approach to innovation? How can you scale new businesses within corporations that are organized to support only one mature, core business? How can you align leadership across a corporation to support these new, risky ventures when all of their DNA is committed to driving profits in today’s franchise?

Bruce is familiar with all of these issues from his tenure as Senior Vice-President of Strategy and Marketing for the IBM Corporation. Bruce helped to create IBM’s “Emerging Business Opportunity” (EBO) that is an excellent template for companies looking at long-term disruptions in their industries. It has generated $26B in additional revenue for IBM since its inception and played a vital role in repositioning the company as a business services organization, rather than simply a technology company.

IBM wasn’t always able to take advantage of new opportunities as well as it does today. As it emerged from its famous near-death experience in the 1990s, Lou Gerstner, IBM’s then CEO, noticed that the company wasn’t capitalizing on new technologies and markets as well as it could be. He knew IBM needed to become what we call an “Ambidextrous Organization.” That is a company that pursues breakthrough growth by separating new, exploratory units from traditional, exploitive ones while maintaining tight links across units at the senior executive level.

IBM turned this EBO approach into a recipe for building innovative new businesses. Each had a leader who reported to a business unit head, but also reported to Bruce as the Senior Executive in charge of new growth opportunities. This made sure each initiative got the resources it needed and met each milestone. They also followed several key principles:

  1. Active and frequent senior-level sponsorship: This ensures that there is clarity of strategy and organizational alignment, and that there is support available.
  2. Dedicated A-team leadership: Previously, younger, less-experienced leaders were put in charge of EBOs so that the EBO wouldn’t get caught up in the established way of thinking. This didn’t work well. Younger managers often lacked the networks needed to nurture an embryonic business within the larger company.
  3. Disciplined mechanisms for cross-company alignment: An explicit goal of the EBO process is to address business opportunities across the company to make sure the established businesses provide support to the EBO, even if it runs counter to their short-term interests.
  4. Resources fenced and monitored to avoid premature cuts: Funds need to be allocated and used according to plan, not re-allocated to existing businesses. Previously, there was a tendency to poach the new business’s resources.
  5. Actions linked to critical milestones: This is key in making sure the EBO is moving in the direction and at the rate the company needs. Milestones are not necessarily tied to financial metrics and are reviewed in monthly meetings.
  6. Quick start, quick stop: Speed is essential. If an EBO isn’t meeting its milestones, it needs to be stopped, or morphed into something else that will. Get the idea to market quickly, experiment, learn, and either iterate or stop the venture.

We continue to learn about how other organizations manage this project of “exploring” and “exploiting” simultaneously. I’m interested to hear about your views and experiences. What other well-established companies, in the technology industry or elsewhere, need to follow this recipe or have found their own?

RIM at the Edge


Andrew Binns, Managing Principal
(@AJMBinns)

It seems that RIM is the latest tech company to find it difficult to adapt quickly.  In his Wall Street Journal article, Will Connor points out some important points that are specific to RIM’s decline, but common to many tech companies that are in a similar situation.  While most tech companies don’t have two CEOs with completely different strategies (arguably the most controversial aspect of RIMs corporate structure), they do have problems with developing their ambidexterity.

CEOs need to be at the head of the charge when it comes to strategic change and execution.  Ideally, they will know how to balance existing business revenue streams with exploratory streams.  As we mentioned, in RIM’s case, there were two leaders with two strategies: Mike Lazaridis, who wanted to push his idea of creating a whole new Blackberry with an innovative operating system, and  Jim Balsillie, who wanted to push the technology licensing option.  If they had understood the steps to building an ambidextrous organization, they could have treated the new blackberry as an emerging business opportunity and the licensing of existing technology as their legacy stream. Yes, it’s possible that the new technology would have overtaken the legacy business, but that’s the paradox of change.

It’s also possible that the new Blackberry could flop due to RIM being too-far behind the Apple and Android curve, but we’ll save that for a later post.  Hypothetically, let’s say that the licensing option became RIM’s legacy business and the new Blackberry was determined to have the best chance of helping the company evolve as the emerging business opportunity (EBO).  If the new Blackberry took off, it could eventually feed new technology into the legacy business.  Here’s how RIM could have ensured that its EBO had the chance to thrive:

1)    Active and frequent Senior-Level Sponsorship:  This ensures that there is clarity of strategy and organizational alignment, and that there is support available.  Of course, this is assuming the Senior-Level leaders are aligned as well.

2)    Dedicated A-Team Leadership: Put the best people on the job.  Younger managers often lack the networks needed to nurture an embryonic business within the larger company.

3)    Disciplined Mechanisms for Cross-Company Alignment: An explicit goal of the EBO process is to address business opportunities across the company to make sure the established businesses provide support to the EBO, even if it runs counter to their short-term interests.

4)    Resources Fenced and Monitored to Avoid Premature Cuts: Funds need to be allocated and used according to plan, not re-allocated to existing businesses.  There is a tendency to poach the new business’s resources when nervousness sets in.  Try to avoid this.

5)    Actions Linked to Critical Milestones: This is key in making sure the EBO is moving in the direction and at the rate the company needs.  Milestones are not necessarily only tied to financial metrics and are reviewed in monthly meetings.

6)    Quick Start, Quick Stop:  Speed is essential.  If an EBO isn’t meeting its milestones, it needs to be stopped, or morphed into something else that will.  Get the idea to market quickly, experiment, learn, and either iterate or stop the venture.