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


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


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

Name the Elephants


Kristin von Donop,  Principal
Follow Kristin on twitter

Recently I attended a holiday party where the only people I knew were the hosts. It wasn’t long before I was engaged in a casual conversation with the woman sitting next to me.  She was 18 years younger than I. After some polite exchanges, the younger woman asked a few of us: “to what extent is the obstructionist political climate in Washington DC due to racism?

I thought, “Now this party is getting interesting!”

Several of us shared our points of view and they were all different. She raised a courageous question, we stated our positions, and then the topic shifted. This scenario happens a lot at work: people share opinions, but nothing changes.  The competency of courageous conversations is important, especially once you’ve established a compelling purpose, which I discussed in my last post.

In this blog, the focus is on those necessary courageous conversations. We can increase velocity, operate differently, and build the capacity to adapt in the future if we address the elephant in the room more effectively.

Name the Elephant PhotoName the Elephant PhotoName the Elephant PhotoName the Elephant PhotoName the Elephant Photo

One of our clients made a bold move to pursue a disruptive strategy and it completely changed their go-to-market approach. The senior management and the board knew people would have to adapt to new ways of working in order to be successful. They got everyone involved over a series of four workshops to address the changes. They addressed all the right levers.

Then six months later, the EVP spoke to me about the lack of progress:

“For half of the organization, it’s as if the clock rolled back a year and nothing changed.  We all agree on the vision but, there are senior managers who aren’t willing to evaluate their work in the context of our strategic outcomes.  How can we get the sacred cows on the table?”

The EVP acknowledged that, as senior managers, they all must do two things at once.  They must manage the current stakeholder demands and at the same time lay the foundation for the future. They must be pragmatic and move toward the new vision.

This awareness is important, but not sufficient for progress. If not addressed, misalignment could strengthen inertia.

Courage is an antidote to inertia. 

It takes courage to focus people’s attention on difficult issues and to maintain the tension long enough to instill new practices. It takes courage because the risks are real. When you challenge the status quo, it increases the likelihood of conflict and stress. Across all cultures, it is difficult to talk about tough issues; but if you don’t tackle the tough issues, people will revert to their habits and that creates inertia. People believe the change is real if the tough issues are out in the open and being addressed.

Courage does not equal bravado. The lone ranger approach increases risk.  If you ride into the meeting on your horse with your flag waving in the wind, and immediately name the elephant in the room, you might feel relief, but it is no guarantee that others in the room will, or that there will be progress.

If you want sustainable results:

a)      Identify the most important issues that you believe need to be addressed

b)     Find out if other people agree and whether they will publicly support your raising the issue

c)      Raise the issue in a way that allows the group to take responsibility.  A guiding principle for this step is to “name, don’t blame”.

I find that the chart below is helpful.  It is the Gradients of Agreement, a tool to identify where people disagree, and focus on what is needed to increase buy-in for a decision.   Use it to surface the level of support that can remain hidden when using majority vote.

Instead of voting yes or no for a decision, people choose a number that reflects their level of support for the idea.








I do not support the proposal

I won’t block it, but I don’t want to be involved in the actions

I want to register a dissenting opinion, but will support it.

I have some reservation but will go along.

I can live with it.

I support it.

I strongly support the proposal.

After everyone has voted, focus on the concerns held by people who voted on the low end of the scale and identify what they need in order to increase their ranking by one.

Adjust the decision and vote again.  Work towards ensuring everyone’s concerns are heard, understood, and the group will commit to standing by the decision once it is made.

What have you experienced that either helped or hindered courageous conversations?

When Leadership Alignment Becomes a Commitment


Kristin von Donop, Associate Principal
Follow Kristin on twitter

There is a consistent theme in our work with the senior leadership teams from financial services, media, entertainment, philanthropy, and information technology companies: they need stronger alignment between business units.  The reasons vary, either for more speed, more innovation, or to collaborate to create market differentiation.  These leaders ask us:

  • How can we increase velocity in the alignment between divisions, regions, and functions?
  • How can we instill new ways of operating that are scalable?
  • How can we ensure we will adapt in the future?

My next few posts will address four topics that are key to addressing the questions above: focusing on the ideal state, getting the elephants on the table, sharing responsibility, and influencing across the matrix.  This post will focus on the defining the ideal state.

Many of the senior teams we work with want their managers to be nimble, work together, and move resources quickly to capture opportunities.  Unfortunately, many great ideas end up dying because of bottlenecks.  These blockages are prevalent, especially when leaders can’t figure out how to get horizontal and vertical engagement.

Earlier this year, we worked with a technology company that grew from multiple mergers.  I asked several people in this organization, “Whom do you work for?” Out of the x number of people I asked, y responded with the name of their legacy company, not the new combined organization.  These responses gave me a key insight: the company has an overarching strategy, but no real alignment.  There was no shared aspiration.

The senior team knew they needed to revitalize the organization and that people were their main source of competitive advantage, but  they struggled with how to get everyone on the same page and aligned to customer demand.  The path forward was unclear.  The only certainty was that the status quo was insufficient.

Getting it Right

A few years ago, the CEO of a successful global IT company convened the top 100 leaders in Florida for their annual strategic meeting.  This was shortly after our friend Mike was selected to run a segment that had high growth potential.  When it was his time to address the group, he started by sharing that he called his mom as soon after he was appointed to his new job. Her immediate response was “Are you nuts? Nobody in that role has been successful!”

He described telling her it would be different this time around because of the people who will be involved.  Then, turning to the audience, he called out Mark, who was in the audience, and said “with Mark’s commitment, we can win in this space” and then he pointed to Maureen, adding “Maureen has the horsepower in her team to get this right”, and on he went until he named ten different executives in the room.  These were the people whose alignment was essential.  They were the leaders of the key products, the regional leaders, and in corporate functions.

Mike then described the impact they could accomplish if they worked together.  He didn’t talk about the revenue, margin or other key metrics.  Instead he described success from the perspective of the customer’s customer.

First, Focus on “Why?”

Mike’s predecessors had small wins but were not able to instill a new set of repeatable practices.  If the quarterly results for any one unit were not up to par, they’d cut the investments for that segment. They’d debateendlessly..  In some cases, they’d escalateissues to the SVPs.

Mark took a different approach and unleashed the power of the ideal state.  His market segment was different than the company’s traditional customer base.  To capture this market, he needed to instill different approaches: more marketing investment, greater reliance on business partners, aand new product development processes to build a portfolio at a different price point.

That meeting in Florida was just the beginning.  Over the next year, Mike made sure conversations about the possibility were an integral part of the alignment work. He rallied his peers to sustain the investments in spite of their skepticism about achieving success in three or four quarters.

Second, Own the “Why?”

Mike’s next step was to create an extended leadership team that had the skills needed from across the organization.  Some of the people he invited were ones named at the meeting in Florida; others were the technical experts in their business units.

Being on the team didn’t create the alignment.  He led a series of focused conversations that addressed the question:

What is the unique value of this leadership team?

The discussions about this question galvanized these busy executives by focusing specifically on the team’s contribution.  It oriented them to what matters most for the customers and for long-term success. The purpose of this newly– formed senior team was compelling and consequential. They also explored the implications of the ideal state for each individual. 

Real change requires grounding people in a shared aspiration. It provides clarity and activates our achievement drive for success.  Relying on threats or danger when you need to catalyze sustained change across many groups isn’t going to cut it.

Leaders need to focus people’s attention on the most important issues without resorting to fear. Unleash the power of the ideal state to create alignment.  Describe what is important to you.  Then inquire what is important to others.  Find the intersections to develop a shared ideal.

As you activate people to do something differently, keep possibility and optimism in the front of your mind. Address what is important and describe why.  Be curious about why it is important to them. During the hard work of change, keep the aspiration alive by reminding yourself and others about the consequential nature of the work.

In the next blog, we will explore ways to strengthen and sustain alignment with a focus on putting the “elephants on the table” – surfacing the tough issues that get in the way of progress.

Six Imperatives to Successfully Implement Agile


Elspeth Chasser, Principal
Follow @ElspethCL

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

Colin looked haggard at our 8am Monday morning meeting. “Had a good weekend?” I queried, wondering if the cause of his unshaven chin was a little too much fermented beverage whilst watching his favorite basketball team.

“I didn’t even get to watch the game.  I was in the office the whole weekend, trying to sort out the big mess with the release on Saturday.”

This shell-shocked Colin seemed a different man from the positive, confident one who had recently joined this Digital Wannabe (an established firm that is developing more digital products).  Almost the first thing he’d done was to introduce the Agile development methodology…  to “enable us to increase our speed to market by testing and learning as we go rather than taking 12 months to release something the market no longer needs”.

And yet now, as he sipped morosely on his coffee, all he could ask himself was: “what went wrong?”

Here’s the thing: Agile can cause havoc in mature organizations because it focuses on what you want the Application to do and it underestimates the complexity of the environment in which it is being developed. Let’s face it:   Your underlying technology is old.  It was written in a language that is the coding equivalent of wearing bell-bottoms. It is un-documented and has been fiddled with for decades. An engineer might adjust a simple-looking line of code, but unbeknownst to him, it is linked to the billing system for a reason that made sense to someone 10 years ago.  Change it and your billing system crashes!  And it’s complex because you’re in a mature organization, meaning that you probably have more regulatory and security constraints than the pure Agile method was designed to deal with.  And it’s complex because you’re working with a mix of engineers – some of whom have been around as long as the code (and still wear bell-bottoms), a lot of whom are outsourced, and most of whom are globally distributed.

So, the answer is obvious, right?  Let’s stop talking about Agile vs. the more traditional Waterfall development methodologies and accept that mature organizations need to do a hybrid.  Done.  Blog complete, right?  No, my friends, because the real cause (in my humble opinion) of Colin’s problems was not that he chose the wrong method but that he was answering the wrong question. The question should not be “what is the right method?” It should be “how can I speed up and consistently deliver what I’ve committed to?”  Part of the answer is Agile.  An equally important part of the answer – and one that CTO/ CIOs often miss – is “you need to change the culture”.

So what is Culture?

Imagine this.  You’re a trainee priest.  You’re generally pretty keen on being a Good Samaritan to anyone who looks a bit peaky.  You’re having a cup of tea in the common room, when in bursts your seminary Director asking if you would rush to a classroom at the other end of the building because one of the teachers is sick, the kids are going crazy and someone needs to be with the class. “Sure” you say and you race down the corridor.  As you do so, you literally step over a person lying on the floor in the hallway who seems to have fallen, clutching his chest.   You don’t give that person a second’s thought, so keen are you to go be helpful to the class.

Lest you think this is apocryphal, this was an actual experiment done by some pesky social scientists.  Across many variations of the experiment, only 10% of Seminarians stopped to help the poor chap lying prostrate on the ground simulating a heart attack.  How do you explain this? One view is that our behavior is less shaped by how moral we are as an individual, and more by what we think is expected of us by other people. As Change Logic Director and Stanford Professor Charles O’Reilly puts it: “Culture is a social control system. It tells us what we need to do to fit in with the expectations that people have of us.”

If we know what is expected – go save that classroom full of children – our own judgment is suspended until we have met that expectation. And, we do it automatically, there is little or no conscious thought involved.  So how does that apply to our Agile debate?

Digital Culture

We know what successful Digital Culture looks like. In 2009, Professor O’Reilly and colleagues from Stanford, UC Berkeley, and Santa Clara University conducted a study that benchmarked the culture of 32 prominent Silicon Valley high-tech firms . They discovered that the highest performing firms are those that have the more ‘adaptive’ cultures (i.e., quicker to opportunities, willing to experiment, more innovative, more risk-taking, faster).  It is this set of success-driving behaviors, or culture, that Colin should bring to his Digital Wannabe.  Looked at in this way, an Agile methodology is a part of resetting expectations.

What Colin needs to do now is trigger the automatic behaviors that tell people to conform to a new set of expectations.  We know that behaviors are provoked by the signals in our environment that tell us “how we do things around here,” and by what will move us away from pain and towards pleasure, or at least towards comfort.  His team is probably still receiving signals from the old culture like: “keep your head down”, “get your bit of the process done” and “don’t surface bad news.”   No wonder things are not shifting.Why the IT Department Doesn't Deliver

Here are six culture imperatives to add to your agenda for becoming a Digital company:

1.      Stop the Debate: Do Agile and Waterfall

Implement one consistent Agile method for application development and assign a team (at least a proactive hound of a Program Manager; an Enterprise Architect and a Content Architect) to do and track a Waterfall plan and risk log to predict and mitigate the interdependencies/ complexities.

2.      Create an Agile and “We Keep Our Commitments” Culture

Create a compelling vision of the future for your team that describes the move from transactional IT provider to becoming the driving force of innovation. Describe what that means for them, new behaviors to adopt, and new work routines that will be necessary.

3.      Signal That You Are Serious about This New Culture

Nothing works quite as quickly at shifting culture as the signal that “I’m being watched and compared to my peers.”  A recent MIT study gave fast food store managers data on “irregular” Point of Sale till tallies. After one week of seeing this data, the “irregularities” stopped, store revenues rose dramatically, as did, interestingly, the tip tallies of all staff. Think about everything in your environment that would signal “this is the new way we do things around here.”

  • Make Agile a business, not just a technology process, so that the business folks become integral to your ‘test and learn’ approach
  • Create a visible dashboard that shows clearly how each team and individual is doing against your commitments. And then get creative – create joint business/ tech awards for successful teams!
  • Train the business folks at the same time as your team. Then shift your annual objectives. Your job designs. Your promotion criteria. Your on-boarding pack. Your intranet page. Everything.

4.      Take No Prisoners – If They Don’t Want to Change, Let Them Go

What do you do the first time one of your best SMEs fails to meet a commitment to you? Remember Lou Gerstner at IBM who said: “Nothing can stop a cultural transformation quicker than a CEO who permits a high-level executive—even a very successful one—to disregard the new behavior model.”

5.      Deal with Those Elephants in the Cubicles

I wrote in my last blog about the “Them” and “Us” resentments that build up between teams.  Putting people in an “Agile Hothouse” room won’t make them like each other.  They’ll just resent each other at closer proximity.  You’ve got to facilitate a “truth and reconciliation” dialogue between these individuals / teams if you want the steps above to work.

6.      Create a Lego-like Component Revolution!

Friends: It is inconceivable that you can continue to write every piece of code from scratch to meet the bespoke need of each Product Manager.  You are increasingly competing against the true Digerati who have a modular architecture and build in Lego-like reusable components.  Unless you want to end up like the IT department equivalent of a tiny Savile Row bespoke tailor to some British aristocrats, move to a catalogue of reusable assets. This will not happen automatically: it’s like getting your kid to eat their greens—they may hate it now, but it will be good for them in the long run.

Future rants will include:

  • Talk to me like I’m 6 years old…isn’t Service Oriented Architecture a bit like Lego?
  • How’s that outsourcing working for ya’, huh?

8 Tips for CTOs to Create a Successful Requirements Process


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.


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?

CTO Digerati Wannabes, You Are Not Google


Elspeth Chasser, Principal

CTO Digerati Wannabes, I love you but AND … Don’t let the Product Guys [substitute “Strategy guys” as appropriate] visit Google’s HQ.  You know what will happen!

I’d been in the room for an hour and I was hot.  Sweaty hot.  Unpleasant hot. And, if the smell was anything to go by, and the sheen on the faces of the team all too close to me, so was everyone else. Drooping employees clambered forlornly over chairs and cables to get a slice of equally drooping pizza. The only sound was the tapping of keyboards.  This was interspersed with occasional moments of expectant silence when the overworked development server did its inanimate version of drooping … and crashed. When this happened, all heads – like Meer cats – looked expectantly towards the operations guy as he called his colleagues at the data center to get them back on line.

But it was all good, because we were (drumroll, please) doing a lunch time hackathon to create an all new mobile App.  The executive team, some months previously, had been on a visit to Google to learn about Innovation and had come back with a “best practice” list that included, yes, lunchtime hackathons, 5 new product innovations and an Open Innovation platform to generate even more ideas.

CTO Digerati Wannabes, here’s the thing. You’re just not Google. You want to be a partner to the business, you want to be a true Digerati, but you can’t do it all!

You’re not Google because your organization’s mission is probably something like “serve our customers by being the best at delivering world class service leveraging…blah, blah, blah ” Ok. That was cheeky.  But you get my point. You can’t do the ‘keep throwing new ideas at the wall and see which one-out-of-1 will stick and be profitable’ thing because that’s not your strategy. Even if it was, you can’t do it because you don’t have 31% growth like Google does (unless you count your Total Cost of Ownership).

You’re not Google because you have a mature product set with customers who like things the way they are.  And each of those mature products has a product manager who is rewarded based on the incremental revenue they generate from those products. So, of course, they think up as many new features as possible and want them NOW so they can hit their targets. This demand is only going to get more ferocious.  But guess what, so are the CFO’s demands for cost cutting.

And lastly, you’re not Google; you don’t need their culture, so stop making weak attempts at implementing it. One client we worked with created an Innovation room – with big comfy chairs and whiteboard walls – but here’s the kicker – the “business case” to use it has to be signed off by a senior manager a week in advance. Come on!

And by the way, CTO Digital Wannabes, there is no evidence that riding about on a Segway all day leads to increased innovation.  There is strong evidence that you’ll look like a tool.

CTO Digital Wannabes, get control of your pipeline

You can’t do everything.  And you know what? If you do, you’re just going to create, as one of my favorite CTOs (who is now a CEO so listen up) said “a shinier version of the same un-integrated mess we have now”. So you’ve got to put some controls in – and no – the Business Case or the annual budget cycle process is not enough. Set up a quarterly or bi-monthly meeting co-chaired by you and the CEO to prioritize what gets done against your strategy and the overarching customer experience of your product set.

CTO Digital Wannabes, create a unit to develop new innovations

You need two development pipelines: one for your current products (100% cost allocated), one for experiments. Create a new unit to do the second, with a new direct report, a new fund, a new culture, new measures and whoever is assigned to that team has to be ring-fenced and fully dedicated to it.

Here are a few tips for the explore unit we’ve learned along the way. 1) Use a Tech start up methodology and mindset.  2) Stick to your architectural guidelines even if another way would be quicker; otherwise, if it is successful, you won’t be able to scale it on your core platform. 3) Product Managers will try anything to get their existing product innovation ideas into the explore unit – don’t let that happen because it undermines your core process.  4) Include technology-driven innovations, e.g. like building a web application layer.

CTO Digital Wannabes, create a culture that will enable you to deliver your technology strategy

There is no one “right culture”. The best culture is the one that enables you to deliver your strategy. To be honest, Digital Wannabe, I think the key cultural attributes you need to focus on are: “project delivery discipline” and “communicating in English not Technology”.

Culture is created by more than a few “techniques”.  Don’t scatter bean bags throughout your otherwise deadly grey cubicles.  It’s like the science teacher dancing at the school disco. Stop it.  Instead, decide the attributes you need to deliver your strategy and then ask yourself “what would show my employees I’m serious about this?” Think about things like office environment yes, but also KPOs, bonus structure and also less obvious things like what you focus on in meetings.  And if I were you, I’d get some of your wider team involved in this – they’ve probably got a much clearer sense of what creates the culture – and what needs to shift!

Tune in next time for:

Dude, the Requirements process, c’mon!

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?

How Can We Turn ‘CTO Digital Wannabes’ into ‘CTO Digital Winners’?


Elspeth Chasser, Principal

Doug is the CTO of a large, lucrative, mature organization that sells physical and digital products.  He was promoted 10 years ago on the back of a successful roll out of the new email system.  Those were the days when an IT department did what it said on the tin. Now Doug’s team has to create new products, implement the new ERP platform, and keep the technological lights on.

Every day, Doug’s business colleagues ask him “why can’t we be more like Google?” They don’t know that the majority of his code was written when Elton John still had his own hair.  They don’t know that despite his very best attempts, his core platforms talk to each other with the grace and ease of the leaders of North and South Korea.  Doug is a member of the Digital Wannabe club. A growing community of IT professionals learning to make the leap from being a support function to becoming core to the business value proposition.

I recently shadowed Doug for a day, a day which started with a “deep dive” on a failing project. His knee dance d up and down in a frenzy as he listened to the blame shifting on this utterly failed project.  I mean utterly failed.  On every count, failed:  Late.  Over budget.  The original specifications, a long distant memory.  And an “interesting” user interface–the design of which was chosen by (yes, you know it Digital Wanabees, say it with me…) the CEO, not the conclusions of the UX research.  In the corridor, we bumped into a Sales Exec who complained that she had just lost another big account to their new competitor.  Why? They are a Silicon Valley firm, started 5 years ago in the Cloud so offer a low cost alternative that also integrates with another of the ex-client’s key business applications. 

Doug had to run (with me at his heels) to a Senior Leadership Team meeting.  As he sat down he grabbed the agenda on the table and pointed at the first item with a grimace: Big Data. Doug patiently explained that there were a number of technical barriers to the grand plan laid out by the external consultant report before them: “As I showed in the SOA strategy at the last meeting…”  The BU lead who’d hired the Big Data consultants said: “We can’t wait Doug; we can’t miss the market window. Let’s bring these guys in to get started whilst you overcome the barriers and really focus on Project Activate.  How’s that going, by the way? ‘Hear you’re still having some issues.”

Doug is real, I’ve met him five times this year. He is caught between the reality of the legacy systems, the urgency of the market, and the complexity of implementing robust, long-term solutions. Doug is technically competent and an effective manager. In common with his other Digerati Wannabes, Doug struggles to lead his peers. That won’t change overnight, but here is the three-point plan Doug and I agreed:

1.    CTO Digital Wannabes, create a compelling Digital Strategy!  You are a leader, not an order-taker.  You know what it takes to be successful in your market where everyone’s expectations are shaped by our everyday experience of Google and Facebook.  You know you need to create a modular, hybrid environment that will enable you to be a service broker as you simplify and update the old whilst integrating the new.  And you know how far you are from that and what it will take to get there. Come on, you’ve got to get ahead of this.

2.    CTO Digital Wannabes, sell your Digital Strategy like a modern-day Don Draper!  Get your UX people in: they’re creative.  Make an animation. Get the business folks to spend a day with the dev team.  Show them your code, and then show them HTML 5.  Give them a visceral experience that convinces them they’ll never achieve their goals unless they invest in your strategy and sign up to your roadmap.

3.    CTO Digital Wannabes, get out of the weeds! The first two are going to take way more time than you think.  Proper time, not just a few extra hours.  Get a Chief of Staff to knock heads over the failed projects that are taking up so much of your time.

Future rants for CTO Digerati Wannabes will include:

  •          Don’t let the Product Guys [substitute “Strategy guys” as appropriate] visit Google’s HQ, you know what will happen!
  •        Dude, the Requirements process, c’mon!
  •         Agile vs Waterfall, blah, blah, shoot me now!
  •         Talk to me like I’m 6 years old…is SOA a bit like Lego?
  •         How’s that outsourcing working for ya’, huh?

And if I have another long flight just after a BU leader says “I just don’t understand why we can’t be more like Google”, god knows, there might be a lot more rants than that.