Trivorto spreekt op Business Agility event van Ice Utility

/in /door

7 November organiseerde Ice Utility Professionals voor haar relaties in de utility branche een event over Business Agility. Op een bijzondere locatie, namelijk het Rijksmuseum, werden de gasten niet alleen getrakteerd op een uitstekend diner verzorgd door topchef Joris Bijdendijk, maar ook op een inspirerend verhaal uit de praktijk van Eneco. Sprekers waren Willemijn Jansen, manager Customer Care, en onze eigen Dave Boere. Zij namen de aanwezigen mee op de reis die Eneco heeft doorgemaakt, maar nodigden ze ook uit mee te denken over de uitdagingen van een agile implementatie bij een service organisatie.

When your only tool is a hammer

Als je enige gereedschap een hamer is…

/in , , , , /door

De omgeving van organisaties verandert met een toenemende snelheid. Complexiteit en onzekerheid vieren hoogtij. Maar de toolset die management gebruikt voor het managen en vormgeven van hun organisaties verandert maar heel langzaam. Er is een toenemend gat tussen de toepasbaarheid van de gebruikte tools en de probleem domeinen van moderne organisaties. Hoe kunnen we vaststellen in welk domein we zitten en of we passende tools gebruiken?

Er is geen ontkennen aan dat organisaties opereren in een wereld van onzekerheid en continue verandering. Windows of opportunity openen en sluiten steeds sneller. Een concurrentievoordeel voor langere tijd vasthouden is tegenwoordig behoorlijk lastig. Het lijkt ook duidelijk dat de meeste organisaties slecht toegerust zijn om te gaan met snelle veranderingen. Een indicatie daartoe is de gemiddelde levensverwachting van organisaties. Die lijkt in een alarmerend tempo af te nemen. Professor Richard Foster of Yale University leidde een Innosight onderzoek dat aantoont dat een 61 jarige levensverwachting voor het gemiddelde bedrijf in de S&P 500 index in 1958 afnam tot 25 jaar in 1980, tot slechts 18 jaar nu. Sterker nog, in dit tempo zal in 2027 meer dan 75% van de S&P 500 uit bedrijven bestaan waar je nu nog nooit van hebt gehoord. Dat klinkt best alarmerend toch?

Er is duidelijk werk aan de winkel voor organisaties. Zelfgenoegzaamheid is je grootste vijand in deze wereld, en is een één-richting straat naar irrelevantie. Het bedrijvenkerkhof ligt vol met bedrijven die of te laat of helemaal niet op verandering gereageerd hebben. We pretenderen niet het wondermiddel in handen te hebben dat elke organisatie omtovert tot een veerkrachtige adaptieve organisatie die alles aankan. Maar de eerste stap is om te beoordelen in welk probleemdomein we zitten en of de tools die we nu gebruiken daar eigenlijk wel geschikt voor zijn. Helaas blijven veel organisaties hardnekkig vasthouden aan de tools die ze kennen zoals hiërarchie, centralisatie, focus op efficiency, regels en procedures, lineaire planning, etc. Er is op zich niks mis met deze tools, maar ze zijn ontworpen voor organisaties die 100 jaar geleden bestonden. Veel managent tools zijn min of meer nog steeds de erfenis van Frederick Taylor’s Scientific Management en Henri Fayol’s functies en principes van management. De wereld is echter behoorlijk veranderd sindsdien. In Westerse economieën zijn er niet veel branches meer waar deze tools nog goed werken.

Elke organisatie, afdeling, team, of proces bevind zich in een specifiek probleemdomein, elk met zijn eigen passende aanpak en tools. Dus hoe kunnen we vaststellen in welk domein we ons bevinden? Een nuttige tool hierbij is het Cynefin framework. Cynefin onderscheid vier hoofddomeinen, en een vijfde die disorder heet, die elk context beschrijven in termen van de relatie tussen oorzaak en gevolg. De vier hoofddomeinen heetten obvious (I geef nog steeds de voorkeur aan de oude term ‘simple’), complicated, complex, and chaotic. Het disorder domein is bedoeld voor als je niet kunt vaststellen in welk domein je bent.

Voor een gedetailleerde beschrijving van het Cynefin framework verwijs ik naar het uitstekende Harvard Business Review artikel van de bedenker van het framework, Dave Snowden. Voor dit artikel houden we de uitleg kort: In het Obvious domein kunnen we het probleem eenvoudig categoriseren en dan de juiste checklist of procesbeschrijving erbij pakken. Omdat de omgeving in dit domein redelijk stabiel en voorspelbaar is, kunnen we ons richten op het optimaliseren van best practice processen. Een eenvoudig lening aanvraagproces is een goed voorbeeld hiervan.

In het Complicated domein is het allemaal niet zo simpel en voorspelbaar. We hebben experts nodig die de situatie analyseren voor we kunnen reageren. Dit is het domein van de experts en kenniswerkers. Meestal is er nog steeds een significant verband tussen oorzaak en gevolg, maar oorzaak en gevolg kunnen in plaats en tijd van elkaar gescheiden zijn, wat het lastig maakt het verband te zien. Dit wordt versterkt door typische management structuren zoals silo’s en KPI’s. We nemen een beslissing in één silo, laten we zeggen de afdeling Verkoop, dat een ongewenst effect als gevolg heeft op een andere silo, laten we zeggen Operations. We zien de relatie tussen oorzaak en gevolg echter niet omdat het in een andere afdeling gebeurt (plaats), en misschien met een vertraging (tijd). Onze focus op verkoop, versterkt door een KPI die slechts verkoop als output meet, zorgt er nog meer voor dat we het negatieve effect op een andere afdeling missen, omdat je die alleen kunt meten met een andere KPI dan degene waarop wij worden afgerekend.

De Obvious en Complicated domeinen worden de geordende domeinen genoemd. Veel organisaties denken zich in de geordende domeinen te bevinden, terwijl een toenemend aantal situaties in organisaties, teams, en processen eigenlijk in het complexe domein valt, wat een geheel andere aanpak vereist. Want in het Complexe domein werken ‘good’ of ‘best practices’ niet. De omgeving is niet stabiel noch voorspelbaar, en daardoor kunnen we niet simpelweg aannemen dat wat in het verleden werkte ook nu, in een andere context, zal werken. En we kunnen de toekomst ook niet plannen in het complexe domein. We kunnen het alleen ontdekken door te experimenteren. De relatie tussen oorzaak en gevolg kan er wel zijn, maar is meestal pas achteraf te constateren. Dit gaat tegen de intuïtie van veel managers in die dit dan ook maar moeilijk kunnen accepteren. Er is een dominante tendens om de toekomst te kunnen willen controleren en voorspellen, zelfs in situaties waar dat niet mogelijk is, en zelfs als we keer op keer constateren dat onze zorgvuldig opgestelde plannen al heel snel niet uit blijken te komen.

Laten we het factureringsproces als voorbeeld nemen. De meeste organisaties verkopen iets, dus facturering is een gebruikelijk proces. Je zou kunnen denken dat facturering een stabiel voorspelbaar statisch proces dat makkelijk kan worden afgehandeld en geoptimaliseerd door een geautomatiseerd proces. En dat klopt. Maar het gevaar is dat management nu alleen nog maar op regels e processen als middel gaan vertrouwen. Het gaat niet om de 95% aan facturen die correct verwerkt worden, de grootste impact ligt in de 5% waar iets mis gaat of die uitzonderlijk zijn. Dit zijn de gevallen die de meeste tijd kosten, en die een gevaar zijn voor de reputatie van het bedrijf als ze niet adequaat afgehandeld worden. Je kunt de uitzonderingen niet op dezelfde manier behandelen als de voorspelbare gevallen. Maar dat is wel wat de meeste organisaties doen. Als er een uitzondering gevonden wordt, dan creëren we een nieuwe regel. Als de klant klaagt over een foute factuur, dan passen we het proces aan. Tot de volgende uitzondering. En de volgende. Op deze manier worden de systemen langzaam steeds moeilijker te doorgronden en te onderhouden, steeds lastiger aan te passen aan nieuwe situaties, en erg kostbaar. En dan nog worden we telkens weer verrast door nieuwe uitzonderingen die nog niet afgedekt worden door regels. Wat de situatie nog erger maakt is dat de afhandeling van klachten van klanten over foute facturen hetzelfde probleem kent: Klantenservice medewerkers volgen over het algemeen een strikt script dat standaard situatie prima afdekt. Maar de frustratie van klanten komt niet van de standaard gevallen, maar van de uitzonderingen en het onvermogen van klantenservice medewerkers het probleem snel op te lossen

Klinkt dit bekend? Het is een continue bron van zendtijd voor consumentenprogramma’s op tv: telecombedrijven, energiemaatschappijen, en verzekeringsmaatschappijen die doorgezaagd worden over hun onvermogen om niet-standaard situaties, die echter voor klanten en de kijker zo duidelijk lijken, op een adequate manier af te handelen. Het is een klassiek voorbeeld van de verkeerde tool voor het probleemdomein. En toch lijken deze bedrijven er nooit van te leren. Wat is het standaard antwoord van de woordvoerder of manager die dapper genoeg is om voor de camera te verschijnen als hun gevraagd wordt hoe ze dit soort problemen in de toekomst gaan vooromen? “We gaan het proces analyseren en verbeteren”. Zucht…

En dat brengt ons bij het belangrijkste leerpunt van dit artikel: als je niet weet in welk domein je situatie zich bevind, dan zul je het waarschijnlijk behandelen als het domein van je voorkeur of ervaring. En in veel gevallen blijkt dat de verkeerde. Je zult dan tools gebruiken die op zich niet fout zijn, maar niet geschikt voor het betreffende probleem. Ten slotte, als je enige gereedschap een hamer is, dan lijkt elk probleem op een spijker…

When your only tool is a hammer

If your only tool is a hammer…

/in , , , , /door

The environment of organizations changes at an increasingly fast pace. Complexity and uncertainty are on the rise. But the set of tools that management uses to manage and design their organizations, is changing very slowly. There is an increasing mismatch between the applicability of tools used and the problem domains of modern organizations. How can we assess which domain we’re in and if we are using the appropriate tools?

There’s no denial that organizations operate in a world of fast change, uncertainty, and constant flux. Windows of opportunity open and close faster and faster. Maintaining a sustainable competitive advantage is pretty hard these days. It also seems apparent that most organizations are ill equipped for dealing with rapid change. One indicator is the life expectancy of organizations. It seems to be shrinking at an alarming rate. Professor Richard Foster of Yale University led a Innosight study that shows that a 61-year tenure for the average firm in the S&P 500 index in 1958 narrowed to 25 years in 1980, to only 18 years now. Even more, at this rate by 2027, over 75% of the S&P 500 will be companies you have never heard of. That’s pretty alarming, isn’t it?

There’s obviously work to do for the management of any organization. Complacency is your biggest enemy in this world, it is a one-way street to irrelevance. The business graveyard is full of companies that either reacted too slow or not at all to change. We don’t pretend to have a silver bullet that transforms any organization into a resilient adaptive organization that can deal with anything. But a first step is to be able to asses which problem domain were in and if the tools we use match the domain. Unfortunately, many organizations stick to tools they know like hierarchy, centralization, focus on efficiency, strict rules and processes, linear planning, etc. There’s nothing wrong with these tools per se, it is just that they were designed for organizations that existed about 100 years ago. Many management tools are, more or less, still the legacy of Frederick Taylor’s Scientific Management and Henri Fayol’s functions and principles of management. The world has changed dramatically since then. In the Western economies there aren’t that many industries anymore where these tools work well.

Every organization, department, team, or process is situated in a specific problem domain, each with its own appropriate tools. So how can we tell which one we’re in. A very useful tool here is a sense-making framework called Cynefin. The Cynefin framework has four main domains, and a fifth one called disorder, that each describe the context in terms of the relationship between cause and effect. The four main domains are called obvious (I still prefer the old term ‘simple’), complicated, complex, and chaotic. The disorder domain is used in case it is not clear in which domain we are.

For a detailed description of the Cynefin framework, you can read the excellent Harvard Business Review article by the framework’s founder Dave Snowden. For the purpose of this article we keep the explanation short: In the Obvious domain, we can easily categorize the problem we face and pick the appropriate checklist or process description to solve it. Because the environment here is pretty stable and predictable we can focus on optimizing best practice processes. A simple loan approval process is a good example.

In the Complicated domain things are not as simple and predictable. We need experts to analyze the situation before we can respond. Most of the time there is still a noticeable relationship between cause and effect but it can be separated in space and time making it hard to spot. This is reinforced by management structures like silo’s and KPI’s. We make a decision in one silo, let’s say sales, which has an undesirable effect on another silo, let’s say operations. We don’t see the relationship between cause and effect here because it occurs somewhere else (place) and maybe with a delay (time). Our focus on sales, reinforced by a KPI that just measures sales output, causes us to miss the unintended consequences for the operations department.

The Obvious and Complicated domains together are called the ordered domains. Many organizations think they are in the ordered domains, whereas an increasing number or situations in organizations, teams and processes actually fall in the complex domain, which requires a completely different approach. Because in the Complex domain, good or best practices won’t work. The environment is not stable or predictable, we therefore cannot simply repeat what worked in the past. Nor can we plan the future. We can only discover it by experimenting. The relationship between cause and effect might be there but in most cases can only be seen in retrospect. This is counterintuitive for many managers and therefore hard to accept. There is a dominant tendency to wanting to be able to control and predict the future, even in situations where we can’t, and even if we experience time after time that our carefully crafted plans quickly fall apart.

Now take an invoicing process for example. Most organizations sell something, so invoicing is a common process. You might think invoicing is a predictable stable static process that can easily be handled and optimized by an automated process, and therefore falls into the obvious domain. You are right. The danger is that this makes management rely on processes and rules only. It is not the 95% of correct invoices that matter, but the 5% that are incorrect or exceptional. These are the ones that take up most of the time, and are a danger to the organization’s reputation if not handled well. You cannot handle the exceptional cases the same way as you do predictable ones. But most organizations do. If an exception is found, we create another rule for it. If a customer complains about a wrong invoice we adapt the process. Until the next exception. And the next one. Our system slowly becomes hard to understand and maintain, slow to adapt to new situations, and very costly. And we still find ourselves constantly surprised by new exceptions we haven’t covered yet. What makes matters worse, the way we handle customer complaints on wrong invoices suffers from the same problem: Customers Service reps tend to use strict scripts that handle standard situations well. But the frustration of customers comes from the non-standard mistakes in the first place, and the inability of customer service the solve the issue only adds to the frustration.

Sounds familiar? It is a constant source of airtime for television consumer shows: telco’s, energy companies, and insurance companies getting scrutinized for their inability to properly deal with non-standard situations that appear so obvious for the customer and viewer. It is a classic example of using the wrong tool for the wrong domain. Yet these companies never seem to learn. What’s the standard reply of every spokesperson or executive brave enough to appear before the camera, when asked how they are going to prevent these issues in the future? “We will analyze the process and improve it”. Sigh…

And that brings us to the key takeaway of this article: if you don’t know which domain your situation is in, your will probably treat it as the domain of your preference and the one you are used to. And in many cases that turn out to be the wrong one. You will then be using tools that are not wrong per se, but they are inappropriate for the problem at hand. After all, if your only tool is a hammer, then every problem looks like a nail…

 

Medewerker Empowerment ontrafeld Deel 2

/in , /door

Empowerment en delegatie zijn management praktijken die steeds meer aan populariteit winnen. In deel 1 van dit artikel hebben we een aantal principes achter empowerment behandeld die uitleggen wat er mis kan gaan en waarom het tijd kost. In dit deel 2 bekijken we een praktische tool uit de Management 3.0 toolkit die kan helpen bij het implementeren van delegatie.

Management 3.0 onderscheidt zeven niveaus van delegatie. De delegatie niveaus en het bijbehorende delegatiebord helpen bij het implementeren van de principes die we in het eerste deel van dit artikel hebben behandeld. Het onderscheiden van meerdere niveaus van delegatie is zinvol. In het eerste deel van het artikel gaf ik al aan dat je grenzen moet stellen om delegatie succesvol te kunnen implementeren. Daarbij komt het hebben van meerdere niveaus goed van pas. De zeven niveaus zijn:

  1. Tell: Als manager neem je de beslissing en je informeert anderen over je beslissing. Dit is duidelijk het laagste niveau van delegatie. In feite is het juist helemaal geen delegatie, maar je zult besluitvormingsgebieden tegenkomen waar je de beslissing nu eenmaal niet aan anderen kunt overlaten.
  2. Sell: Jij neemt de beslissing maar je probeert anderen te overtuigen dat het de juiste beslissing is.
  3. Consult: Je vraagt om input, en neemt dan een beslissing waarbij je de input meeneemt.
  4. Agree: Je probeert consensus te bereiken binnen de groep over de juiste beslissing.
  5. Advise: Je biedt je advies aan, maar je laat de beslissing aan de groep over.
  6. Inquire: Zij nemen de beslissing maar je wilt wel geïnformeerd worden.
  7. Delegate: Zij nemen de beslissing en je hoeft niet eens te weten wat de beslissing is.

De eerste stap is het identificeren van de besluitvormingsgebieden. Dit kan variëren van vakantiedagen tot het aannemen van nieuwe teamleden. Probeer zo specifiek mogelijk te zijn. Doe dit niet in je eentje, doe het samen met de mensen waar je beslissingen naar wilt delegeren. Het is prima om een voorstel lijst als voorbereiding te hebben, maar let op dat je niet in de valkuil trapt om onbewust het laagste delegatie niveau te kiezen voor… het implementeren van delegatie…

De tweede stap is om elk besluitvormingsgebied langs te gaan met de groep en een passend delegatie niveau af te spreken. Het is acceptabel als er onderwerpen zijn waarop je een lager delegatieniveau wilt, je bent ten slotte bezig met het stellen van grenzen. Mensen begrijpen heus wel dat je niet alles aan ze zult overlaten. Vergeet het principe van reflexiviteit niet: team leden kunnen zich voor sommige besluitvormingsgebieden niet comfortabel voelen met een hoog delegatie niveau, zelfs als jij er vertrouwen in hebt dat ze het wel kunnen.

Management 3.0 heeft een handige set kaarten voor elk van de delegatie niveaus. Deze kun je puur gebruiken om het proces wat visueler te maken: het heeft nu eenmaal meer impact als je naar een kaartje kunt wijzen dan door te roepen ‘ik denk level 4!’. Je kunt de kaarten ook gebruiken voor Delegatie Poker, een afgeleide van de Scrum techniek Planning Poker die gebruikt wordt voor het inschatten van taken.

Het Delegatie Bord is de laatste stap: het is het visuele resultaat van de gemaakte afspraken. Het Delegatie Bord is een grid dat alle besluitvormingsgebieden als rijen weergeeft, en de zeven delegatie niveaus als kolommen. Het bij elk gebied horende afgesproken delegatie niveau wordt hierop weergegeven. Transparantie over de gemaakte afspraken is cruciaal.

Een voorbeeld van het gebruik van deze techniek is een manager die twee doelen had: het eerste doel was om de groep van teamleiders meer verantwoordelijkheid te geven. Het tweede doel was een praktische: het verminderen van haar workload dat veroorzaakt werd doordat de bedrijfsregels haar goedkeuring vereisten bij vrijwel alle besluiten. Ze was betrokken bij vele processen en besluiten die allemaal via haar liepen, terwijl de teamleiders dit prima zelf afkonden.

Je kunt de delegatie niveaus ook de andere kant op gebruiken. Dezelfde manager had een voor de organisatie vrij nieuwe rol. De grenzen van haar autoriteit waren vaag. Ze had soms het gevoel zeggenschap te missen op gebieden waar ze dit in haar rol wel zou verwachten. Het was duidelijk dat de organisatie nog moest wennen aan de nieuwe rol. In zo’n situatie kun je de delegatie niveaus ook gebruiken om duidelijkheid naar boven te krijgen: bespreek de delegatie niveaus op key beslissingsgebieden met je manager.

Wil je meer leren over modern management? Schrijf je dan in voor een van onze Management 3.0: Modern Leadership workshops.

Employee Empowerment demystified Part 2

/in , , /door

Empowerment and delegation are management practices that are gaining popularity. However they proof to be hard to implement. In part 1 of this article we explored some of the principles behind delegation and empowerment that help you explain what can go wrong and why it takes time. Next we are going to look at a practical tool from the Management 3.0 toolkit that helps implementing delegation.

Management 3.0 defines seven levels of delegation. The delegation levels and a delegation board help implementing empowerment following the principles we discussed in the first part of this article. Having multiple levels of delegation makes sense. When setting constraints you will find that for some decision areas different levels of delegation are appropriate. The seven levels are:

  1. Tell: You as manager make the decision and you inform others of the decision made. This is obviously the lowest level of delegation. Actually it not delegation at all, but there will be areas where you just cannot delegate decision making.
  2. Sell: You make the decision but you do try to convince others it is the right decision.
  3. Consult: You ask for input, and then make a decision taking the input into account.
  4. Agree: You try to reach consensus as a group on the right decision.
  5. Advise: You offer your opinion but it is their decision to make.
  6. Inquire: They make the decision but you do want to be informed.
  7. Delegate: They make the decision and you don’t even have to know what it is.

The first step is to identify areas of decision making. Be as specific as possible. Don’t do this on your own, do it together with the people you are delegating decisions to. It is ok to prepare a preliminary list of course but don’t fall into the trap of unconsciously choosing the lowest level of delegation for… implementing delegation.

The second step is to go by each decision area and agree on the appropriate delegation level. It is ok to be clear that some topics will have a lower level of delegation for now, after all you are setting constraints. People understand you won’t be leaving everything up to them. Don’t forget the reflexive principle: team members might not feel comfortable with a high delegation level at some areas, even if you feel confident they can do it.

Management 3.0 has nice sets of cards available that represent the delegation levels. You can use these just to make things more visual: it has more impact to point to a card than to say ‘level 4’. You can also use the cards to play Delegation Poker, a derivative of the Agile estimation technique Planning Poker.

The Delegation Board is the final step: it is the visual result of the agreements made. The Delegation Board is a grid that displays all decision areas as rows and the 7 delegation levels as columns. It marks the delegation level for each decision area. Being transparent on the agreed delegation levels is crucial.

An example of the use of the delegation board is a manager who had two goals: the first was to increase the level of responsibility of the team leaders in her group. The second one was a very practical one: to reduce her workload caused by the company policies requiring her to approve everything. She was involved in a lot of processes and decisions of which she felt her added value was limited. The team leaders could very well decide themselves.

You can use the delegation levels the other way around as well. The same manager was in a new role. The boundaries of her authority were blurred. She sometimes felt a lack of authority in areas she would have expected otherwise. Clearly the organization still needed to get used to the new role. In such a situation you can also use the delegation levels to clarify constraints upwards: discuss delegation levels on key decision areas with your manager.

Do you want to learn more about modern management? Attend one of our Management 3.0: Modern Leadership Practices classes.

Medewerker Empowerment ontrafeld Deel 1

/in , /door

Veel organisaties zijn zich ervan bewust dat de huidige tijd van hoge complexiteit en snelle veranderingen een uitdaging is om mee om te gaan, vooral voor het management. Het is niet zo dat de traditionele management technieken per se niet goed zijn, maar ze zijn niet langer het meest geschikt om de toenemende complexiteit mee te lijf te gaan. Daarom worstelen organisaties met het implementeren van andere vormen van management: medewerker empowerment; servant leadership; gedecentraliseerde besluitvorming; delegeren; zelforganiserende teams, het zijn allemaal termen voor hetzelfde concept: leg de autoriteit daar waar de informatie is. Dit concept blijkt echter best lastig te implementeren. In dit artikel ontrafelen we de geheimen en uitdagingen van empowerment en delegeren, en bieden we een eenvoudige doeltreffende Management 3.0 tool waarmee je direct aan de slag kunt.

Empowerment is belangrijk omdat het tot snellere en betere besluiten leidt. Hedendaagse organisaties opereren in een complexe omgeving. Het is steeds minder mogelijk om te vertrouwen op bewezen geoptimaliseerde processen omdat het werk niet meer zo voorspelbaar is. We komen steeds vaker in een situatie waarin we iets toepassen dat we nog niet eerder hebben gedaan. We hebben experts nodig die gecompliceerde situaties analyseren, en creatieve medewerkers die snel nieuwe ideeën kunnen creëren en valideren door middel van experimenten. Deze medewerkers hebben meestal meer inhoudelijke kennis dan hun managers. Dus laat hun beslissen: beslissingen zullen beter zijn omdat ze het beter weten. En ze zijn sneller omdat de hiërarchische besluitvormingsstructuur omzeild wordt.

Ontdek de principes van empowerment

Laten we uitgaan van een old school command-and-control type manager, Sam geheten. Je kunt het Sam overigens niet kwalijk nemen dat hij deze stijl nog steeds hanteert. Het zijn bedrijven en het onderwijssysteem die de Sams van deze wereld creëert en in stand houdt. Sam neemt deel in een management programma in zijn organisatie met als doel om van managers servant leaders te maken. Sam begrijpt waarom dit belangrijk is. Hij is enthousiast over de verandering, hoewel ook een beetje onzeker, maar zijn gevoel zegt hem dat dit de juiste koers is. Dus gaat hij ervoor.

Op een Maandagochtend roept Sam zijn teamleden bij elkaar en vertelt ze dat hij een ander type manager gaat worden. Vanaf nu zal hij het team coachen en faciliteren, in plaats van ze vertellen wat ze moeten doen. “Ik wil dat jullie empowered zijn”, zegt hij. “Jullie zijn nu een zelforganiserend team”. Ondanks dat de reactie van het team niet zo enthousiast is als hij had verwacht, is Sam nog vol vertrouwen.

Inmiddels zijn we een paar weken verder en Sam raakt steeds meer gefrustreerd. Hij heeft het gevoel dat mensen wel iets pro-actiever konden zijn. Waarom nemen ze zo weinig initiatief?! Hij geeft ze toch alle ruimte daartoe? Waarom lijken ze zich niet erg verantwoordelijk te voelen voor resultaten? Hij heeft ze alleen verteld welk resultaat hij verwacht en het ‘hoe’ aan de teamleden overgelaten, precies zoals hij geleerd heeft in de servant leadership workshop die hij gevolgd heeft. Maar het heeft allemaal nog niet tot betere resultaten geleid. Sterker nog, een paar keer was hij gedwongen om in te grijpen om een fout te herstellen die het team maakte. Hij krijgt het gevoel dat in elk geval sommige teamleden de verantwoordelijkheid niet aankunnen. Of misschien hebben ze gewoon liever dat hun wordt verteld wat te doen.

Dit is geen ongebruikelijk scenario. Agile coaches en Servant Leadership aficionados vertellen je dat iedereen graag controle over zijn eigen werk heeft. Maar waarom blijkt het dan zo moeizaam en langzaam in de praktijk om empowerment en delegatie te implementeren? Laten we de principes achter empowerment en delegatie ontrafelen.

Delegatie vereist grenzen stellenHet eerste principe lijkt op het eerste gezicht tegenstrijdig: Empowerment kan niet succesvol zijn zonder duidelijke grenzen. “Wacht even, empowerment ging toch juist om meer controle geven? Dus wat bedoel je met grenzen stellen?”. Delegatie is nooit absoluut, en als je niet volledig transparant bent over welke beslissingen mensen wel en welke ze niet kunnen nemen, dan zullen ze waarschijnlijk aarzelen om überhaupt een beslissing te nemen. Mensen zullen zich onzeker voelen of het nemen van een beslissing wel echt ok is. Wellicht zetten ze zelfs een stapje terug afwachtend tot iemand anders eerst gaat. Ze kunnen achterdochtig zijn of het bedrijf het wel echt meent en ze niet alsnog de eerste de beste fout kwalijk zullen nemen die ze ongetwijfeld gaan maken. Dus hoewel het tegenstrijdig kan klinken, is het stellen van grenzen en daar transparant over zijn cruciaal om een veilige omgeving te creëren voor het nemen van initiatief.

Management 3.0: Delegatie is reflexiefEmpowerment is reflexief. Delegatie is geen eenrichtingsverkeer. Het gaat beide kanten op. Werknemers hebben zelf ook een verwachting wat ze aan een manager kunnen overlaten. Een team is wellicht (nog) niet comfortabel met een bepaald niveau van delegatie voor een beslissingsgebied, zelfs als jij er wel vertrouwen in hebt dat ze het aankunnen. Als manager dien je dat te respecteren. Delegatie is ook niet statisch, je kunt verder delegeren in de loop van de tijd.

Management 3.0: Delegatie vereist vertrouwen en geduldEmpowerment vereist vertrouwen. En geduld. Als je zegt dat je bepaalde beslissingen overlaat aan je medewerkers, dan kun je dat maar beter echt menen. Storm niet binnen met een goedbedoeld advies op het eerste moment dat je aarzeling ziet bij het team. Vertrouw erop dat ze er zelf uitkomen. Nog erger is ze een fout kwalijk nemen die ze ongetwijfeld gaan maken. In plaats van “Waar ben je nou mee bezig?!” kun je beter zeggen “Wat kunnen we de volgende keer beter doen?”. Woordkeuze, hoe subtiel ook, is cruciaal: Jouw mentaal model kan je ertoe verleiden bepaalde woorden te kiezen die een averechts effect kunnen hebben. Het zal soms frustrerend zijn, het zal je geduld op de proef stellen, je zult jezelf ervan moeten weerhouden om in te grijpen. Begrijp me niet verkeerd, ik bedoel niet dat je je mensen maar moeten laten zwemmen. Maar neem het niet over. Vertrouwen gaat ook beide kanten op: jij moet je werknemers vertrouwen, maar je moet ook zelf bewijzen hun vertrouwen waard te zijn. Zo niet, dan is het momentum weg, en kan het een hele tijd duren voor iemand weer een initiatief durft te nemen.

Empowerment is een investering, en het kan even duren voor je resultaat krijgt. Onthoudt dat mensen geprogrammeerd zijn voor compliance, of volgzaamheid in goed Nederlands. Niet van nature, maar door de organisaties waarin we werken en door het onderwijssysteem. Het start al als kinderen naar school gaan: plotseling moet je letterlijk en figuurlijk binnen de lijntjes kleuren. Fouten worden steevast gecorrigeerd. “Een fout maken is verkeerd”, is de onbewuste boodschap. De hele dag wordt ons verteld wat we moeten doen. Als je aan je eerste baan begint, wordt het nog duidelijker. Anderen vertellen jou wat je moet doen en hoe je het moet doen. Ondanks dat management wel zegt dat ze initiatief en creativiteit verwachten, en ondanks verwoede pogingen van HR tot werknemers engagement programma’s is de subtiele onuitgesproken boodschap die we voelen toch: “Doe wat er van je verwacht wordt”. “Volg.” Dus als je dit echt serieus en gemeend wil veranderen in je organisatie, besef dan dat het een tijd duurt voordat mensen veranderen.

Het begrijpen van deze principes is één ding, het toepassen is de volgende stap. In deel 2 van dit artikel bespreken we een eenvoudig maar effectief instrument voor delegatie dat de zojuist besproken principes omarmt.

Wil je zelf aan de slag met moderne vormen van management? Volg één van onze Management 3.0: Modern Leadership Practices workshops.

Employee Empowerment demystified Part 1

/in , /door

Most organizations are aware that these times of high complexity and fast paced change are a challenge to cope with, especially for management. It’s not that traditional management techniques are wrong per se, but they are no longer the most appropriate way to face today’s complexity. So organizations are struggling to implement alternative ways of managing: Employee empowerment; servant leadership; decentralized decision making; delegation; self-organizing teams, these are all terms for the same concept: put the authority where the information is. The concept proofs to be pretty hard to implement however. This article is going to demystify empowerment and delegation as well as provide a simple yet powerful Management 3.0 tool that you can start using today.

The reason why empowerment is important is that it enables faster and better decision making. Today’s organizations operate in a complex environment. You cannot rely on following proven optimized processes because the work is not that predictable anymore. We often find ourselves doing things we haven’t done before. We need experts that can analyze complicated situations, and creative workers that know how to quickly create and validate ideas using experiments. These workers most often know the work better than their managers. So let them decide: decisions will be better because they know better. And they will be faster because the hierarchal chain of authority is short circuited.

Exploring principles of empowerment

So let’s assume we have an old school command and control type of manager, called Sam. Don’t blame Sam by the way, because it’s organizations and the education system that create and maintain Sams. Sam participates in a new management program in his company with the purpose of turning managers into servant leaders. Sam gets the reason why. He is enthusiastic about the change, a little anxious perhaps, but his guts tell him this is a more effective way. So he is going for it.

On Monday morning Sam gathers his team members telling them he is going to be a different manager. He will be facilitating and coaching the members from now on, and not be telling them what to do anymore. “I want you guys to be empowered”, he tells them. “You are a self-organizing team from now on”. While the team’s reaction was not as enthusiastic as he had expected, Sam is still confident and excited.

A few weeks go by and Sam is feeling increasingly frustrated. Things are not changing as fast as he had expected. He feels people could be more proactive. Why aren’t they taking initiative?! After all he has given them every room to do so. Why do they not seem to feel accountable for results? He has just told them what results he expects leaving the ‘how’ up to them, just as he was taught in the servant leadership workshop he attended. But it hasn’t led to better results yet. As a matter of fact, he was forced to step in a couple of times to correct mistakes that were made. He begins to feel that at least some team members cannot handle responsibility. Or maybe they just prefer to be controlled.

This is not an uncommon scenario. Agile coaches and Servant Leadership aficionados will tell you people want to have control over their own work. So why does it proof to be so cumbersome and slow to implement empowerment and delegation? Let’s unravel the principles of empowerment and delegation.

The first principle seems to be contradicting at first: Empowerment cannot be successful without clear constraints. “Wait a minute, empowerment was about giving people more control. So what are you talking about when you say you need to set constraints?” Delegation is never absolute, so unless you are very transparent which decisions people can make themselves and which they cannot, they will be reluctant to make any decision. People will feel insecure on making a decision not sure if it is really ok. They might take a backseat waiting for others to go first. They might be conspicuous whether the company really means it and will not blame them for the very first mistake they make as a result of a decision. Although it might sound contradicting, if you set clear boundaries and are very transparent on them, you create a safe environment for taking initiative.

Empowerment is reflexive. Delegation is not a one way street. It goes both ways. Employees have expectations of what they can leave up to the manager too. A team might not feel comfortable with a certain level of delegation for some area (yet), even if you do. As a manager you need to respect that. Delegation does not only go downwards. It goes up too.

Empowerment requires trust. And patience. When you say you are going to leave certain decisions to the employees, you better mean it. Don’t come rushing in with good advice the moment you see some hesitation. Trust them to get it sorted out. Even worse is blaming them for a mistake they are inevitably going to make. Instead of “What were you thinking?!” say “What can we do better next time?”. Your choice of words, no matter how subtle, is crucial. Your mental model might unconsciously lure you into choosing words that have a backwards effect. It will feel frustrating at times, it will test your patience, you will have to stop yourself from stepping in. Don’t get me wrong, I don’t mean just let them sink. You are there to help if they want it. But don’t take over. Trust goes both ways too: you need to trust the workers, but you need to live up to their trust as well. If you don’t the momentum is gone and they will not dare to take initiative anytime soon anymore.

Empowerment is an investment, it may take a while before you get your return on investment. Remember, people are wired for compliance. Not by nature, but by organizations and the education system. It starts as soon as children go to school: Suddenly you are required, both litterally and figurally speaking to color within the lines. Mistakes are structurally corrected. “Making a mistake is wrong” is the unconcious message. All day you are supposed to do what you are told. It gets even clearer when you start your first job. Others tell you what to do and how. All employee engagement programs set aside, people feel they are expected to comply. So when you are genuinely trying to change this in your organization, know it will take a while for people to change.

Understanding these principles is one thing, using them is another. In part 2 of this blog we provide a simple yet effective tool for delegation that honours the principles just discussed.

Do you want to learn more about modern management? Attend one of our Management 3.0: Modern Leadership Practices classes.

Comments on SAFe 4.5: is it all cosmetic?

/in , , /door

Recently SAFe 4.5 was released. Of course there is a lot of information from SAI itself on what’s new in SAFe 4.5, so I want won’t cover all changes in detail here but focus on adding some comments on the significance and usefulness of the changes, or lack of it for that matter.

Cosmetic surgery isn’t always a bad thing

Let me start with something that might feel cosmetic but actually is the most significant improvement in my opinion, namely the fact that the ‘Big Picture’ didn’t get bigger or more complicated this time. From SAFe 3.0 to 4.0 the framework went from three layers to four. In my SAFe courses I sometimes joke that hopefully SAFe 5.0 will not have five layers. I still spend quite some time explaining you should not consider using the Values Stream layer unless it is a very large complex SAFe adoption. While the challenge of coordinating multiple trains in a single Value Stream is of course real, the solution SAFe presents in the Value Stream layer leans rather high towards processes if we consider the Agile Manifesto value Individuals and Interactions over Processes and Tools. In this respect I rather like the most basic coordination mechanism in LeSS: Just Talk. We can come a long way using this mechanism before we actually need to define formal processes in my opinion. It is actually a trap for larger bureaucratic organizations trying to transform to a more agile organization: they have the tendency to model everything in processes instead of telling people to just talk to each other whenever there is something to coordinate.

So the Big Picture didn’t get any bigger this time. Actually it got a lot cleaner. The most significant change in this regard is the configurability of the Big Picture. SAFe now has four base configurations targeted at a specific context. Each configuration only displays the constructs that are relevant for that configuration, making the big picture a lot easier to read. The four configurations are: Essential SAFe, Portfolio SAFe, Large SAFe, and Full SAFe. Selecting a configuration and watching the Big Picture change accordingly is actually quite fun and insightful.
Second, the Big Picture got a visual make-over making it less cluttered and easier to read. SAI claims they actually added more stuff then they removed so kudos to the visual designer.
Third, the Value Stream layer is renamed to Large Solution. Again, this seems purely cosmetic, but as I said I spend a lot of time explaining to people you don’t need to do everything on the Big Picture just because it is on there. Calling it Large Solution will definitely make it easier to understand you only need a large solution when you have a… large problem.

Now you might wonder why I spend so much time on cosmetic changes. The reason is the ‘completeness’ of the Big Picture is both a blessing, you click on anything and instantly get tons of information on the topic, and a curse. Organizations have a tendency to want to implement everything on the Big Picture because they think they are supposed to. The overview can also be quite overwhelming at first glance. And it also makes SAFe an easy target for a sometimes rather loud group of agilists, sitting comfortably high on Mount Stupid, shouting down that SAFE is not agile at all, usually while having no more experience than glancing at the Big Picture at scaledagileframework.com. Yeah, I could just ignore those people but unfortunately they tell their tales to customers as well. If you haven’t heard of Mount Stupid, also known as the Dunning-Kruger effect, it is the phenomenon that people who are the most ignorant on a subject are also the ones most eager to share their opinion on it. Sounds familiar?

Lean Startup

Of course there are more substantial changes too. But you can read about those in detail on the SAFe website.

One is the integration of Lean Startup. A very welcome addition, no doubt, but to be fair there was nothing in SAFe 4.0 that prevented you from using Lean Startup within SAFe. I have actually promoted the fact that everything is a hypothesis that needs to be validated as fast as possible from the start. I have also seen companies use Alexander Osterwalder’s Business Model canvases and Value Proposition design; or Ash Maurya’s Lean Canvas successfully within SAFe. We don’t need it on the Big Picture for this. But the guidance is of course welcome.

Other changes

The role of DevOps is growing in SAFe 4.5 which is a good thing. Not much I can add to that. Continuous Delivery is emphasized more and has gotten a bit more substance. Good, but you were supposed to take Continuous Delivery very seriously anyway already.

Now we all know that delivery and releasing are not the same but they are related of course. One noticeable change on releasing: it has gone from Release on Demand (v3.0) to Release Anytime (v4.0) and back to Release on Demand again in v4.5. Make up your minds guys. 😉

What else? The Implementation Roadmap is there, but to be honest it was already published before the release of 4.5. The implementation roadmap is a big step forward from the rather ridiculous 123 model that seems to have dropped of the Big Picture. Thankfully. Tons of useful information there but one major flaw still remains: It is still a more or less linear process. I strongly feel that a change process should also be iterative, based on experiments and short feedback loops. I recommend looking at Lean Change Management and combine it with the Implementation Roadmap.

Conclusion

So although there are lots of useful additions and changes to SAFe 4.5 the most significant changes are the ones that might appear purely cosmetic at first glance. I think those can actually prevent some organizations from falling into common traps.

Commentaar op SAFe 4.5: puur cosmetisch?

/in , , /door

SAFe 4.5 is pas uitgekomen. Natuurlijk kun je heel veel informatie over wat er nieuw is in SAFe 4.5 vinden bij SAI zelf, dus zal ik niet alles in detail hier behandelen, maar vooral hier en daar wat commentaar geven over het belang en nut van de wijzigingen, of het ontbreken daarvan.

Cosmetische chirurgie is niet altijd slecht

Laat me beginnen met iets dat misschien vooral cosmetisch lijkt, maar voor mij de meest belangrijke verbetering is, namelijk het feit dat de ‘Big Picture’ niet groter of gecompliceerder is geworden deze keer. Van SAFe 3.0 naar 4.0 ging het framework van drie lagen naar vier. In mijn SAFe trainingen grap ik nog steeds dat ik hoop dat SAFe 5.0 straks geen vijf lagen heeft. Ik besteed behoorlijk wat tijd om uit te leggen dat je die extra  Values Stream laag niet moet overwegen tenzij het een heel grote en complexe SAFe implementatie betreft. Natuurlijk is het coördineren van meerdere ARTs in een Value Stream een reële uitdaging. Echter SAFe’s oplossing in de Value Stream laag helt wel erg over naar processen als je even stilstaat bij de Agile Manifesto waarde Individuals and Interactions over Processes and Tools. Wat dat betreft waardeer ik het meest basic coördinatie mechanisme in LeSS erg: Just Talk. We kunnen hier een heel eind mee komen voordat het echt nodig is om formele processen te definiëren. En dit is in feite een valkuil voor veel grotere bureaucratische organisaties die zichzelf in een meer agile organisatie willen omvormen: ze hebben de neiging om alles in processen te modelleren in plaats van mensen te vertellen dat ze ook gewoon met elkaar kunnen gaan overleggen als er iets afgestemd moet worden.

Dus gelukkig is de Big Picture deze keer niet groter geworden. In feite is het een stuk cleaner geworden. De meest significante bijdrage daaraan is de nieuwe configurabiliteit van de Big Picture. SAFe heeft nu vier basis configuraties die elk op een eigen specifieke context zijn gericht. Elke configuratie toont alleen die elementen die relevant zijn voor die configuratie. En hierdoor is de Big Picture een stuk overzichtelijker en makkelijker te begrijpen. De vier configuraties zijn: Essential SAFe, Portfolio SAFe, Large SAFe, en Full SAFe. Een configuratie selecteren en de Big Picture zien aanpassen is eigenlijk best leuk en leerzaam. Ten tweede heeft de Big Picture een make-over gekregen en is daardoor veel minder druk en beter leesbaar. SAI claimt dat ze eigenlijk meer elementen hebben toegevoegd dan weggehaald, dus Kudos aan de visual designer. Ten slotte is de Value Stream laag hernoemd naar Large Solution. Dit lijkt ook weer puur cosmetisch, maar zoals ik al eerder schreef besteed ik veel tijd om mensen uit te leggen dat je niet alles dat op de Big Picture staat moet implementeren alleen maar omdat het erop staat. Door het Large Solution te noemen wordt het denk ik een stuk gemakkelijker te begrijpen dat je een Grote Oplossing alleen nodig hebt bij … een groot probleem.

Nu vraag je je wellicht af waarom ik zoveel aandacht besteed aan cosmetische wijzigingen. De reden hiervoor is dat de ‘compleetheid’ van de Big Picture zowel een zegen is, je kunt immers op alles klikken en een schat aan informatie krijgen, als een vloek. Organisaties hebben de neiging om alles op de Big Picture te implementeren omdat ze denken dat het nodig is. Een cleanere Big Picture kan helpen. Daarbij kan de overvolle Big Picture best overweldigend overkomen en afschrikken in eerste instantie. Maar een andere belangrijke reden is dat het SAFe een makkelijke prooi maakt voor die soms tamelijk luidruchtige groep aan agilisten die, comfortabel vanaf de top van Mount Stupid, naar beneden schreeuwen dat SAFe helemaal niet Agile is, en dat terwijl hun ervaring ermee over het algemeen niet veel verder rijkt dan het bekijken van de Big Picture op scaledagileframework.com. Ja, natuurlijk zou ik ze gewoon kunnen negeren, maar helaas hebben deze lui de neiging hun verhalen ook aan klanten te vertellen. Als je nog nooit van Mount Stupid, ook wel het Dunning-Kruger effect genoemd, hebt gehoord, dat is het fenomeen waarbij die mensen die het minst van een onderwerp afweten zich het meest comfortabel schijnen te voelen om hun mening erover te verkondigen. Klinkt bekend?

Lean Startup

Natuurlijk zijn er ook meer substantiele wijzigingen. Maar daar kun je alle details over lezen op de SAFe website.

Een ervan is de integratie van Lean Startup. Een zeer welkome aanvulling, dat zeker, maar om eerlijk te zijn was er natuurlijk in SAFe 4.0 al niets dat je in de weg stond om Lean Startup praktijken te gebruiken binnen SAFe. Ik promoot al vanaf het begin dat alles een hypothese behoort te zijn die we zo snel mogelijk moeten zien te valideren. Ik heb organisaties ook Alexander Osterwalder’s Business Model canvas en Value Proposition design zien gebruiken binnen SAFe; of Ash Maurya’s Lean Canvas. We hoeven het daarvoor niet per se op de Big Picture te hebben staan. Maar de adviezen zijn natuurlijk erg welkom.

Andere wijzigingen

De rol van DevOps neemt steeds meer toe in SAFe en dat is iets goeds. Veel meer dan dat kan ik er niet over zeggen. Continuous Delivery wordt ook meer benadrukt en krijgt wat meer substantie. Mooi, maar we wisten natuurlijk allemaal al lang dat we Continuous Delivery zeer serieus moeten nemen in elke (geschaalde) Agile omgeving.

Nu weten we ook allemaal dat delivery en release niet hetzelfde zijn, maar wel aan elkaar gerelateerd. Je wil op elk moment kunnen ‘deliveren’, maar niet per se tegelijkertijd ‘releasen’. Er is een enigszins opmerkelijke wijziging in 4.5 als het gaat om releasen: het ging van Release on Demand (v3.0) naar Release Anytime (4.0), en nu weer terug naar Release on Demand in v4.5. Make up your minds guys. 😉

Wat nog meer? De The Implementation Roadmap is er, maar eerlijkheid biedt te zeggen dat die al geruime tijd voor 4.5 uitgekomen is. De Implementation Roadmap is overigens wel een flink stap vooruit ten opzicht van het belachelijke 123 model dat van de Big Picture lijkt te zijn afgevallen. Gelukkig maar. De roadmap biedt veel nuttige informatie maar er blijft een belangrijk mankement: het is nog steeds min of meer een lineair proces. Ik hecht er sterk aan dat een veranderproces ook iteratief moet zijn, gebaseerd op experimenten, en korte feedbackloops. Ik kan je aanbevelen om te kijken naar Lean Change Management en dit te combineren met de Implementation Roadmap.

Conclusie

Dus, ondanks dat er veel nuttige toevoegingen en wijzigingen in SAFe 4.5 zitten, kunnen de meest belangrijke wijzigingen op het eerste gezicht puur cosmetisch lijken. Ik denk dat deze wijzigingen echter erg belangrijk zijn om te helpen voorkomen dat organisaties in een aantal geniepige valkuilen stappen.
[/av_textblock]

How to help management towards servant leadership?

/in /door

During a recent Management 3.0 training I provided one of the attendants had a question on how we could help management towards a change in their role. How can we motivate middle management in particular because for them a management transition towards servant leadership potentially has such a huge impact. How do we deal with the question “If I am going to loose control because I am supposed to delegate authority downwards, what is it that I get back?”

This question led to a good discussion in the group, but even after the course the question stuck to me. It is an important question that deserves a thorough answer. And that’s the reason for this article. In this article I will attempt to provide suggestions on ways to help management fulfill a different role. I will try to use the tools and knowledge that Management 3.0 provides.

A little bit of background information: Management 3.0 is a body of knowledge that concerns itself with a different way of fulfilling the role of management in organizations. It replaces direct control of people with the creation of an environment in which employees can be motivated, can take control, and can learn continuously. The need for this different role of management is twofold: On one side the environment of organizations is changing increasingly fast and is rapidly getting more complex. Traditional management methods do not handle this complicity very well. On the other side it just makes work more fun, which eventually will also lead to better results as is indicated by numerous research.

Organization with a desire to become more adaptive can use Management 3.0 principles to achieve this. For teams and individuals this often has a direct positive impact because they get more autonomy, more chances to take initiative and opportunities to develop themselves. For senior management it is a strategic choice they deem necessary for the long term succes of the company. But for middle management, as we often experience in our consultancy work, this change has the biggest impact. They have to let go of a style of management that has been imprinted in their minds for years. They are suddenly expected to to adopt practices that feel alien to everything they have ever learned on the subject of management. Many times they have to implement this change while they are still being ‘managed the old way’ themselves. No easy job. In this situation it seems a very relevant question: How can we help the manager in this transition?

The original question was formulated in terms of “We are taking something away from the manager. What does he get back in return?” I think this is a bit of a trap. It can understandingly be the line of reasoning for the manager in question himself, but I think we must be careful to follow him in this line of reasoning. It is not a simple exchange. The ’thing’ we are taking away is something that has been an intrinsic part of the manager’s fundamental believes on management for years: “If I am to be responsible for something, I expect to have the authority that comes with it”. He knows how to do his job the current way through and through. The new way of management is probably largely uncharted territory for him. And even for someone who truly believes in the need for change, it is going to take a while to really appreciate ‘what you got back’. Besides, ’taking something away’ suggests a sudden change, and reality teaches us that a careful coaching is crucial. And even then it will often feel as a sudden change anyway, because the positive consequences are only seen later.

So what are the step we can take?

 

Start with personal motivation

Start with gaining insight in what the person in question truly motivates. A helpful tools for this within the Management 3.0 toolkit is Moving Motivators, which is a set of 10 intrinsic and extrinsic motivators we can use to get an understanding of what matters to someone and get him going. Some people are motivated by status for example. For others the relationship with coworkers is very important.

So we start with personal motivation. The tool offers a set of cards, one for each of the 10 motivators. Ask the person in question to rank the cards in order of importance. Which motivator is most important for him in the context of work? Which ones are less important. Having a conversation on the ranking is the real value of course because then you will explore why some motivators are so important to someone.

Moving Motivators

The second step indicates whether certain motivators are positively or negatively influenced by someone’s current role. Imagine someone values status. Does the current role fulfill that motivator in a positive or negatieve way? Ask for actual examples. Move motivator card that are positively triggered up, and negatively triggered motivators down. This creates a visual image that of course is something to discus again.

Next we do the same looking at the expectation of the new contents of the management role. Are some important motivators that were triggered positively so far now expected to be triggered in a negative manner?

These steps of course provide some important insight to the change team. But more important is the insight for the manager himself. I have experienced that a manager expected some motivators to get negatively triggered by her new role, but she also discovered some other motivators were potentially triggered in a positive way. These are the first step in coaching. This also touches the second goal of this focus on motivation: it gives the manager the feeling that his personal motivation matters. We are not simply taking something away and give something in return. We go on a journey that fulfills a new role in a way in which personal motivations matter.

Purpose

Dan Pink points out that organizations should spend more time on asking WHY we do something and less on HOW the work should be done. He has illustrated this with an example of a research study that was conducted among call center volunteers at a major US University. The call center workers participated in fund raising for valuable scientific research. The researches divided the workers into three groups: One group spend five minutes of reading letters from former call center workers explaining which personal benefits the work had brought them, before they started calling. The second group also read letters for five minutes, but this time they where from people that had received funds and explained what valuable research the money was spend on. The third group was a control group and were allowed to spend the five minutes anyway they wanted. The two groups that read letters before calling outperformed the control group by far. But the group that read letters on the impact of the donations raised twice as much money as the other group!

People are motivated by a higher purpose if that purpose is clear and they know how to contribute to it. Even more so if the purpose aligns with their personal goals and values. So don’t start with HOW the new role of management should look like, but start with the question WHY we are making this change in the first place. Be crystal clear on the purpose of the organization, and give management the opportunity to align their personal goals with the goals of the organization. Don’t be surprised if some managers get so engaged in the process they start looking for new ways to fulfill the management role  in line with the company purpose by themselves.

Offer a generous exit

Helping managers through a change also means helping them to gain insights whether the new role really fits them or not. Don’t expect everybody to be able or willing to take the journey with you. And that should be ok. If the new role does not trigger any personal motivation in a positive way, you will not be doing that person, or the organization for that matter, any favor to force someone into the new role.

It is important to be transparent that the conclusion that a new role does not fit is an acceptable outcome. It is not a personal failure. Offer a generous exit as part of the transition, and be very transparant on this upfront. Realize that it is the organization itself that is responsible for the current management style in the first place. We created the type of managers we know expect to change in a way that differs fundamentally from anything they were ever taught on management. So senior leaders must take responsibility for anyone that is not able to follow in this change.

What does this mean exactly? Take your time for this transition. Don’t force people to fundamentally change their style of management overnight. Sending them to a course is not enough.

Help people towards another job is they are not able or willing to follow the change. This can also be a new job/role within the company! Many organizations we encounter silently broadcast the message that the only way to have a sustainable career in the company is the way up. Moving up the management ladder. But the modern management we are talking about changes more than just the job description of managers: the emphasis on the hierarchical structure of the organization need to lessen as well. After all, we are delegating authority downwards. For some (ex) managers this can feel as a liberation: finally they can find the time to actually work on something and get things done. Many managers have missed the satisfaction of actually accomplishing some task more then they are willing to admit. Embracing Management 3.0 does not entail we have less management as an activity, but it does mean we have less people that are dedicated managers. Management as an activity will be distributed more broadly throughout the organization. But this also can accomplish a new appreciation for craftsmanship as a way to make a career.

 

Change the entire chain

A phenomenon we often encounter is that senior management decides things need to change: employees and teams need te become self-organizing. Middle management need to execute this change by delegating decisions and responsibility downwards. But senior management itself does not change (at least for now). This creates a very difficult situation for middle management: they are expected to decentralize control, while at the same time they are themselves still managed the old way in a command-and-control fashion. We often see that middle managers are still held directly accountable for the people that ‘report’ to him or here.

My advise is very clear: Change the entire chain of authority, both below AND above the middle manager.

Use the chain to determine the needs of people towards middle management in the new situation. Ask teams what they need from the manager to be successful.  Ask senior management what they expect from middle management. This creates both clarity and support.

Coaching

By now it should be clear that thorough coaching is imperative for a smooth transition to a new management style. The most important advice is to take your time. A fast instrumental intervention in which the new management role is determined by others than those are going to fulfill it will not work. There’s a famous quote of Peter Drucker called ““Culture eats strategy for breakfast”. An instrumental intervention does not change values, beliefs, informal contacts, and habits. And in the end nothing will change because of this. Culture will always be stronger then imposed processes, rules, and procedures. You need to realize that a change of the role of management is nothing less than a change of culture.

Coaching means training and helping the group of managers, but also personal coaching. Coaching also means managers are involved in defining the new management role.

Another advice is to start a buddy system that allows managers to support each other and learn form each other. This contributes to reflection on the new role, and they can help each other in challenging situations that will no doubt arise.

 

Coaches will have to be external at first. Because who in the organization is totally free of the principles, values, styles, and habits that we are trying to change? Even the most enthusiastic pro-change manager has to work within the current context and therefore will be influenced by it. But in the end the force for sustainable change needs to come form inside. It is too important to leave to external coaches. So an important task of external coaches is to create internal champions that support and in the end take over the job of the external coach.

Conclusion

The transformation towards an agile adaptive organization calls for a fundamental change of the role of management. Because the new role of management differs so fundamentally from what has been the standard for decades it is imperative that coaching and helping management in this transition is taken seriously. Paying attention to the personal motivators of managers is one important stap. A clear purpose that managers can align with their personal goals, beliefs, and motivators is another. It is crucial to change the entire management chain, not just middle management. Personal coaching, in conjunction with a buddy system, is aimed at creating internal champions. And for those who are not able or willing to make the transition the organization should offer a generous exit that displays the responsibility the organisation has in creating the kind of managers people need to change form in the first place.