Bridging Present Capabilities and Future Success with @MichaelTushman Organizational Ambidexterity

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

Look Both Ways!

In his latest edition of the weekly “Economic Principles“, David Warsh addresses the controversy revolving around Jill Lepore’s criticism of Clay Christensen’s work in The New Yorker. He delivers some salient points and he gives a hat tip to our founders, Professors Charles O’Reilly and Michael Tushman, and their concept of the Ambidextrous Organization, as the way forward for larger, well-established businesses. Does Ambidexterity resonate with you, as it did with Warsh? 

The Art of Leadership

Ingrid Johnson, Group Managing Director for Retail and Commercial Banking at Nedbank, and a former student of Professor Mike Tushman, offers some key lessons on leading transformation in her recent interview in African Banker:

“One of my big lessons had been in the art of leadership, as opposed to management…if you come in and say ‘I think this is the new strategic direction’–you’re never going to get outright support, because people don’t like change.”

“[Nedbank]was not quite sure of its destiny.  It had described a strategy, but not necessarily executed it.  It was amazing, going from one floor to the next and it felt like I’d joined a completely different organisation.”

“You come in with the expectation that [the existing management team of a reasonably performing business] know what they’ve got to do, and you just need to nudge them in a certain direction. And then you learn more about the scale of the challenge required to change the organization: if the existing leaders knew that and had embraced it, then perhaps they would have done it already.”

“It is in these times that courageous decisions and actions can change the sedtiny of the business…You need to honor people and … be very open in your conversations as to your expectations.  But how much time do you give people to shift?  I think that’s the challenge in a moderate-performing business.  If you’re on a burning platform and everything is wrong, it’s almost easier to affect change”.

If you’d like to gain a deeper understanding of how Johnson arrived at these lessons, read the HBS case study on Nedbank by our co-founder, Professor Michael Tushman.

Congratulations to Professor Tushman

This weekend, our co-founder Professor Michael Tushman won the Distinguished Award for Scholarly Contributions to Management.  We couldn’t be more thrilled for Mike.  Now, he and co-founder Professor Charles O’Reilly have both received lifetime achievement awards from the AOM, reinforcing their positions as thought-leaders in the business world.

Mike Academy of Management Award

AOM Lifetime Achievement Award Winners (l. to r.: Michael Tushman, Philip Mervis, R. Edward Freeman, and James P. Walsh)

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?

The “Tyranny of Success”

We’ve all seen Nokia and Blackberry fall victim to the ‘Tyranny of Success’, the well-researched syndrome that causes market leaders to miss fundamental shifts in their markets. But, are we already seeing the same pattern unfold with their nemesis, Apple, and its duopoly partner Samsung?

 

Some of the key lead indicators for the ‘Tyranny of Success’ are:

iWatch

Could Apple be the next to suffer from the Tyranny of Success?

 

  • Focusing on technology gadgets rather than solving real customer issues – remember Polaroid’s wearable printer, it made sense to them as a way to make sure digital cameras still generated sale of film. Are Siri and Samsung’s new eye movement activation symbols of the same obsession with what technology can do at the expense of what is useful? Reuters reported that Samsung shares dropped nearly 5 percent, or around $10 billion, in just two trading sessions after it launched its latest Galaxy S smartphone late on last week.
  • Seeking success by repeating past glories – Just think how long it took the US car industry to seriously respond to small, well-made Japanese cars. Or, when Gilette finally had to admit that putting yet another blade on the razor didn’t equal innovation. Are we watching the same story with the iWatch? How many iGadgets can the world absorb?
  • Getting disrupted by low-end competitors – Clay Christiansen’s classic research on how the Steel industry ignored ‘mini-mills’ or mainframe computers ignored PCs. How seriously is Apple taking Kindle Fire when it launches the iPad mini at twice the price and with half the functionality?
  • Losing a sense of proportion – so many great companies end their days in the death throes of litigation, trying to get the rules changed. Is that to be Apple’s fate? “Apple …has been spending a great deal of time in the courtroom, pointing fingers at Samsung (and similar, smaller others) of stealing designs for its phones, tablets and operating systems.” (IBTimes)