Workplace Culture

By | AgileBusiness, Culture, Leadership, Strategy | No Comments

Workplace culture is intriguing, a few seem to have an opinion on it or trying to build it, maintain it or redefine it. Further below is a link to survey for some research we’re doing into Workplace Culture if you’d like to contribute and get the report findings.

It’s a long game, it’s not like you can change your culture in a few months …even years.

Michael Sahota listed the following key points about culture whilst referencing the Schneider Culture Model:

  • Management guru Peter Drucker says “Culture … is singularly persistent … In fact, changing behaviour works only if it is based on the existing ‘culture’”
  • No one culture type is better than another.
  • Depending on the type of work, one type of culture may be a better fit.
  • Companies typically have a dominant culture with aspects from other cultures. This is fine as long as those aspects serve the dominant culture.
  • Different departments or groups may have different cultures. (e.g. development vs. operations)
  • Differences can lead to conflict.

It’s those last three that caught my attention.

Culture comes from a combined set of behaviours, from people ‘in’ the business. Often it’s driven by the founder (not always a CEO) or a change agent, an ambassador for change, who has a strong vision and purpose that everyone else buys into because it fits with some of their own needs and ambitions. That’s what creates the ‘energy’ in a work environment that electrical vibe that people describe they can feel, drive, passion, teamwork, whatever you want to call it, you can feel it. Can you feel it now? Have you felt it this week? Month? Year? If you haven’t then you have a problem, maybe you have or are developing different cultures in different groups and moving to conflict, which by the way slows you down.

We’re now seeing businesses wanting to move faster, have teams that come together and then break away after a relatively short time. We’re going to see more resource coming in to the organisation that’s far more temporary, new technologies, new processes, to serve short and long term purposes. Every company needs to become more adaptive, iterative and emergent, which means mixing skills it doesn’t have or can’t afford to hire full time (yes you can partner but that’s not for everyone), and as Nigel Bogle once said,

‘Big is a collection of smalls’ 

and that’s a team dynamic. How do we cope when we have mixed cultures and does it matter? Does it lead to conflict? How do we recognise that and the ‘energy’ and more importantly how do we build or maintain it?

Knowing the culture(s) you have and the culture(s) you want to keep (because it drives growth) should be primary, especially during a merger or change programme, it’s your people stupid, the foundation of what you build.

What’s your experience? It still feels like the elephant in the room.


Responsible or interested in Workplace Culture?

I’ve been working with London Research and Rare: Consultancy developing a report looking at the impact of the working environment on staff morale and performance, with a particular focus on the impact of a merger or acquisition on culture.
Those taking part in the survey will get a free copy of the research when it is published in the spring.

Take part in the Survey here. (closes March 9th)


You can read more about culture and business agility in the book.

For MORE exclusive content related to our book on Building the Agile Business, you can sign up here.

Image source

The Problem With Project Reviews

By | AgileBusiness, Leadership, Strategy | No Comments

In large organisations that are characterised by quite controlling cultures the shift from traditional waterfall to more iterative process and project management can often feel full of risk, since it involves moving away from the kind of rigid stage gates and associated phased forecasts that can help leaders to feel comfortable about approving a business case. And yet the irony is that in the context of rapidly changing environments, these set forecasts can often be more damaging than they are helpful.

One of the challenges of waterfall project management in this context is it’s inflexibility. Rigidly sticking to a plan when all around you is changing can accumulate unseen risks that are only exposed once the project output is live. Hidden assumptions that remain unvalidated can sometimes grow risk to significant proportions without managers realising that there are assumptions being baked-in. In inflexible, hierarchical cultures projects can also accumulate political momentum which can make them very difficult to kill off. Executives who are associated with the project want it to continue for as long as possible in order to avoid the political fall-out that can come from ending an initiative. Which in turn can also accrue risk. In The Startup Way, Eric Ries has a neat way of expressing this:

‘Cancelling a project often has significant political consequences. As a result, companies don’t do it nearly often enough. Once a project starts to gather political momentum, it becomes hard for a stage-gate process to stop it. Middle managers are forced to act like executioners – when they do have to kill a project, it’s usually quite painful.

In fact, I’ve sat in on a lot of corporate reviews over the years. Most companies use a ‘green, yellow, red’ evaluation system to determine where a team is in terms of hitting necessary milestones. Generally speaking, if there are ten criteria for conducting the evaluation, every team always seems to present seven greens, two yellows, and one red. It’s like magic – they’re always the same!

Why? Every manager knows that if you show too many greens, you won’t sound credible. On the other hand, too many problems could get your project cancelled. Managers are perfectly calibrating their status updates to what is needed to pass through the gates.’

As Eric Ries also points out, the amount of time and energy invested in generating these narratives around how the project is progressing is huge.

Being more ruthless about prioritisation. Making smarter decisions about the progress and potential of initiatives. Identifying what you are going to stop doing in order to create space for the new. And balancing the persistence needed to realise long-term visions with the emotional and intellectual intelligence to kill off projects when it’s right to do so. These are all leadership qualities that have never been more important.

For more like this, order your copy of Building the Agile Business Through Digital Transformation, or you can join our community to access exclusive content related to the book.

Image source

Making Decisions and Business Cases the Amazon Way

By | AgileBusiness, Culture, Disruptive Innovation, Leadership, Strategy | No Comments

AmazonWhen I work with leadership teams, one of the most common perceived barriers to greater agility is the way in which the business makes decisions. In many larger companies this is typically characterised by one-size-fits-all decision-making and lengthy business case documentation or powerpoint presentations filled with extensive projections based on very little. It’s a painful, broken process.

Somehow we feel more comfortable with a powerpoint presentation that sets out a linear progression for the project with set stage gates and forecast outcomes at every stage, even when those forecasts are based on contexts that are highly likely to change, or projections extrapolated from past data that is already out of date. It’s false certainty, and simply creates more work in justifying why you’ve moved away from those forecasts as the project progresses.

Far better surely to acknowledge when contexts are likely to shift, to set a directional course and a vision for the project outcome, but then be more fluid and adaptive in how you achieve that vision. Tracking progress towards a goal is important, but we need to be more adaptive than a linear set of rigid targets set out at the start allows for and instead be smarter about how we fund projects and track leading indicators.

The Jeff Bezos approach to decision-making at Amazon is instructive here. Executives in many of the organisations I deal with often complain about slow decision-making in the business. In his most recent shareholders letter Bezos describes how many larger, well-established enterprises make high quality decisions, but make them slowly, adopting a a one-size-fits-all approach to decision-making which is typically characterised by waiting until you have 90% of the information you need before making your choice. In many cases, he says, many less complex or easily adapted decisions can be made with around 70% of the information you wish you had. But it’s more advantageous to make the decision and course-correct if necessary than it is to slow everything down.

Similarly, a culture of consensus-driven decision-making where all stakeholders need to be aligned before you move forwards with something can also slow the company down. Amazon use a phrase “disagree and commit” as a useful way of acknowledging disagreement whist enabling the project to progress rapidly. High-velocity decision-making enables larger companies to act and behave like much smaller ones.

The Amazon approach to business case generation and approval is also instructive. Bezos famously banned powerpoint (as long ago as 2004) as a way of presenting a case, saying:

‘The traditional kind of corporate meeting starts with a presentation. Somebody gets up in front of the room and presents with a PowerPoint presentation, some type of slide show. In our view you get very little information, you get bullet points. This is easy for the presenter, but difficult for the audience.’ 

Instead, Amazon meetings are structured around a 6 page explanatory ‘narrative’ pitch (shortened for less in depth decisions). The first 20 minutes of a team meeting is spent in silence reading the pitch, after which the presenter fields questions and a decision is made. Says Bezos:

‘The reason writing a 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related.’

The data-rich six page narratives follow the same structure:

  1. The context or question.
  2. Approaches to answer the question – by whom, by which method, and their conclusions
  3. How is your attempt at answering the question different or the same from previous approaches
  4. Now what? – that is, what’s in it for the customer, the company, and how does the answer to the question enable innovation on behalf of the customer?

The approach allows for deeper thinking, better decision-making, better use of time, and also reduces the role and influence of politics in the process. Many large businesses that I deal with are choked with powerpoint presentations. The ‘narrative’ approach is a simple way to make better decisions faster.

When it comes to making decisions about product development, Amazon famously use a ‘working backwards’ approach that seeks to work back from the customer rather than starting with a product idea and trying to find a justification in a customer need. The product manager typically begins be writing an internal press release (with the end users as the imagined audience) about the finished new product, that describes the customer problem and how the new solution will be a marked improvement on the existing one. An example outline (quoted from here) to the press release may look like this:

  • Heading – Name the product in a way the reader (i.e. your target customers) will understand.
  • Sub-Heading – Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
  • Summary – Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
  • Problem – Describe the problem your product solves.
  • Solution – Describe how your product elegantly solves the problem.
  • Quote from You – A quote from a spokesperson in your company.
  • How to Get Started – Describe how easy it is to get started.
  • Customer Quote – Provide a quote from a hypothetical customer that describes how they experienced the benefit.
  • Closing and Call to Action – Wrap it up and give pointers where the reader should go next.

Taking this approach tests whether the solution and the benefits are exciting enough. If they’re not it doesn’t get built. The product manager has to iterate the release to capture benefits that are more interesting but iterating on a press release is a lot cheaper and more efficient than iterating on the product itself.

This may sound like a relatively minor element in supporting business change but is fundamental. Decision-making processes in many large businesses are no longer fit-for-purpose. The process for business case generation and approval is broken. It really is time for a better way.

For more like this, order your copy of Building the Agile Business Through Digital Transformation, or you can join our community to access exclusive content related to the book.

Image source

Context Mapping for Business Transformation

By | AgileBusiness, Organisational Structure, Strategy | No Comments

When I work with clients in digital and business transformation programmes one of the key questions that often arises focuses on the application of iterative working practices and wider agile principles across the organisation. Our book makes the case for the broader applicability of agile thinking, resourcing and ways of operating in the service of supporting transformation, continuous experimentation and innovation. We’re describing a fundamental reorientation of the business to a wholly different type of organisation that is characterised by flexibility, manoeuvrability, learning, and continuous improvement.

Transitioning to these newer approaches can be hugely challenging for businesses that have been schooled for decades in Waterfall thinking and culture. Much of what organisations think they know has to be unlearned and put back together again in a different way. It can often be uncomfortable for people across the company. If not done properly, there’s a high probability of drift and failure.

Iterative approaches to value creation are typically undervalued and under applied in most companies, yet are central to transforming business for the digital age. But what we’re not saying is that Agile, or other iterative processes or version of Agile, should be the default way of working right across the organisation. Questions about the scalability of agile approaches run alongside questions about where we should apply them and, just as importantly, where we should not (in fact I’m working with a large, global telco business right now and these are precisely the questions that they’re working through). In order to determine the answers to these questions we need to take account of the different context and environment in which functions, disciplines, tasks, and areas of the business operate and apply appropriate methodologies, capability types, roles and ways of working. Context is everything.

In other words it’s not only about doing Agile, but about being agile. Whilst we need to consider which areas or functions of the business should work more iteratively or in small, multi-disciplinary teams, we also need to consider which areas of the business should not. We need to think about how the latter can support the former, how we can bring people on the journey with us, and be aware of the tensions that will naturally arise from introducing new ways of working. We need to create enough space to enable a new culture to thrive, whilst ensuring that the degree of separation does not hamper broader learning or change. In other words it’s about agile as a culture, and not just as a process.

Building out from the concepts and frameworks outlined in the book there’s a way that I’ve found useful to describe to clients a sensible approach to solving this challenge. The approach is founded in the different ‘jobs-to-be-done’ that the business has. In some domains the problems will be ones which are characterised more by known quantities and the objective more about best practice and driving efficiences. In other domains, the tasks will be more complicated or complex, with far higher degrees of uncertainty and unfamiliarity. But the point is that the organisation needs to accommodate a robust way of handling all three domains, and apply appropriate responses, processes and thinking to each one (this framework draws on the work of Simon Wardley who has widely explored organisation situational awareness, and his thoughts on pioneers, settlers and town planners, Dave Snowden’s work on Cynefin, and concepts such as three horizons thinking). The framework reflects three key domains:

The differences between the domains define the organisational response:

Domain One: Relatively stable environments, higher degrees of certainty. 

This domain is likely to be defined by established, well developed, relatively enduring contexts that change slowly. The challenges are there, but they are characterised more by ‘known knowns’. Perhaps the market is mature, and the company’s proposition well established. The need is for common ways of doing things, scalability, and best practice. There is value in innovation, but this is focused on innovating on core capability to drive incremental gain or to drive efficiences and better ways of doing what you do now. This domain is well suited to those people who are exceptional at operationalising, optimising and institutionalising.

Domain Two: Evolving contexts

Domain Two is characterised by a higher and faster level of change than domain one, or more known unknowns. The business can identify what it doesn’t know and set out to fill the gap or to learn. The problems have more variables than domain one and are complicated, so the response needs to be founded in developing and exploiting expertise. The focus is more on test and learn, and iterative working to adapt existing capability, innovate in adjacencies, and commercialise and evolve ideas so that they can be scaled, but the rhythm is not necessarily as fast as domain three. This domain is suited to people who are great at developing models that work in the real world, who can define the operating model or revenue opportunity.

Domain Three: Rapid change, high uncertainty

In this domain, there are plenty of unknown unknowns. The problems that the business is trying to solve are complex, the context far newer, the response is emergent by necessity. Iterative working is the only way of navigating this complexity and creating value in this ambiguous environment. This is new capability, future facing ideas, exploration of entirely new propositions, the kinds of ideas that may disrupt the existing business or take it in a new direction. This is the domain of pioneers – lateral, creative or visionary thinkers who can visualise a different future.

Joseph Schumpeter defined innovation as a three stage process of ideation or invention, commercialisation and scaling or adoption. If the organisation is to survive in the modern business world, it needs to innovate continuously and it needs to be good at all three of these things. It needs a continual flow of new ideas, space to harvest and nurture those new ideas, and the ability to scale and operationalise. It needs to be good at all three domains. It needs to allocate sufficient resources to each one, and it needs to apply appropriate processes and thinking.

New propositions in the business may start out in domain three, move toward domain two, and end up in domain one, but as they progress the types of people that we need working on them will shift, and the approaches and ways of working that we apply will also likely evolve. Large organisations may well be comfortable with waterfall thinking and processes but the application of more iterative working methodologies like Design Thinking, Agile and Lean can help them to explore new and adjacent territory in continuous and competitive ways, and to develop new ways of thinking and operating that can scale far beyond the innovation lab and help transform the business. But only if the newer ways are not suffocated by the old. Whilst key parts of the business will need to be doing Agile, every part of the business will need to be agile. It’s time for a far more holistic but contextual view of the business transformation.

For more like this, order your copy of Building the Agile Business Through Digital Transformation, or you can join our community to access exclusive content related to the book.

Image source