Pulled Change: Sustainable Change That Spreads Organically

If you want sustainable, human-centric change, you need to allow for people to “pull” the change into their world by choice.

How Change Spreads

When suggesting organisational change of some sort, the reception tends to be mixed (even if it seems positive on the surface). Some people and teams will be ignited by idea. They have been longing for this and can’t wait to get started. Some will be neutral, others turned off. The principle of pulled change informs us to start with the people that are ready to go, because they are most likely to get going by introducing something new into the team. In other words, to pull change into their world1.

One way of looking at this is through the lens of the innovation adoption cycle. This curve depicts how new technology or ideas spread through a population. We can use it for thinking about how new ideas and ways of working spread through an organisation.

Photo from Wikipedia

To allow for change to be pulled in, we avoid spending time trying to convince late majority and laggards. These groups are very conservative and would need to be forced, which we don’t want to do. Basically, they will only consider trying something new when every one else is doing it. Instead, we can use the change power of innovators and early adopters to create references. These references will be needed to win over the early majority. When half of the company has changed, the rest will happen by momentum.

This is not to say we shouldn’t talk to “the resistance”. You can gain incredible amounts of information from just listening to people who don’t want to participate. And sometimes, just from listening well, they change their minds. All I’m saying here is not spend time trying to sell it to the most conservative group first because they won’t buy.

Setting a Bad Example

Another application of this principle is to let a team pull in new practices instead of inflicting change on them. As an illustration, let me tell you a story of a failed change of mine.

Some years back, I was a manager for a development team. We had worked together for a couple of months and things were looking good. We knew each other and I could see signs of them taking responsibility and owning their world, but at the same time they had so much to learn.

They had no scheduled team learning session so I set up a weekly hour for this purpose, assuming they would understand the importance of learning and benefit from my immense knowledge (ha ha). For the first session, three out of eight team members turned up. We did TDD katas and I thought the low participant number was just a coincidence. Next week, again, three people. Now I was getting worried. To the 3rd session, no one came. After 10 minutes, two representatives from the team showed up and told me that the team did not see enough reason to come to these learning sessions.

“What!?” I was hurt. Why go the extra mile as a manager for this kind of response? But I also felt a bit ashamed. I realised I had skipped the ground work and had tried to push a new practice on the team. After some thinking, I also realised this was another sign of the team becoming more self-organized. Just because I valued learning so much I thought they did as well. I still believe they would have had fun and learned tonnes, but that was not good coaching on my part. As Aaron Dignan would put it, we need to do it through them, not to them.

A pull system. Photo by Astrid on Unsplash

Why Pull?

Why let people pull in change? Why not just tell them what to do? After all, they’re getting paid to work. The reasons for this detour are two-fold: Sustainability and respect for people.

To me it seems obvious that shallow or unsustainable change is meaningless. What is the point of ticking the boxes, except ego comfort? What’s the point of compliance when you’re looking for engagement? The results are often disappointing and the change quietly discontinued. If you want sustainable change, you need to let people chose themselves.

This is also a more people positive2 stance, based on the fundamental belief that people are capable and intrinsically motivated to do a good job3. Finally, it comes down to one of the Toyota Way pillars: Respect for People4. Pushing change on people is disrespectful and too bossy for my taste.

Dealing with the System

With this reasoning we could well be faced with a situation where we really see a need for change in the organisation, but we can’t push it onto people. That seems impossible. How would we go about?

Flow where you can. Pull where you must. Never Push. — Kanban mantra

For this, I’d like to take some inspiration from Kanban, a method for continuous improvement based on flow and visualisation. We could view change as a kind of flow. My approach has three parts:

  1. If change is happening regularly on its own, recognise and encourage this.
  2. When change is not yet happening, change the conditions for change. Spend time understanding what’s preventing change. Be confident that when the conditions are right, change will be pulled in.
  3. Never push change on people.

The most interesting and common situation is when change is not happening even though we think it should. We have told them why, we have painted a vision poster together, and given them training, but things just continue as they always have.

For the immature or misguided leader, this is a sign of incompetence. “We have told them what to do and they’re not doing it. Are they stupid?” (Hint: Probably not.) That’s when you start hearing comments about “a need to drive change” and questions from the CEO about who’s leading the resistance. This is when organisations start pushing change onto people. Please avoid that path.

Unless the team takes ownership, sustainable change is not possible.

A much nicer and I think more interesting route is to genuinely ask yourself: What could be the problem? Now you get to use your curiosity. Now you are a detective. In my experience, the main suspects are to be found in the context (or system) around the group or in the group mindset. My primary suspects are organisational structure, leadership behaviour, and team working climate.

There could be structures in place that prevent change from happening. Perhaps there are incentives involved? Perhaps there is a process or policy in place that counteracts our goal? Is there is an issue in the way our goals are defined? Perhaps surprisingly, it’s not uncommon for neighboring groups and departments to have contradictory goals. Or did someone make an unsubstantiated promise and is now trying to save face?

Perhaps it’s a leadership issue? What behaviour is typically rewarded in the organisation? Are people feeling safe enough to mix things up? What if we fail? How have we been treating failure in our organisation? And what questions are the leaders asking publicly? Are they asking when it’s done (bad) or are they asking what we have tried so far (good)?

Or is it in the group dynamics? Perhaps the team harbors an unhelpful belief around work? For example, after years of mismanagement, it’s not unreasonable for a team to feel like victims; just pawns in the game being shuffled around with no agency of their own. It’s not unreasonable, but also not helpful. Sometimes, things have changed but people haven’t noticed yet. Unless the team takes ownership, sustainable change is not possible.

As a leader, when you have discovered what’s preventing change you have change work on your own. Working on the system is change work for leadership. Use the same approach as your team. You know the current condition, you know the outcome you’re after, and you know at least one obstacle. Can you come up with an experiment to change the conditions? How would you recognise success in that case? Keep working on the conditions until change comes easier.

Patience and a curious mindset are your friends when you are guiding people through change.

1Credit to Bjarte Bogsnes, who was the first one I heard articulating organisational change as a “pull-based approach”.
2Expression from the book Brave New Work by Aaron Dignan
3Fundamentally, Theory Y over Theory X
4The Toyota Way, as described by Toyota

Think Big, Start Small

When working with any form of change we need to Think Big and Start Small. We need to both conjure up a better world and start with a small change that could have an effect in the right direction. This goes for any type of complex change, be it in product or software development, enterprise architecture or process improvement.

Greta Thunberg was 15 years old and she knew we needed radical, societal change to sustain a habitable world for her and future generations. She imagined a world without fossil fuels. What did she do? Did she write and propose radical (and youthful) environmental changes to the Swedish government? Or did she decide to study to become an academic so she could speak with more credibility? None of that. What she did was both simple and brilliant: One fine Friday she skipped school, painted a simple sign, went into the city, and sat herself down in front of the Swedish parliament building. Just a kid with a sign. That’s it. Today, #FridaysForFuture is a global protest movement.

By following our Think Big motto we allow ourselves to imagine a positive future. We use our hopes and wishes for the future to find a shared belief in a new, favorable situation. It could be in the form of a North Star, a vision poster, a desired state or any kind of image of a future we’d like to create.

There is much power in this, as it kickstarts the engine of change within us; saying to ourselves: “It doesn’t have to be like this. I can see a better way now”. Without a shared vision, very little will pull us in the direction of change. We desperately need pull to overcome our intrinsic inertia.

If Think Big is our Yin, then Start Small is our Yang. By following Start Small, we allow ourselves to naively ignore all that work and all those obstacles and difficulties we will need to overcome to reach our goal. And just start. All we need to do is to take a good, first step in a direction that looks about right.

For a product, this could mean solving just a part of the problem, in a specific situation, for a certain type of customer using a specific device, etcetera. We need to get specific. For an organisation, it could mean just finding one aspect of your goal, thinking about what’s not working in the current state and identify something you could try instead.

There is huge power in this as well. The power of taking action. Without action, it’s incredibly easy to get stuck, paralyzed by all the complexity and uncertainty.

Thing Big, Start Small may sound mundane but in my experience from the business world, it’s not that common at all. Most software teams I work with are handed big problems and create big solutions for them. Many organisations create massive “transformations” to rethink, not only their organisation, roles and processes, but even organisational culture. Big solutions to big problems.

The problem of big solutions is rooted in one of the human biases that we all share: Belief bias. In simple terms, Belief bias can be described as evaluating statements and accepting them as true, not primarily based on their logic or objective fact, but on how credible they seem to us. That means, for a big problem, we tend to look for solutions of similar size and complexity. Trivial solutions to a big problem are just not credible.

To overcome a pandemic merely by washing our hands, coughing in our armpits, and staying home when feeling ill, just seems wrong to many of us. It’s not enough! We should hoard toilet paper, close the schools, and force everyone to wear a protective mask. Even if it’s not rational, not based in science, and ignores consequences from those measures, at least it feels appropriate1 2.

Thinking big and working big is an anti-pattern. It gets us into all kinds of trouble. Analysis paralysis, lack of customer focus, long feedback loops, and loss of engagement, just to mention a few effects of that way of thinking. If you’ve ever seen a government IT contract with an outsourced development company cancelled after 3-5 years with not discernible value you know what I mean. Typical outcomes are projects without value and change efforts that run out of steam.

Starting small and then continue working in small steps give us ample opportunity to find value early and get feedback that will allow us to become better. This is the agile way. But it also creates momentum and gets us results early. It’s always hard to see that we’re making progress in a complex world but a series of many small achievements is an indication, at least.

If you want to go places, combine your big thoughts with small steps.

Working in small steps in an iterative and incremental fashion is probably not news to anyone who knows anything about agile development. However, combining this with thinking BIG was probably first articulated to me in the Unlearn podcast with Barry O’Reilly, which has “Think Big, Start Small, and Learn Fast” in the introduction. I recommend checking it out.

1 Pandemins psykologi (“Psychology of the pandemic”, in Swedish)

2 I’m not saying these measures are necessarily ill-advised, just that, from what I understand, there is little scientific support for them at this time. But hey, I’m no epidemiologist so save your rants. Well okay, hoarding toilet paper was probably neither particularly clever, nor kind to your fellow citizens.

Earlier posts in the series on principles for organisational development:

  1. Nothing Ever Lasts but Change
  2. Include the People Involved
  3. Start by Changing Change

Start by Changing Change

This is the third post in my ongoing series around principles for organisational development. The earlier articles were:

  1. Nothing Ever Lasts but Change
  2. Include the People Involved

Start by changing change. What do I mean by that? What I mean is that I believe that the most sensible way to start developing an organisation is by improving how they work with change1. I think we need to make change itself and the skills associated with change an integral part of the start.

Otherwise, if you don’t start with change, all change will need to be imposed on people. And that’s a much harder proposition than involving people right from the start2.

What’s all too common is to start with a framework, a bundle of practices that may be “Turing complete” but not make sense in our context. “All teams must use Scrum”, is an obvious example. By doing this, you are pushing a bundle of practices onto a team of professionals, which is rarely appreciated, to put in mildly2.

If you are skilled change artist, then any change after a first change cycle will become more manageable. The first changes will be slow since everything is new. Every vision must be created, every current state measured, every new skill learned. But gradually, the pace of change will increase.

For example, let’s say the leadership team in a typical enterprise of today (with managers and an IT department) demand more transparency from the Development department. Stakeholders outside of IT have been getting increasingly more annoyed.

Before actually starting we need two things: 1. A large-majority commitment to a new direction2, and 2. Everyone involved trained in how systematic, sustainable change works. I would suggest using a meta-model like the Improvement Kata3. People need to understand how we will follow up results (excellence is good experimentation, not necessarily great results). Most of all, participants should be asked to entertain the idea that daily improvement is important, that change is actually real work.

With this out of the way, I would consider working in this fashion.

  1. Facilitate establishing a shared vision or North Star, an ideal that we may never reach. In this case, two items of the vision could be “Every stakeholder can pull accurate and understandable information on all software changes on demand” and “We respond to each idea or change proposed to any of our teams without delay”.
  2. Coach the teams in assessing the current situation. In our example, the stakeholders only receive information once a month from some of the teams during their software demonstrations. Most ideas seem to disappear into to the void. Stakeholders are frustrated.
  3. Facilitate setting a challenge for the department. Consider using something akin to the OKR format, combining both an engaging objective with metrics on progress. In this case, one objective could be “Give business developers a good understanding of our work in progress”. One metric could be a survey to assess the way business developers rate their understanding of ongoing work; one baseline and then metrics relative to that.
  4. Coach each team in setting up their own improvement cycle. They will need an objective (a desired state) in harmony with the transparency direction, an assessment of the current situation, and a first experiment. Actively support them through that first one. Help them set up a metric for the result. Facilitate assessing the result and setting up the next experiment. Help them visualize progress.
  5. Coach leaders coaching teams on improvement. It is vitally important that they ask the right questions. Good question: What is your current experiment? Bad question: When will you be done with the improvement? Support them in their first attempts at following up on team progress and visualizing the overall progress towards the objective. It is essential that managers are involved and engaged. Otherwise, people will assume it’s not that important.
  6. Keep doing this until the challenge is reached or we feel it’s good enough for now and should move into another area of improvement. Go back to step 1 to refine the vision and start again. By now, the managers and the teams have not only improved, but actually learned the basics of continuous, sustainable improvement at the same time.

That was a short description of a first run through the improvement cycle. For the first run, I wouldn’t put too much at stake on the actual improvement. It’s not the point right now, more of an excuse to practice.

The next lap will be easier. Most of the structure will be in place and everyone knows the basics and what is expected of them. With each iteration, the coach may step back a bit until they can fly on their own.

After a number of these cycles, if handled mindfully, people will now see real benefits of not treating improvement as a possible side-project when we have time. And the organisation will have the basics of a learning organisation and culture, an essential capability in a digital world.

Warm thanks to Mike Burrows, Agendashift and Mike Rother, Toyota Kata, for your wise thinking around improvement.

1This is not always the best way to start. One reason for not starting this way could be that the working climate of the organisation is toxic or just unproductive. In that case, nothing will work and you need to start there.
2See my previous post: Include the People Involved
3See Toyota Kata by Mike Rother

13 Guidelines for Successful Software Demonstrations

Just for fun last night, I started compiling a list of my best guidelines for live software demonstrations (“demoes”). I turned into quite the list so I thought I’d put it out there to see what you think of it. Anything you would remove, change or add? Which one do you like the most?

Guidelines for Software Demonstrations

  1. Send out the agenda in advance (what will be reviewed). This will allow everyone to decide if they want to come or not.
  2. Prepare and test in advance. Use a high-level script. Pre-cook data. Keep a backup plan for the thorny bits.
  3. Use three roles: Host, Demonstrator, and Note taker. Demonstrator could alternate.
  4. Allocate most of the meeting time for looking at live software. Keep slides to a minimum. Too many meetings look at slides anyway.
  5. Prefer showing things that are ready for release, or nearly ready. This will provide the most accurate picture of current status. Avoid pretty but unimplemented designs which often leads to exaggerated expectations. Don’t show untested or buggy software.
  6. If time is short, demonstrate the most interesting stuff and list the rest for completeness.
  7. Keep it engaging and use occasional humor to lighten the mood. Role playing is an excellent technique for both.
  8. Frame each solution with the context and the problem. Explain the situation and what the customer is trying to do, or what problem the customer is having.
  9. Demonstrate at a slow pace, explaining every move. People won’t be able to keep up otherwise.
  10. If you have them, use metrics to show the outcome of the solution that was just demonstrated. This will help demonstrate how your teams provide business value instead of being a feature factory. 
  11. Encourage questions and feedback from the audience and show appreciation when you get it. This will create more feedback.
  12. Respond to all feedback, either in the meeting or, if you can’t answer directly, afterwards. People hate shouting into the void.
  13. At the end, review the road map or backlog so the audience knows what’s coming next.

Include the People Involved

In all kinds of organisational change, whether small and local or major, involving many parts of an organisation, one of my principles of change is to include the people involved. To be clear, I mean serious inclusion; as in being asked to dance, be one of the players in this game of change. If the change involves the whole organisation, then everyone needs to be invited to participate.

You need to have your people drive the change. As soon as people smell that they will be told how to work, you will get compliance, not engagement. People and teams need to have high degree of autonomy in most dimensions and be invited to participate in every important decision around the change. Not only is this ethically the right thing to do but I believe it’s also the most effective and sustainable.

K2K Emocionado is a basque consulting firm that helps organisations become self-managed (a.k.a. “bossless”). What is meant by this? Oh, just removing all the managers, turning everyone into a leader, and turning the company around from imminent bankruptcy. No biggie.

Can you imagine a more difficult job in an organisation? I can’t. Yet, their track record is amazing. So far, over 15 years, they have helped more than 80 organisations[1], mostly in basque country, with a high success rate.

How is that possible?

I think most change practitioners agree that teams should have a high degree of autonomy in how to effect change. This includes selecting what to change, which experiments to run, in what order, etc. After all, it’s their work. I don’t go around telling people at work how to do their job. That would be super rude. It would also, you know, deprive people of any ownership they might feel. Annoying, right?

Perhaps surprisingly then, the most common mistake I see is people telling other people how to do their work. It mostly happens in large corporate hierarchies, where people have grown accustomed to this kind of misguided behaviour, but it can happen anywhere a manager gets change wrong. To my mind, as soon as you impose a practice, a method or framework on your people, you don’t understand how change works.

This is an area that got me into a lot of trouble as a younger change agent and I see it in others too. I knew it was much better it teams could self-organise, including having a high degree of autonomy when it came to their working process. On the other hand, I also knew that I would have to train the teams how to perform the steps of the process correctly. Otherwise, the change will be a lost cause. So, both autonomous and be told how to work. This incoherence is unsettling.

So, the problem here is not the training but that I started from a place of imposition. The teams had to use the process. And then I wondered why I never saw any major culture change. Today, I know that humans aren’t open to changing the way they think based on behaviours that you are forcing them to perform. What you get instead is silent opposition and resistance.

“Diversity is being invited to the party; inclusion is being asked to dance.” — Verna Myers.

There seems to be more disagreement around goals. Should managers provide goals or should teams define them themselves? Product management expert Marty Cagan argues for teams to be given “team objectives” (problems to solve) since setting goals is a question of leadership[2]. (Yes, this is in product development, not organisational development, but it’s a similar process.)

On the other hand, The DORA research team on DevOps has this to say around transforming to DevOps: “A team’s own target conditions or OKRs must be set by the team. If they are set in a top-down way, teams won’t have a stake in the outcome and thus won’t be as invested in achieving them”[3]. In these researchers’ minds, it’s essential that team set their own goals.

To me, who is setting the goals is dependent on things like culture and team. Personally, I would hate having a manager tell me what improvement goals I should strive for (apart from a strategic, high-level directions, which I understand and feel meaningful to me). On the other hand, I have seen team go into a state of paralysis when asked to set their own objectives. They weren’t ready for it. On the whole, I do think that the more we can have teams defining and owning their own objectives, even the strategy for improvement, the better.

There are several factors that make K2K successful, of course[4]. They have the experience, they have done it themselves, and they do their work to “improve the world”[1], not to become rich. But here’s another factor that I think is vitally important: They ask everyone nicely.

Here’s how: When starting work with a new organisation, they paint a clear picture for everyone what the change will mean, not shying away from the difficult or painful parts. They also invite everyone to go visit one of their former clients to see with their own eyes and better understand what it could look like. Then they call a General Assembly and ask everyone to vote. Unless 80-85 % of the people vote for change, they leave. But if more than 85 % do, they have a really strong mandate right from the starting gate.

And that’s how you include people in major change.

[1] Leadermorphosis Podcast, 53. Jabi Salcedo and Dunia Reverter on K2K’s keys to becoming a self-managing organisation
[2] See Team Objectives – Action
[3] See DevOps culture: How to transform
[4] Lisa Gill wrote a very nice article for Corporate Rebels on K2K’s ten keys for self-managment.