More on this book
Community
Kindle Notes & Highlights
by
Jason Little
Read between
March 25 - July 5, 2017
For example, in a culture that values stability and control, optimizing process and stripping out bureaucracy can improve performance. That doesn’t mean the culture has migrated to one that doesn’t value stability and control. It also doesn’t mean people in the organization made a mindset shift (or changed their overall culture). It simply means the organization is performing better because they learned how to improve the attributes of their existing culture.
In an organization that values control and process, optimizing those processes by cutting out red tape doesn’t mean a culture change. To that organization, it means process optimization.
The same question is indirectly raised again — is it possible to change culture by tweaking process? Can a change in process cause a change in culture? One the one hand it's a category problem (a member of a set cannot be the set itself), and Conway's Law tells us that whatever we do we will always end up spitting out but copies of ourselves. It wouldn't be unlike ordering people to have fun, or forcing democracy onto a tribal society. Without the vocabulary of mental representations, the new concepts will not be integrated in the culture.
On the other hand, IT is not the only area where humanity tried and succeeded to introduce constructive change. Consider how institutions had to change with advances in human rights, but also consider adoption of new forms of communication, and even just successful product deployments — the dynamic is not new. We have to be able to explain new things using the old things as the alphabet. Therein is the limitation of Conway's Law, but it doesn't fully apply here: the basic building blocks already include concepts of family, empathy, cooperation, etc., while our objective of creating a harmonious working environment can be communicated in those terms. Therefore, aren't changes in culture and process inseparable, and neither will endure without the other?
As an example, I didn’t observe a radical shift to an Agile mindset at The Commission. What I did see was extremely painful daily standup meetings in front of our EKB. After a while, those standup meetings became the norm. That change was anchored into the culture, but the culture was still one of process and control.
Peters and Waterman pointed out that if you wanted to diagnose and solve organizational problems, you needed to think about more than just the structure. They identified six other related factors, which they considered to be just as important: Strategy, Systems, Skills, Style, Staff, and Shared values (called “Superordinate goals” in early versions of the model).
Kotter’s Eight Steps: Think of Kotter’s eight steps as the list of ingredients that go into a successful change recipe. But don’t go through the steps in a linear way like an actual recipe. Instead, treat them as a guide. A guide that helps you navigate the messy process that change really is. I use Kotter’s framework as a checklist of sorts. I want to make sure I’m addressing the concerns of all eight steps through a variety of methods and practices. McKinsey’s 7S: McKinsey’s 7S is a powerful framework I use to map out the dynamic elements of change and anticipate the ripples each change will
...more
Traditional thinking says that you must follow a process and create a plan. Lean Change Management says, collect Insights first in order to guide and shape your process and plan.
Lean Change Management will help you build your own change process that is adapted to your organization’s reality. The process you create and follow will evolve over time as you learn how your organization reacts to change.
One approach is to use tools from the Lean world, like 5 Why’s, and root-cause analysis, which are great for exploring the problem. The theory is that by lingering in the problem space, you understand the problem better and only then can you come up with the right solutions.
Consider the "Feynman algorithm" — think real hard until you find a solution
Another approach is to focus on solutions. Some feel this is a better approach because it relies on thinking about a future state where the problem doesn’t exist, rather than dwelling on the problem. This is called solution-focused thinking, and it has its roots in the therapeutic approach called Solution-Focused Brief Therapy 1(SFBP) devised by Steve de Shazer and Insoo Kim Burg. According to this theory, change happens when people construct solutions, rather than dwell on problems. The question associated closely with SFBP is referred to as the Miracle Question: “Suppose you went to bed and
...more
We were transforming to a new state at The Commission, so in some respects, we wanted to ignore the current state, and the reasons why agile “wouldn’t” work. In Lean Change Management, Options are designed to help people take an action that will get them to their desired future state without worrying about the current state.
The inevitable response to this is that if we ignore mistakes we're doomed to repeat them. How do we counter that?
Perhaps it's similar to a situation where the resources that would have otherwise gone into R&D are now fixing legacy configurations, sometimes even having to copy dysfunctions to ensure continuity. A simple metaphor is that of burying one's head in the sand.
Another rebuttal is that a general change in direction is what is needed. The metaphor here would be of trying to fix the car that's going the wrong direction.
Anyway, is there a class of problems for which the solution involves moving the focus away from the problem itself? Which psychologist said that we grow out of our problems more often than resolve them? Consider, for instance, category types — the problem can be viewed as that of identity, ability, circumstance, location, etc.
That’s the difference between transformation and change. In order to change a process, you need to play in the problem space for a while to truly understand it. In order to transform to a new organizational state, use solutionfocused thinking to get to that desired future state.
If your conversations about Options generate many “That won’t work here because…” statements, dig deeper into the reasons why you think it won’t work. That may help you discover less disruptive Experiments to run.
If you only have one option, you have no options. If you have two options, you have a dilemma. When you have three options, only then do you truly have Options.
Charlan Nemeth concluded that being exposed to alternate views expands our creative potential. That’s because our brains try to make sense of the silly Option, which causes us to re-evaluate our initial assumptions about the problem we’re trying to solve.
Using the word cost helps stakeholders realize that all actions in the change plan cost the organization something.
Another consideration for assessing cost is thinking about the un-intended consequences the Option may bring. Since the McKinsey 7S Framework points out the interconnections between facets of the organization, why not use that framework to try to anticipate chain reactions, and the costs associated with managing those?
Lewin’s Force Field Analysis is another way to uncover costs that help mitigate the risk of implementing the wrong changes. If you see strong opposing forces to a particular change, you’re going to have a higher cost trying to implement that Option.
the QMO met weekly to plot new changes on our cost-versus-value chart. When it came time to dig deeper into Options that we thought would be high-cost, we used two specific types of visualization to help us think through the change:
1. Blast Radius: Brainstorm and list the intended and possible un-intended consequences of introducing this change.
2. Sphere of Influence Diagram: How hard would this change be, given who would be affected by it? For example, are the people affected by the change outside our direct sphere of influence? How would they react to someone outside their department suggesting they change how they work? Conversely, how could we leverage people within our sphere of influence to help us implement the change?
you’ve generated Insights about your organization, and some Options that consider the unique characteristics of your organization. For those Options, you’ve considered who is affected, where the support might be, and where the resistance might manifest. Now consider how these Options fit into your overall change plan by classifying them based on what you’re trying to accomplish. Going through this exercise will help you see if you’ve added all the elements that are needed in any change initiative. In Chapter 5, I mentioned that I use Kotter’s 8-steps as a checklist, not a linear process to
...more
Options that, after understanding the blast radius and sphere of influence, definitely won’t work now, but might work later. The reason you keep them here is that you’ll gain some Insights when other people see them and ask you about them. Putting those seemingly impossible ideas into people’s brains might eventually morph them into “you know what, that’s not such a bad idea!”. Remember, just because you think it won’t work, doesn’t mean it can’t work. At the Commission, we would review our Abandon list monthly and throw out any stale ideas.
The analysis of abandoned options generated some knowledge, and it has value. We wouldn't want to have to repeat the research that led us to that conclusion. On the contrary, we want to build on top of that knowledge. It may have also brought with itself additional Insights that may lead to other Options.
“Let’s start all projects in the red, then move them to green status once we know they are on target”
This seems quite natural considering that this is exactly how unit testing works — all tests are red until the code is written that satisfies those tests, and they become green.
software teams discover risk early in the project, and have the most questions at this early stage. However, by the time the status report drives through the chain-of-command carwash, it’s shiny, polished, and green. Uncertainty is at its highest at the start of the project, so start red and learn your way to green!
the change team spent a great deal of time thinking about changes. It is only natural that it should take the affected people just as much, if not more, time to reach the level of understanding the change team have about the change.
This certainly seems true for the types of change that requires a gradual discovery and exploration of new terrain. Other types of change, however, are revelatory in nature. Agile and Lean approaches aim to make workplace more open, more humane, and more efficient by removing obstacles, and allowing teams to self-organize naturally. Thus, coworkers would hardly need training to participate in Lean Coffee, or to use merit money — we all already know how to act naturally.
Change teams spend lots of time designing ways to introduce change, this same type of thinking is not required on the part of the affected people.
Calling changes “Experiments” helps you develop an approach that makes it ok to not know everything upfront. It will also help you be more creative and learn while the change is in progress.
All Experiments start with a hypothesis. Early on at The Commission we were deliberate about creating hypotheses for all the changes we wanted to implement. After a while, we stopped creating hypotheses, except for changes that had a large blast radius or high uncertainty.
Here’s how I wrote down my hypothesis at the time: I hypothesize that by changing our Enterprise Kanban Board (EKB) to be a portfolio-level board, we can eliminate weekly status reports PM’s currently produce, thus reducing their administrative activities, which will save the department $150K annually, as measured by the time it takes 25 PMs to generate these reports. A colleague and I mocked up a “status-y looking” visualization on the Enterprise Kanban Board (EKB), leaving it intentionally roughlooking around the edges. The goal was to get feedback quickly, and not to have it perfect right
...more
We hypothesize by <implementing this change> we will <solve this problem> which will have <these benefits> as measured by <this measurement> This template helps change agents get into the mindset of being explicit about Experiments. You’ll get better at measuring your Experiments when you explicitly state the benefit, measurement and goal for them. Another benefit is that the template uses plain language that everyone can understand,
During our team retrospective I brought up my observation that as a change team, we were too focused on checking-off change tasks as complete, instead of being focused on outcomes and validation. How could we validate if designing these new frameworks and processes were the right things to do?
“Validation” in Lean Change Management means confirming that the change you’re planning is the right one to focus on for that particular time, before you spend all your time and effort designing a change that is likely to hit a wall of resistance. (Remember, resistance is the signal that tells you it’s the wrong change for that particular time.)
two important steps during the creation of your Experiment. The first step is done with your change team, and involves asking two questions before running the Experiment: 1. How will we know this Experiment has been successful? 2. How will know we are moving towards our intended outcome? The second step is to review your Experiment with the people affected by the change to see how they react to it. If they react violently – metaphorically speaking – your Experiment might be a bad idea! Or it simply might not be the right time to introduce it. In contrast, early on at The Commission, the
...more
Measuring behavior can be dangerous. As soon as people feel they’re being measured, they begin to feel threatened. This is a false feeling, and definitely not the intent, but nonetheless, that’s usually what happens. The intent behind the behavior measurment was good, but the negative feelings it generated with the staff didn’t help the change team gain trust and credibility.
It is clear that whatever is being measured will receive more attention, and in most cases, will increase. It works well with hard measurements like minutes on the phone or defects per 100 lines. It is conceivable, however, that the same logic cannot apply to "soft" factors such as congeniality or agreeableness. How do you objectively measure a person's contribution to a successful outcome on the basis of being more nice? Moreover, although we may have decided that higher agreeableness is desireable in a team, when applied to an individual, it is a personality trait, and as such it's clearly threatening to realize that one's personality is on trial.
There are more important things to measure than people’s behavior: Did the people affected by the change get the outcome they thought they would? Has this Experiment improved something for them or made them happier? For example, when organizations adopt Lean and Agile software practices, they expect teams to deliver higher quality software. That’s the outcome, and it can be measured by a reduction of problems reported by customers.
This Experiment included talking with the team about a number of different practices they could use in order to produce higher quality software.
It wouldn't be dissimilar to offering better ways to hunt or to cook in the prehistoric context. Curiously, in gamification, researchers have been able to identify preferences for different types of
Implementation of better software practices leading to fewer defects as measured by in-process defects and escaped defects. The team tracked and categorized defects found in the team (inprocess defects) and they tracked requests for changes requested from outside the team (escaped defects)
A cross-functional team allowing the team to deliver their work sooner because there would be less time wasted on hand-offs between functional teams. For this validation, we used a simple, “softer” validation.
One of the reasons I believe this Experiment worked is because we involved the team in the design of the change by giving them control over which practices they felt were achievable. I refer to this as “co-creation of change”, because the people affected by the change are involved in the design of the change. They help decide what changes to implement, and how to validate that the Experiment worked.
Big companies “can’t” do this: Well, that’s what they all say. “Can’t” actually means, “This approach won’t work in our culture.” It sounds good to “co-create change” but some people felt necessary structure was missing from this feedback-driven approach. The perceived lack of a plan up-front was unsettling for them.
Indeed. Statements like "it won't work here" all come down to the incompatibility of the desired behaviour and the processes that are currrent at the organization.
