Conflict as a resource

Caveat Before we get into it, just a bit about my background. I am not an expert on leadership and conflict resolution and I don’t wish to be perceived as one. I am a simple software engineer turned agile coach. So why write on conflict? Well, for over almost 30 years of work, I have seen my fair share of conflict and how leaders handle them (or not handle them) and it still bugs me how conflicts are perceived. Personally, I find conflicts uncomfortable, but I know we can do better. We must do better. You should also know that I don’t take credit for any of this material. I learned this from others, especially from communities around self-management, from training in Nonviolent Communication, and from Tuff Leadership Training.

Conflict. Perhaps just reading the word makes you ill at ease? Did you just start to think about that insufferable person at work? If there is one thing you agree on with that… that… individual, it is that you should stay the hell away from each other.

Conflict in progress? (photo by charlesdeluvio on Unsplash)

When you are thinking about an ongoing conflict, what are you feeling? You probably feel frustration. If you were to dig a bit deeper within yourself, you would probably find a bunch of other feelings around the conflict. Perhaps sadness or guilt. Probably, you would find shame. Few things at work can elicit more shame than conflict. We know we should be rational about this, but we just… can’t. And leaders reciprocate by treating the conflict with the utmost secrecy. No, no, we can’t talk about conflicts because it involves individuals. Like it’s some kind of disease.

The conventional view of conflict in organisations

There is a conventional view of conflicts that leads to these thoughts and behaviours. I want to make it clear from the start that I don’t subscribe to this view. In fact, I think it is damaging to organisations, but let’s examine it anyway. This conventional view goes something like this:

  • Conflicts are irrational. Conflict arise from individual feelings and needs, not from organisational needs. In business, we should always strive to remain rational. Feelings may cloud our judgement. Therefore, having conflicts is a sign of trouble. Where there is conflict, for example in a management team, other leaders or team members may believe the group is currently off balance or even dysfunctional.
  • Conflicts should be avoided. Building on the previous point, since conflicts may affect our thinking and behaviours, they should be avoided. Conflicts are distractions from the real work that decrease our productivity and create concern.
  • Conflicts are shameful. Given the previous points, the general thinking is that conflicts are only relevant to the conflicting parties and should not be spoken openly about. It’s confidential. Side note: Through first-hand observation and gossip, people around the conflict always seem to know about ongoing conflicts.
  • Conflict is a people problem. Again, since conflict is an individual issue, the blame falls squarely on the people in the conflict. Rarely do we reflect on how the system around them contributes to conflicts.
  • Conflicts should be managed by skilled people. Conflict is often such a sensitive issue we need to bring in a mediator, typically the manager of the conflicting parties or HR/People team.

Examining the conventional view

Although conflict may feel exhausting and emotional when inside one, I would argue against this view.

First of all, organisations are filled with people. I hope I won’t shock you now, but people have feelings and needs that influence our behaviours. Feelings and needs are important. So why do we feel a need to hide large parts of ourselves just because we are at work? It doesn’t make sense. Some people call it “The tyranny of rationality”. In this hyper-rational view of the world, we need to create and maintain distorted images of ourselves to our colleagues and leaders, spending a lot of energy.

Secondly, when people try to collaborate, there is always tension. Tension, conflict, and resolution is part of every model of group dynamics that I have seen. In fact, there is general agreement that you cannot create a deep collaboration (or teamwork) without conflict. That means that signs of conflict can actually be a positive sign for a group, under some conditions.

Thirdly, using a systemic thinking lens, most conflict are quite rational. For example, people having conflicting goals. People may simply have been pitted against each other in a zero-sum game. “If I don’t get that money, you will.”. The system we are in greatly affects our behaviour.

Finally, we seem to have forgotten that people at work are responsible grown ups. On every other area of life, responsible grown ups are expected to solve conflicts. Why not at work?

The progressive view of conflict

As you probably know, Alice and Bob had a conflict yesterday on how to manage security tokens. Just to keep you updated, they are working it out as we speak and will report back to us when that is done.

–– A team leader

More progressive organisations have a different view of conflict:

  • Conflicts are natural. Conflict may come from feelings and needs, but is one aspect of human interactions. Conflicts are part of our human condition. By embracing conflict, we can allow a richer picture of ourself emerge at work, outside of our rational self.
  • Conflicts are not only expected but essential. In our interactions with other people, we sometimes go through phases where disagreement and conflict occur more frequently. Without constructive conflict, we can never evolve into a team, with shared goals and mutual dependency.
  • Conflict is a resource for learning. We can use conflict to create better teams and better collaboration. We can clarify expectations of each other. What if we learned how to identify tensions early and use them instead?
  • Communication on the progress of a conflict is useful. Most everyone already knows about the ongoing conflict. Trying to keep it a secret is impossible. It will only lead to misunderstanding and exaggerations. Instead of all that tip-toeing, what if your team manager said something like this instead: “As you probably know, Alice and Bob had a conflict yesterday on how to manage security tokens. Just to keep you updated, they are working it out as we speak and will report back to us when that is done.”? Suddenly, that knot in my stomach dissolved. I have even resolved conflicts with people with the whole team present, listening and mediating.
  • Fundamentally, all conflicts at work can be resolved (some may take time). Some conflicts are certainly personal and hard to resolve, but we can choose to view all conflicts as possible to resolve in a constructive way. We need to believe this ourselves.
  • We can expect grown-ups to resolve most of their conflicts on their own without the help of outside mediation. We’ve known how to do it since kindergarten. It may feel hard sometimes because we do it so rarely. With some training, it becomes easier.

There is one thing that both perspectives agree on: What we must never do is allow for a conflict to remain without resolution. The conflict will grow and fester. It can turn into an all-out war, but more likely it will remain but never spoken about. It will become a problem, not only to the people involved, but to everyone else that works with them. People will need to work around this and use their mental abilities to navigate this minefield instead of being able to focus 100 % on work.

Your turn

What conflicts do you have? Big or small, I suggest bringing them up with the people involved and listen to each other. Start with the small ones, so small they almost don’t feel worth bringing up. They are good for practicing. Here is one way you can bring it up:

Charlie, I noticed we disagreed yesterday on the need for more diversity in the management team. After that meeting, I feel sadness and a bit of frustration. It is important to me that we are an inclusive and equitable employer. Would you be willing to talk about this with me over a coffee at 10?

Here are some questions that can be helpful in the conversation itself:

  1. Facts and observations: Do you both agree on the facts? What would you have seen and heard if it was caught by a hidden camera?
  2. Perspectives and feelings about it: If you listen closely, can you understand the perspective of the other person? How did they feel in this? How does it make you feel, hearing this now? Take turns.
  3. Needs: What do you need from the other person to put it to rest?
  4. Wishes for the future: How would you both like things to work going forward?
  5. Organisational learning: Can you now see why the conflict emerged? What forces contributed? As an organisation, what can we learn from this?

Don’t delay. Start treating your conflicts as resources.

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

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:

  1. Show up at the place of work
  2. Interact with the teams, listen and ask open questions
  3. 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:

  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
  8. Don’t adopt – adapt
  9. Spread knowledge organically

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

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:

  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
  8. Don’t adopt – adapt

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:

  1. WHAT are we working on?
  2. HOW are we doing that?
  3. 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.


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.


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.

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.

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)