Teamskatt och andra okända skatter

“Dags att betala teamskatten igen. Härligt!!”

I mitt jobb som konsult möter jag många kompetenta grupper och team och en observation som jag har gjort är att många av dem beklagar sig över alla aktiviteter som inte handlar om att skapa direkt värde, till exempel planering av arbetet, företagsmöten eller övningar för att lära känna sina kollegor bättre. Dessa företeelser ses med illa dolt förakt, motarbetas och beskrivs som “trams” eller “onödig administration”.

Det här är intressant, tycker jag, för jag ser det inte på det sättet. Om du är en person som ogillar alla former av möten och kanske känner igen dig i detta, skulle jag vilja erbjuda ett alternativt sätt att se på saken och en metafor som kanske kan vara användbar.


Alla former av arbete, om det inte är hitte-på-jobb, går ut på att skapa värde för någon, t.ex. en kund eller medborgare. I en ideal värld är jag som individ så kompetent att jag kan skapa det värdet helt på egen hand. Som ett tankeexperiment kan vi föreställa oss en kund som beställer en burk läsk. Eftersom jag är mycket kompetent på alla områden som behövs och kapabel att utföra alla moment åker jag iväg och bryter malmen. Därefter utvinner jag metallen, valsar den och skär till en burk. Sedan formar jag och trycker burken (med min egen design). Jag odlar vidare alla ingredienser till läsken, inklusive framställer och buteljerar kolsyra, tillverkar läsken, tappar den på burk, försluter den och ger den till kunden. Enkelt!

Det här är möjligen ett roande scenario, men, som exemplet kanske illustrerar, oftast helt orealistiskt idag. Det mesta är för komplicerat, oavsett om vi tillverkar något efter ritning eller utvecklar något nytt. Nästan alltid behöver vi andra människor, team eller till och med andra organisationer för att effektivt kunna skapa värde.

När vi är beroende av andra människor eller organisationer uppstår en konsekvens. Vi måste börja förhålla oss till och reagera på andra människor och vad de gör. De har ju samma rätt som vi till ett meningsfullt arbete. Det här stjäl en del av vår tid. Plötsligt kan vi inte lägga all vår tid på värdeskapande arbete. Men vad är alternativet?

Jag tänker att det här är som vanligt i livet; för att få tillgång till något som du vill ha måste du betala något. Då dras mina tankar till företeelsen skatt.

En skatt i vanlig mening är ju en del av din eventuella inkomst som du måste betala för att få vara en del av samhället och åtnjuta dess utbud som respekterad medborgare. Du kanske inte gillar skatten och försöker att minimera den, men du kommer inte ifrån att betala den hur du än slingrar dig. Och skatten används, i bästa fall, för att just skapa de här fördelarna som du innerst inne vill ha och behöver; en skola som fungerar för dina barn, sjukvård när du får ett elakt virus och en brandkår som släcker branden i ditt hus.

In this world nothing can be said to be certain, except death and taxes.[1]

Benjamin Franklin

Vi har en liknande situation här. Vi får någonting värdefullt, till exempel att klara av ett arbete som vi aldrig skulle fixa på egen hand. Men, vi måste också betala något. Och det finns inget sätt att komma undan det. Skatten som vi betalar kan absolut, i vissa fall, vara överdriven och onödig, men även i många fall helt nödvändig för att skapa det som du innerst inne behöver och till och med vill ha.

Låt oss titta på ett exempel för att göra det tydligare vad jag svamlar om.

Teamskatt

Situation: Vi är flera personer som arbetar tillsammans i ett team (lag). Tillsammans har vi kompetens inom de områden som behövs för att utföra teamets uppgift. Som team har vi gemensamma mål och ett ömsesidigt beroende av varandra. När gruppen mognar klarar vi av mer och mer, blir mer oberoende av andra. Vi kan verkligen njuta av vår gemensamma skicklighet.

Vinst: Vi klarar av betydligt mer än ensamma. Vi får åtnjuta glädjen av att lyckas tillsammans, uppmuntran och stödet från lagkompisarna och trösten av att inte vara ensamma när vi misslyckas.

Skatt: Skatten som vi måste betala är tid för aktiviteter för att styra teamets arbete samt för att skapa och bibehålla ett fungerande lag och arbetsklimat.

Exempel: Definiera mål för teamet på olika horisont, planera kommande veckas arbete, regelbunden arbetskoordination, involvera de som vill i en kreativ session, en middag med teamet efter arbetsdagens slut, reda ut en konflikt, förbättringsmöten och experiment för att förbättra hur vi levererar värde.

Skatten är alltså allt det som vi måste göra för att ens ha ett lag och kunna samarbeta till fullo. Det är inget att fnysa åt, tycker jag.


En del av oss förefaller helt omedvetna om de här “skatterna” och verkar leva i illusionen att situationen med totalt oberoende, där vi kan lägga all tid på att bara… “jobba”, på nåt sätt borde vara verkligheten. All tid och alla aktiviteter som ingår i skatten ses som en kränkning av deras personliga frihet.

Saken är dock den att den inte går att undvika. Det tjänar lika lite till att bli arg på skatter som att hytta med näven åt motvinden. Det är vad det är. Vill vi ha fördelarna måste vi betala skatten.

Det finns naturligtvis en poäng i att hålla teamskatten låg, men vi måste vara medvetna om att om vi börjar “skattefiffla” kommer konsekvenserna att bli mångdubbelt värre. I förlängningen kan det leda till att du i praktiken inte har något team.

Det är inte bara för team som den här typen av “skatt” förekommer. Här följer några andra exempel på sådana här “skatter” i organisatoriska sammanhang.

Värdeströmsskatt

Situation: Vårt team ingår i en större värdeström, ett nätverk av flera team eller organisationer som skapar värde från behov till kund. Det som vi skapar tillsammans har ett känt kundvärde.

Vinst: Vi får vara med i ett sammanhang som kan ta något hela vägen, från signal om produktion till något som kan användas för att göra en kund nöjd. Det här är en källa till upplevd mening och stolthet.

Skatt: Skatt för detta som vi måste betala är tid för att styra hela värdeströmmens arbete samt hålla ihop denna.

Exempel: Koordination och synkronisering med andra team och personer i värdeströmmen, anpassning av din egen arbetstakt för att matcha takten i värdeströmmen, bredda din kompetens för att kunna stötta i flera steg i värdeströmmen, förbättringsarbete kring värdeströmmen genom att optimera flödet.
Komplexitetsskatt

Situation: Liknande situation som värdeströmsskatten, med det tillägget att det finns hög osäkerhet kring vad som utgör värde för kunden samt hög grad av förändring. Ett annat ord för detta är komplexitet. Ju högre osäkerhet och förändringstakt, desto högre skatt. Även den mest effektiva värdeström kan vara värdelös om den producerar saker som inte har något värde för kunderna.

Vinst: Samma som för värdeströmsskatt, men med det försvårande momentet att det klaras av under stor osäkerhet och förändring, vilket är en sann bedrift av de som lyckas bra.

Skatt: Skatten kommer i form av tid för aktiviteter för att reducera osäkerheten och hantera förändringstakten. Främsta bland dessa är utforskande av behov samt anammandet av iterativa och experimenterande arbetssätt.

Exempel: Studier av användare och deras behov, utformning och genomförande av produktexperiment, analys av data och tänkande för att skapa insikter, uppdelning av arbete i små delar, förbättringar av hur vi utför detta arbete i syfte att snabba på vårt lärande.
Organisationsskatt

Situation: Vi är många personer i samma organisation; en juridisk konstruktion och metafor med ett syfte att skapa värde för kunder eller medborgare.

Vinst: Att få vara medlem i en organisation och få alla de fördelarna som det medför, exempelvis en fast månadslön, ett fint kontor samt olika interna tjänster som står fritt att bruka.

Skatt: Här ingår allt som du måste göra för att harmonisera, koordinera, skapa enhetlighet och bygga lagkänsla kring större organisatoriska enheter.

Exempel: Onboarding kring organisationskultur med nya medarbetare, statusmöte för det stora GDPR-projektet, kick-off-dag med avdelningen, företagsmöte med information om hur organisationen fungerar i olika dimensioner, skapa enighet kring vår strategi framåt, sommarfest med hela företaget, kontroll på ekonomin, att vi inte överskrider våra tillgångar.

Med dessa exempel hoppas jag att det har blivit mer tydligt för läsaren vad jag menar med skatt i det här sammanhanget. Låt oss nu göra några reflektioner kring vad det betyder.


En del av oss kanske upplever ordet skatt som ett till allt överskuggande del negativt laddat ord. Som kanske framgår här försöker jag bortse från vad jag hörde min far säga när jag var 8 år utan i stället försöka se på skatt från ett mer neutralt perspektiv. Skatt kan ju upplevas som negativt ur den egoistiskes perspektiv (“Vad får jag för pengarna?”), men skapar också helt nödvändiga och i många fall goda samhällsmekanismer. Skatt i sig är ju bara ett verktyg, den är varken ond eller god – den bara är. Frågan är mer hur vi använder resurserna (pengarna, timmarna).

Precis som med samhällsskatt kan det givetvis vara så att skatten kan användas på ett klokt eller mindre klokt, eller till och med galet, sätt. Onödig och hindrande struktur och process, även känt som byråkrati, skulle vi helt enkelt kunna se som oklok användning av organisationsskatten. I USA har organisationsskatten beräknats till 3 triljoner dollar per år[2]. Det går enkelt att hitta liknande exempel för övriga skatter:

  • En oklok användning av teamskatten skulle kunna vara att samlas en timme varje morgon för att prata om alla som pågår.
  • En mindre intelligent användning av värdeströmsskatten kan vara att införa projektledare för att koordinera arbetet i värdeströmmen.
  • En obegåvad användning av komplexitetsskatten vore att ägna månader åt att förstå kundbehov och skriva ner det i en produktspecifikation.

Bra användning av skatt är till sådant som många berörda behöver. För ett team kan det vara att sätta meningsfulla, gemensamma mål, lösa konflikter på ett produktivt sätt eller lära sig att jobba bättre tillsammans. Och många andra saker. Det är helt essentiella uppgifter för att få ihop ett team och bör inte ses som onödiga, “administrativa” uppgifter. Och ju skickligare vi gör dem, desto mindre behövs de.

Nästa gång du utsätts för en sådan här skatt, prova att inte direkt himla med ögonen eller dra nåt skämt om möten för att visa för alla hur idiotiskt du tycker att detta är. Fundera i stället på vad det är för slags skatt. Om det är en nödvändig skatt som ger dig något som du egentligen vill ha, överväg att göra ditt bästa på mötet, för att få riktigt bra effekt av skatten. Om det verkligen är en oklok skatt, överväg vad du skulle kunna göra för att förändra situationen framöver.


[1] Death and Taxes (idiom)
[2] The $3 Trillion Prize for Busting Bureaucracy (and how to claim it)

Don’t adopt – adapt!

Simply copying what someone else is doing may be functional in child development but is a poor way to improve organisations. The problem is that practices don’t translate well between contexts. But it’s easy to be seduced by what you see, the practices, and forget about what you don’t see. We need to look beyond the practices. Improvement must be based on agreed outcomes, principles, and fundamental needs. Practices should be pulled in mindfully and tweaked to fit the local context. Don’t adopt – adapt!

Copying a practice. Photo by Sai De Silva on Unsplash

At one of the major banks in Sweden, they had spent years on a big Lean change programme. This was before my time at the bank. I had heard about it, as in “the management consultants came in and told us how to work”, but saw no sign of it. Until one day, when I found a paper on a desk which mentioned Lean. I got interested and picked it up. After some reading I realised this was about 5S, which I knew a bit about from reading books on Lean Software Development.

5S is a Lean practice. The five ‘S’ in English is for Sort, Set in order, Shine, Standardize and Sustain. It is a system of practices invented and used in Toyota manufacturing to maintain cleanliness and order at the work stations. Every tool and materials in its place is important in a factory. It increases productivity by reducing the time to find a tool and it reduces risk of injury, for example by using the wrong tool. This makes sense.

On the other hand, in an office… What would even 5S mean in an office? I realised that what they meant were things like keeping the desk clean and sorting each document into the correct binder. Really? Did a bank really need a Lean transformation to tell them that? As far as I know, people working in banks are already quite skilled in paperwork. How valuable was it for the bank officers to learn about 5S? I believe they must have thought it pretty useless and maybe even quite a bit insulting.

That’s an example of what happens when we mindlessly translate a practice from one setting to another. A valuable practice in one setting makes less sense in another.


We often overestimate the importance of what we see. In his book Thinking Fast and Slow, Daniel Kahneman called this bias WYSIATI, What You See Is All There Is. It’s hard to see what’s not there. You need to know it should be there to catch it. When we’re talking about ways of working, this bias leads us to put too much focus on roles, processes, and practices.

But practices is just what we do – not how we think about it. A layperson walking by a team having a daily standup may conclude: “Ah, that’s one of these agile team I hear about”. The agile expert will tell you that the observation of a standup contains almost no information at all around the agility of the team. It’s quite possible to have a daily standup in a manner more consistent with a command-and-control style of management and without fulfilling any of its intended purposes. Unless the practice is informed by agile principles, guided by agile values and an agile mindset, it won’t be valuable to the team.

That’s why we get superficial “adoptions” or “implementations” of the latest management fad. Teams start working according to given instructions, not really understanding why. What’s the purpose? After a while it becomes rote. The practices become theater, gestures performed on a stage. In that situations, trust is hurt. Teams become less willing to take ownership and less engaged in improvement. Repeat with the next fad. Perhaps we can now start to see one underlying reason for the fact that only 15 % of the global workforce are actively engaged at work[1].


I think we need to move away from the copying and the adoption. Instead we should discover people’s needs and agree on a shared set of outcomes to centre the work. We may then select guiding principles on which teams and individuals can base their practices. By basing change on principles, the practices used can be adapted to each team and situation. This enables teams to take ownership of how they work, shape suitable ways of working, and stay engaged in improvement.

For example, imagine our organisation values quality. One principle we could have is Stop dependence on mass testing and build quality into the development process (from Deming). To one development team, this could mean an experiment to create a better test coverage in a certain, bug-ridden part of the codebase. To another team, with solid test-driven practices, this could mean experimenting with mob programming. Or it could mean interweaving usability testing in the deploy pipeline, regular code reviews, contract testing or including a test specialist in the startup meeting of every initiative. The possibilities are many, but the goal and the underlying principle are the same.

There are no “best practices” in complex situations. The exact practices you use are not important. Most of the time, it doesn’t matter much, which ones you choose, as long as you follow the principles, live the values, and move towards agreed outcomes. The practices won’t make you agile or lean. You need to look beyond the visible.


[1] Source: 12 Employee Engagement Statistics You Need To Know In 2020


Previous posts in the series on principles of organisational development:

  1. Nothing Ever Lasts but Change
  2. Include the People Involved
  3. Start by Changing Change
  4. Think Big, Start Small
  5. Pulled Change: Sustainable Change That Spreads Organically
  6. Thinking and Doing Together
  7. Managers Are Part of Change

Managers Are Part of Change

Imagine you are a manager in an organisation of non-trivial size. Now, you and your manager friends have decided the organisation needs to improve. Let’s say, for argument’s sake, you want to cut lead times by 50 %.

You’re thinking, this is obviously a goal for the teams and individual contributors in the organisation, right? They are the ones that need to tighten their processes. Cut handovers and remove waiting time. Your part as a manager is basically to get it going by presenting the logical reasons for the change and allocate the resources. The rest is just monitoring progress and intervening if there are problems, right? Right?

A manager on the road ahead. Photo by Tim Marshall on Unsplash

It’s easy to fall into that trap. But it’s just not an effective way to improve, at least if we’re talking organisational development. To make change work, managers cannot be exempt from it. Managers are part of the organisation too. If the organisation changes, they need to change.

Managers need to sponsor and support the change, of course. But if managers are serious about change, they need to take a more active role in it and – the horror – change themselves.

The rewards of managers immersing themselves in change are plentiful. Not only will this change have a fighting chance, but in the process, managers will gain a deeper understanding of the nature of the work. They will develop a natural credibility in the organisation. They will now be listened to, not because “they are the boss”, but because they actually know what they’re talking about.

If not a large majority of the managers in the organisation are onboard with the change and work towards it, no change stands a chance.


I should have known better. The startup meeting at the bus travel company was pleasant enough. My friend, the head of the design team, who had recommended me for the job, was there and the development manager seemed nice. She laid out the challenge for us.

Their agile journey had started with a group of co-workers and consultants going rogue and starting an agile initiative. “Grass roots movement – check!” I thought. It did not have that much of an effect, since they were so few, but a seed had been planted. After a few years they were ready for the big transformation. They started with a whole-company conference day dedicated to agile ways of working with an agile coach as inspiration. This got the attention of the organisation but not much more. Some things changed but then the change fizzled out again.

Now, a year later, the development manager wanted me and my friend to get them going again. We would have full freedom and she would get out of our way. If we needed anything, we could come to her. Sounds sweet! So why did I have a feeling in my gut that something was not right?


Before we hear the end of the story, let’s look at things a manager can do in change. The way I see it, managers have at least five major responsibilities in a change:

  1. If needed, create or revitalize the systems for continuous improvement,
  2. Contribute to the overall direction of change,
  3. Go first – lead,
  4. Guide and support teams through the change, and
  5. Remove or reshape organisational systems that prevent change.

Any sustainable change is made by responsible people who own the change. This means, the organisation needs to have a system in place for how to improve continuously. To be effective it also needs to be systematic, inclusive, and experimental. To create and enable such a system is a big undertaking but when it’s in place it will turn your organisation into a learning organisation, which creates the conditions for making your organisation successful for decades. Toyota is the prime example of this. This is a leadership issue, if there ever was one.

In change, people need to be drawn towards something, an ideal. A North Star (or similar). A North Star is not a goal. It just sets the direction. Many people can and should contribute to the definition of a North Star, of course, but as a manager or executive you’re accountable for the quality and clarity of the direction. And iteratively adapting and improving it, of course.

Managers should go first, lead the change themselves. Be the change they want to see, as the saying goes. The opposite would be very incongruent; telling people to do something but not do it yourself. It’s true the work of managers if often different from the value creating work, but often the underlying principles can be carried over.

Teams will need coaching and support through the change. Managers need to be more present. By being present with the teams, managers gain a better understanding of what is going on. Suddenly, they can make observations and ask questions to the teams without them rolling their eyes when you’re not looking. Managers can reinforce behaviours that they’d like to see. For example, if you’d like to see more experimentation, you can ask questions about the ongoing experiment; what the team is going for, what they are trying, and what the obstacle is. This attention alone tells the team that improvement by experimentation is important.

Finally, managers are the stewards of the organisation systems; processes and structures. Sure, individual contributors may influence change but to improve, simplify or even remove an organisational system takes management decisions. As managers coach their teams, they will gradually become more aware of where the real obstacles lie. They can help the teams create value by removing or streamlining things that are in the way.

One observation I would like to offer is that the way most managers seem to think about change today (plan-driven) and their role in it (sponsor, advocate), makes success with change look like a question of effort. A failure can only have two causes, either the plan was flawed or the execution was flawed. When we fail, clearly, the people in the organisation are to blame. Who else? This is a convenient position, of course, but their lack of leadership is staggering. Do you think leadership is showing slides and giving speeches? If you are guilty of this, you aren’t a leader at all. You are an actor.


So, what happened? After a few months I started to see where my initial gut feeling came from. The development manager certainly gave us freedom. A lot of freedom. In fact, the manager was hardly to be seen. Apparently, she did not see any role for herself in the change work, fully delegating it to us. Predictably, when people opposed the change, she took a neutral position, not backing the change 100 %. It’s quite natural for people to feel confused or frustrated in change, but when the leaders hesitate, people get doubtful. It makes it very hard to achieve any change at all.

I slowly understood why the agile transformation had subsided the last time and why it would do the same this time. The managers and the executives were not behind it. The really hard, necessary decisions, like changing an important process, the managers would not make. Could not make. They had little knowledge of what was going on and they weren’t particularly engaged in the matter. They couldn’t help us. The distance between managers and operations was too big.

Cross-functional development teams, a team coach for each team, a product organisation and a pull model of upcoming work, but that’s as far as we got. The managers refused to get involved. When the wave of change lost its energy, it was our fault.


Previous posts in the series on principles of organisational development:

  1. Nothing Ever Lasts but Change
  2. Include the People Involved
  3. Start by Changing Change
  4. Think Big, Start Small
  5. Pulled Change: Sustainable Change That Spreads Organically
  6. Thinking and Doing Together

Thinking and Doing Together

For effective organizational change, consider working with both the mindset (the thinking) and the behaviour (the doing). Let people try new ways of working through mindful practice, but also let it be informed by theory. Learn by doing, but also invite people to consider other beliefs of what good looks like. What we do and how we think and feel are deeply connected.

Thinking & Doing

Thinking First, or Doing First?

It is logical to think that we will start behaving differently as soon as we start thinking differently. This seems right because we (falsely) believe that our decisions are rational and our conscience is in control of our bodies1. In practice, however, this approach leads to problems. It is just very hard to make people change their way of thinking without them actually doing something. How many times have you changed your mind just by being told how to think?

I hear and I forget. I see and I remember. I do and I understand. – Attributed to Confucius

We now understand that the way we behave can have a strong effect on how we think and feel. Research shows that we feel better just by physically raising the corners of the mouth by putting a pencil between our teeth2. This is also how Toyota approaches change. Not through pencils but their outlook on change. They teach people a new behaviour. Based on the results and reflection through active coaching, the mindset follows. People behave themselves into a new kind of thinking.

Good think. Now go do something! (photo by Juan Rumimpunu on Unsplash)

There is a lot of wisdom in learning by doing, but it does not explain why so many Agile adoptions are full of meaningless rituals and fake agility. Should not teaching teams how to follow the Scrum meeting practices change the way they think about their work and their collaboration? In my experience, this is not the case. I have seen many mechanical process implementations with little understanding of the purpose behind the mechanics and the negative effects are considerable. Is learning by doing really enough?

A Tale of Two Teams

Let’s visit two imaginary teams at work.

Team 1: Imagine a scene at the office. It’s time for the Daily Scrum for the development team. Slowly, they saunter into the meeting room and take their seats around the big table. The manager opens her laptop and starts the meeting. From the Jira board we can see the team has a lot on their plate. There are lots of what they call “tickets” on the board and many have been worked on for weeks. Everyone on the team is responsible for their own tickets. The meeting proceeds with the manager asking each one what they’ve done since yesterday morning. Everyone answers with the number of their Jira ticket, for example IH-5316, and that it proceeds according to plan. Manager asks what they will be doing today. Answer: Keep going on their tickets. Finally, the manager asks for impediments. The team sees no obstacles. The meeting ends in under 10 minutes. Everybody leaves the room quickly, happy that it’s over. One of the developers turns and whisper to a colleague: “Agile sucks”.

Team 2: Imagine a scene at another office. The team gathers quickly for their Daily Kickstart. This week, the DevOps engineer Louise will be facilitating the team meetings. Some current stakeholders join and gather up close to listen. The team reviews their team whiteboard, containing a lot of information. We see a few product changes and one improvement, all formulated as experiments, in progress. Louise starts by asking everyone for energy level today, as a number 1-5. One of the team members volunteer a low number due to a stressful morning and gets support from people standing next to him. Louise lets people talk but is sure to maintain the flow of the meeting. Divergent threads are asked to pause until after the meeting. They start talking about an experiment they released last week. It doesn’t really generate the outcomes they’d hoped for and needs a tweak. They talk about several other experiments with a focus on flow and obstacles to it. Everyone gets to talk and everyone is heard. At the end of the meeting, today’s priorities are clear to everyone. Martin, one of the frontend specialists makes a pun that makes most team members cringe but also smile. The meeting is over in 10 minutes.

These examples may be a bit exaggerated but only slightly. I have certainly seen all of these behaviours in different contexts.

It seems obvious to me that the second situation is preferable. The second team shows much more joy and engagement. I strongly believe that this team will also create better outcomes and more value for the customers. But both teams followed the Scrum recommendations. In fact the first team followed standard Scrum very well. Yet, the experience, and probably the results, of the first team was much worse. What is causing this difference?

I believe these differences can be traced back to the knowledge of the team members, their attitude to their work, and the team working climate they have created. The second team understood the purpose of the Daily Scrum practice and could harness its power and related practices wisely. They had assumed ownership of their ways of working and shaped them in a way that suited them. They also nurtured their relationships and created a safe and joyful working climate. An agile mindset combined with extensive feeling of ownership.

When Doing Doesn’t Influence Thinking

My point here is that the first team will not turn into the second team by simply continuing with the Daily Standup. Instead, what you are likely to get is just more resentment. In this case, thinking does not seem to follow behaviour. Some time ago, the team started a new practice but it has not turned the team members into agile thinkers – or even just a collaborating team. Why is that?

There could be several reasons for this. For example, it could be because the results are not impressive enough to lead people to consider changing their way of thinking or that the practices in themselves are not strong enough to influence their thinking. But I think the main reason is this: The way the team approaches the new practice is misguided, not based on Lean and Agile principles. They will never find it valuable and enjoyable the way they perform it so why should they consider it to be a good thing to frequently come together and coordinate the work together?

Many agile practices are social practices, which are sensitive to both individual and group mindset. The practice of a Daily Standup can only be valuable if it is informed by theory and an agile mindset. You need a bit of agile understanding to perform the practice in a productive and valuable manner. And in complex domains, practices need to emerge. Finding good ways of working requires endless experimentation and tweaking. You need to modify it to suit your context, which requires safety and a feeling of ownership.

In these situations, we need an upgraded approach. I believe we need to do both. By all means, practice new behaviours. Do it in a safe space with lots of feedback from peers and coaches. But also teach and invite people to consider new ways of thinking. Let that theory inform and guide the practical exercises. In complex domains, learning and doing are two sides of the same coin.


1This is only half true. Many, if not most, bodily functions are done subconsciously or only inform the conscious mind after the fact.
2See Try Some Smile Therapy, Psychology Today


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
  4. Think Big, Start Small
  5. Pulled Change: Sustainable Change That Spreads Organically

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