Coaching Improvement with WYAFIWYG

In human behaviour, consequences are more important than instructions. To facilitate change, leaders must regularly be present where the work takes place. They coach people and teams on improvement efforts, which at the same time teaches people the method by which improvement is achieved. The coaching should focus on thinking and behaviours, not results.

*Remember your ABCs.* Photo by Pixabay pu00e5 Pexels.com

A well-known, progressive CIO once told me in an agitated discussion about goals: “Apart from setting goals and clarifying constraints, there are no other means by which leaders can influence work”.

I think I understand his reasoning, but I disagree. In fact, I think he got it backwards. Setting goals is certainly not all you can do. In fact, goal setting is not even that important.

Before you stop reading, let me explain: It is common among modern leaders to “manage by objectives”. This is a debatable practice, but it comes from a good intention: As leaders we should avoid interfering in operational details and allow people and teams to organize the work themselves.

But what they forget is how humans work.

Organisational Behaviour Management (OBM) is a field studying human behaviour in the workplace. OBM has murky roots in behaviorism, but also some interesting findings. One of them is the ABC rule. ABC stands for Antecedent-Behaviour-Consequence.

Antecedent: What comes before, for example training, instructions, orders
Behaviour: What we do as a result (not what we avoid doing)
Consequence: What comes after, good or bad, for example attention, recognition, frustration, removal of gratuitous fruit.

The ABC rule states that to most people, the consequences are more important than antecedent. In other words: What happens afterwards is more important than what sets it off. For example, if a manager presses on her team to improve quality (that’s the antecedent), but no action is taken, the manager never speaks about it again, and quality problems are still ignored (no consequence), we should not be surprised that, after a while, nobody cares about quality improvement. Makes sense, right?

The ABC Rule (in simple terms): What happens afterwards is more important than what sets it off.

Applying the ABC rule to goals tells us that it’s more important to follow up on the progress on goals than it is to define them. This is often surprising to leaders. Leadership teams tend to make a big fuss about next year’s goals or next quarterly objectives, seduced by the alluring feeling of control. However, taking an interest in the work, ensuring teams make goals their own, learning how they approach the work, what they are trying and what’s standing in the way, is not as popular. Managers tend to wonder why there is so little progress on the goals. Armed with the knowledge of the ABC rule, we know why.

Taking us back to the CIO in the beginning, that’s where he got it backwards. It is more important to be present and take an interest in how things are going than to set objectives.

This series is about organisational change, where the ABC rule applies as well, of course. That means, setting up a vision and mission, perhaps even a North Star and getting teams trained in PDCA is all well and good, but it’s what happens next that matters.

To me, there are three things that are important here:

Show up at the place of work
Interact with the teams, listen and ask open questions
Focus coaching on thinking on behaviours, not results

“Success is 50 % just showing up”, is a common saying. The best leaders are present where the work happens (in Lean often called the gemba). Not to control, but to observe, interact, teach, and understand how people think and how the work works. Just being present now and then, listening and observing will take you far.

Even better, talk to teams. Ask open, curious questions and listen actively. Not just their words, but their tone of voice, body language, etc. What does that tell you? What’s their current way of thinking? Can you help them in some way? Look at you, now you’re coaching teams!

Finally, remember that weird abbreviation in the title: WYAFIWYG? It means: What You Ask For Is What You Get. This guideline informs us that a leader’s questions will tell people what is important to them (and probably the organisation). If leaders and people are aligned, people will then try to bring more of that. Why? Because of the ABC rule. Leadership attention and genuine curiosity are the reinforcing consequences. (Note: It has to be genuine. Don’t fake it.)

WYAFIWYG: What You Ask For Is What You Get

So you have to ask the right questions. If you mostly ask about deliveries and say: “When will it be done?”, people will take away that project management and deliveries are of paramount importance here. Experimentation, learning, improvement, health, safety, collaboration, feedback, etcetera – not so much. This is a clear symptom of a manager with a command-and-control mindset.

Instead, I suggest asking, not for results, but for the behaviours that you believe will lead to great results. If you want improvement on quality, for example, inquire what the team is trying to do about it. Ask questions that reveal that you assume people are working on it using your agreed improvement method. Here are some powerful questions around improvement you can ask[1]:

What are you trying to achieve?
What experiments have you tried so far and what happened?
What obstacles do you see and which one are you addressing now?
What will you try next?
When do you think we’ll be able see the result from your next experiment?

Faced with these kinds of questions, a team will understand that experimenting to learn and improve is really important here. This will intensify their efforts. It will also, gradually, teach them the scientific method of continuous improvement. And suddenly, you’re on your way to a learning organisation. That’s the power of WYAFIWYG.

[1] These questions are derived from the Coaching Kata of Toyota Kata, by Mike Rother. Watch this video for a 5-minute introduction to Toyota Kata and the role of the coach.

Previous posts in the series on organisational change:

Spread Knowledge Organically

Diffusion of knowledge is a difficult problem. People who need to know something are often unaware that they do. And even when they do, they may have no idea that this knowledge already exist in another part of the organisation. Spreading knowledge and learning quickly has become a business advantage. In the age of digital disruption, every organisation needs to be a learning organisation. To facilitate the dissemination of knowledge, organisations need to enable people to pull it in, organically.

*Social learning in progress.* Photo by cottonbro pu00e5 Pexels.com

A few years back I coached a few teams at a digital product company in Stockholm (I will withhold its name). They had a lot going for it and an attractive brand among engineers. This allowed them to handpick good developers. I don’t think I have ever met so many intellectually brilliant people in one place. It was humbling.

Another cool think was the freedom that teams enjoyed and the expectation of them to experiment and innovate. The frequent hack days were not a free-for-all, but an opportunity to “flex your innovation muscle”, as they put it. Everything’s great, then? Well, no. I also saw problems.

What bothered me was that the cool stuff and learnings that teams made did not seem to spread to other teams. People and teams did a lot of interesting stuff but it didn’t improve the whole, from what I could tell. Knowing that this is an important part of Lean/TPS, I was curious, why?

After a while I realised that part of the reason was the rampant Imposter syndrome. In this organisation, it was always easy to find someone who you believe to be more knowledgeable in any given topic. I saw virtually no lunch-and-learns during my time there. But there was also another reason.

There was little organisational support for spreading knowledge, learnings, or just good practices to the rest of the organisation. No standards, no lunch-and-learns, no documentation, and no research database. When I asked a senior manager about this he told me “this is by design, good ideas spread by themselves”. Really? I was doubtful. The words sound good, but how fantastic must an idea be to spread in an organisation with loads of product teams in multiple countries on different continents without any kind of support?

I came away with the impression that, although this organisation was vanguard in many respects, this dimension, what we might call knowledge diffusion, simply did not work well. I believe other coaches perceived this too, at least unconsciously. Lacking the right support structure, many coaches took to creating cute but simplified infographics with “recipes” for teams how to perform agile practices, e.g. run a retrospective. Since I always look to create systemic change in my work and I found this to be alien to how I wanted to work, I decided to leave my assignment after just one year.

In the age of digital disruption, every organisation needs to be a learning organisation.

To me, the concept of a learning organisation not only speaks to the growth of individuals (also important), but to the organisational learning; the way we continuously experiment, improve, encode, and disseminate knowledge, be it results from experiments, insights or whatever. A working continuous improvement “engine” does not only improve the process (or whatever) under improvement; it also improves the customer experience and, importantly, makes room for more radical innovation. Without continuous learning and improvement, we will always be busy with operational issues and firefighting.

Furthermore, learnings and empirical knowledge from experiments must be encoded somehow and disseminated through the organisation. Everyone does not need to work the same way, of course, but they need to know where to find information about new learnings so that they can be inspired to try them out (a learning pull system, if you will).

Let’s look at another example: Buurtzorg. Buurtzorg is a home-care organisation that started in the Netherlands. It is famed for creating a successful healthcare organisation mostly consisting of self-managed nursing teams and now employs over 10 000 employees in 850 teams [1].

A team at Buurtzorg manages their own operation, from budgeting, care planning, home nursing, and improvement. Whenever a team tries something new, they are encouraged to publish their findings on the Buurtzorg intranet. That way, other nursing teams can read about it. If they want to pull it into their team, they often contact the original team to learn from them directly. That way they can take full advantage of the idea.

Using simple organisational structure, self-managing teams and a company intranet that is actually used by people, knowledge about promising ideas and learnings about bad ones can spread rapidly even in a large organisation. That’s one way how a large organisation can support knowledge diffusion. But let’s look at another mechanism too.

Knowledge is not data. You can’t transmit it from one brain to another.

Using the old, top-down, command-and-control way of thinking, organisations have come up with all kinds of ways how to spread knowledge in their organisations. Improvement program, Training Lab, Centre of Excellence, just to name a few. The problem with most of these to me is that they treat knowledge like data; based on the fundamental premise that knowledge just needs to be transmitted from one brain to another. But that’s not how learning works, right? Learning is pull. Learning can only happen if the learner has the means and the motivation to learn.

Instead of thinking of learning as experts transmitting data to students, why not think of learning as a social mechanism where capable, motivated people learn together with other capable people? When professionals come together, everyone knows something, but no one knows everything. Apparently, people learning together is called social learning.

Social learning forms the foundation for Communities of Practice, or simply CoP. In short, CoP are “groups of people informally bound together by shared expertise and passion for a joint enterprise”[2]. CoP is an excellent way to allow knowledge and new learnings to spread in your organisation. Okay, so you just gather people into different learning communities then? No, it’s not that easy.

Obviously, CoP don’t appear by the wave of the CEO’s magic wand. It takes time, reasoning, encouragement, and supporting structures to make them work. Or, using the language from Switch[3], to Direct the Rider, Motivate the Elephant, and Shape the Path. You need to explain the reasoning for trying out a CoP. You need to spark the flame for excellence in people’s hearts. And you need to provide a simple way to do it. But don’t get discouraged. A simple wiki home page for all learning networks with clear instructions on how to get going is a good start.

If you need to go to your manager to get permission to learn, forget about innovation.

I sometimes hear leaders lament the lack of innovation in their organisations. But how can you innovate when you don’t even know how to improve? If you need to go to your manager to get permission to learn, forget about innovation. Managers are responsible for creating the conditions for learning and improvement. If you want to create a learning organisation, you need to remove or minimize every possible obstacle to learning.

To conclude, forcing a certain way-of-working on people is not cool. Good ideas, learnings, knowledge, and practices can be allowed to spread organically, as more and more teams want to participate in a change. But it won’t happen on its own. Leaders need to create the organisational support for it.

[1] Buurtzorg home page

[2] Communities of Practice: The Organizational Frontier by Etienne C. Wenger and William M. Snyder, Harvard Business Review Magazine (Jan-Feb 2000)

[3] Switch: How to Change Things When Change Is Hard, by Chip and Dan Heath

Previous posts in the series on principles of organisational development:

Why you should avoid saying the Product Owner is responsible for the What

Why is this a problem?

Many Product Managers/Owners are told they are “responsible for the What and the team responsible for the How”. The intention here is that PM/POs should focus on what the team should deliver, not how it delivers it. On the surface, this makes sense, but I believe dragons are hiding underneath.

The first issue I have with this saying is a very real one. When you say that someone is responsible for the What, it’s often interpreted to mean that someone should deliver descriptions of features (for example in the shape of stories) to develop to the team. This is a handover, far from ideal, and quite a bit similar to the old serial model of development. It removes the team from the creative work of coming up with good solutions to user needs and it puts the responsibility strictly on one person to shape the product functionally. We discovered this misunderstanding in the early years of agile software development and documented many times, for example in [1] and [2]. This saying reinforces the misunderstanding.

The other big issue I have with saying the PM/PO is responsible for the What and the team is responsible for the How is that it completely ignores the most important aspect in product development: The Why. The Why is the reason for doing this work in the first place, the value it could create in relation to the estimated effort to product the intended outcome, for example the way it would improve things for the users/customers and the value the organisation could receive from it. This factor is of paramount importance to product developers, simply because of the high degree of uncertainty: Most features will have little to no value to customers and a few key features will have surprisingly high value. The more innovative the idea, the stronger this effect will be. This is the key reason why movements like Design Thinking and Product Discovery were created; to help us manage the value risk under great uncertainty.

Three important questions

Instead, let’s dive a bit deeper and look at the work from different angles. There are three important questions to any work:

WHAT are we working on?
HOW are we doing that?
WHY does it matter?

Let’s discuss them in reverse order. The third question is clearly of great interest to any PM/PO. It makes sense to interpret “the Why” as the reason for doing this work. By that I mean the needs or problems the users are having and the value a solution could create for them and our organisation. If your mission is to guide a product team towards maximum value, then a deep understanding of user needs and the actual problem is crucial. For this reason, it makes a lot of sense for the PM/PO to lead the effort of creating a validated Why.

The second dimension I would interpret as the design and implementation of the solution to the problem. Not only the details but also conceptual design. It makes sense to leave this to the makers on the team, for example the UI designers and software developers, since that is their core skill (and to be frank, too technical a topic for most PM/POs).

Finally, the What. This is where is often gets confused. The reason for this is that it’s not clear what “What” refers to in software. Is the question: What user need are we going to aim to fulfill? Or is it: What will we develop to fulfill this need for our users?

It’s easy to fall into the 2nd one, thinking of the What as the “requirements” on the software, describing the capabilities and features to be developed. After all, that’s what is to be developed. I believe this is a mistake, at least in software. To me, the features of any product should largely be a matter of discovery and less about specification. The understanding of which features to develop falls in the realm of the solution, in other words, the How. By thinking this way, the What remains clearly in the problem space.

A better way?

To me, it makes sense for a skilled PM/PO to have decision rights on our current goal, for example what problem to solve. A skilled PM/PO has a good understanding of the business and knows enough of the product strategy, users, data, the competitive landscape, and the industry as a whole to make that call. The product team designs (or discovers) what features to develop in order to move towards the goal. That doesn’t mean it should be authoritarian. In practice, it works the best when it’s a team effort.

Below I have tried to illustrate my thinking; how it’s a scale of different abstraction levels, how the team can work as one even though one role is typically driving, and some associated types of activities.

Abstraction levels in product development

To summarize, the PM/PO and the rest of the team are inverses to each other. The PM/PO leads the team around researching the value, decides on what need to address, guides the team in finding a good enough solution, and is involved in the development. The product team, on the other hand, is involved in goal setting and user research, co-creates the solution, and takes responsibility for its design and implementation.

What do you think about this? I’d love to hear your thoughts in the comments. Take care!

[1] A great article on this anti-pattern is ConversationalStories, by Martin Fowler (2010)
[2] My own contribution: Magical User Stories (2009)

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:

The Blogging Terrier | Den bloggande terriern

Energetic, swift-footed, kind-hearted and extremely loyal to those we like