How to Create a Culture of Success

Change Logic co-founder, Charles O’Reilly, offers some insights on how to create a culture of success, produced by the Stanford Graduate School of Business.

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

Name the Elephants

KvD

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.

1

2

3

4

5

6

7

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?

Six Imperatives to Successfully Implement Agile

ChangeLogic01092013-1748bw_2

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

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?

CTO Digerati Wannabes, You Are Not Google

ChangeLogic01092013-1748bw_2

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?

Can We Turn Risk-Aversion on Its Head?

ChangeLogic01092013-1674bw (2)
Andrew Binns, Managing Partner
Follow @ajmbinns

Change Logic was in Silicon Valley last week, running a Strategic Execution Forum with a technology firm, helping leaders to identify the key barriers to growth in their organization.  Amid the specifics, the leaders identified a need to change in order to execute their growth strategy.  It’s a familiar story of a risk-averse culture, and it’s a familiar story across more than a hundred of these workshops– innovation is stifled by a fear of destabilizing current product revenues; short-term priorities trump investing in promising growth opportunities; and, new ideas have to fight for attention.

on its head

The history of the computer tablet could have been very different if Bill Gates’ hadn’t insisted on making its e-reader product a profit center well before it was ready for the market.  Or, if Intel had not pulled its investment in a tablet in 2001 as a part of budget cuts during the tech crunch (by the way, their Mp3 player and digital camera projects were shelved at the same time). These stories unwittingly freeze innovation inside corporations. It tells anyone that might come up with a breakthrough idea that it is a better career option to play it safe, to avoid risk.

backflip
There are plenty of environments where managing and avoiding risk is a very important activity, but how do you manage risk while encouraging it at the same time? One step is to turn a negative into a positive.  Asking people to become less risk-averse isn’t very actionable. Experimentation is.  Can we turn the problem on its head and find ways to encourage, sponsor and facilitate actions of experimentation?

Here are five ideas that I’ve seen our clients successfully adopt:

  • Seed Fund – one media client has a $1M fund set aside for helping employees test new ideas; employees compete for the money and get time to prove the concepts.
  • Business Experiments – another client is creating a series of ‘experiments’ that get managed outside the usual management system with an explicit ‘test and learn’ philosophy
  • Customer Discovery – one of our Latin American clients has systematically applied the ‘Lean Start-up’ philosophy to find new customer needs to solve and build businesses around meeting those needs
  • Crowd Sourcing – one of our pharmaceutical clients has put some of its toughest science problems out to an online community to solve
  • Break the Rules Workshops – most of our clients are learning to do this–inviting executives to think about how to challenge and rewrite some of the assumptions of their industry; we’ve found this a powerfully liberating experience for many companies.

Our California client is starting its journey of growth armed with these ideas and a passionate commitment to organizational renewal. These practical steps will not rid them of risk aversion (and remember that’s not always wrong), but they will foster an openness to experimentation and to learning from failure and success. I would love to hear of other simple, practical ways to set a norm of experimentation.