Ett tillstånd eller egenskap som gör något intrikat eller komplicerat, till exempel genom att bestå av många delar, vara svårt att förstå eller överblicka.

Mary Poppendieck, som myntade begreppet Lean Software Development, har liknat komplexitet i organisationer med högt kolesterol i människokroppen. Du är förmodligen inte medveten om att du har det förrän du letar efter det och har du otur så tar det kål på dig.

Komplexiteten tenderar att alltid öka över tid i takt med att en produkt eller organisation växer i storlek. Om man saknar tydliga strategiska riktlinjer för hur man motverkar den, kommer komplexiteten att växa och bli allt jobbigare att ta sig an. Produktstrategier, teknikstrategier, infrastrukturstrategier och så vidare. Strategierna måste vara formulerade på ett sådant sätt att de ger praktisk guidning i vardagens taktiska beslut.

Här går många organisationer bort sig redan från start, eftersom man ser strategiarbetet som en separat aktivitet. Då kommer man ganska snart tycka att man inte har tid till strategiarbete. De flesta har fullt upp med att hantera sin vardag, så strategiarbetet får alltid stå tillbaka om det inte sker i och under det dagliga arbetet.

Komplexitetsnivån är en viktig hälsoindikator för alla organisationer och företag. Det är också komplexiteten som i stor utsträckning avgör hur hög press du kan utsätta din organisation för innan stressen eskalerar.

I Stressekvationen finns ett multiplikationstecken mellan press och komplexitet. Det innebär att om man har hög komplexitet, så får höjd press stora konsekvenser för den totala stressnivån. På samma sätt kan en sänkt komplexitet ge en rejäl sänkning i stressnivå, även med bibehållen press.

Alfred North Whitehead, filosof och matematiker, mest känd för att ha skrivit Principia Mathematica tillsammans med Bertrand Russel uttryckte det som att: Civilisationen avancerar genom att utöka antalet viktiga operationer som vi kan utföra utan att behöva tänka på dem.

Hur många organisationer har den inställningen till sina verktyg, sina produkter, sin organisationsstruktur? Jag skulle vilja formulera om det som: Organisationen avancerar genom att fler viktiga saker kan bli gjorda utan att det kräver någon större insats.

Vad har ni som organisation gjort den senaste månaden för att göra det enklare för er själva att leverera?

I likhet med Press vill jag dela in komplexitet i två underkategorier: Kognitiv belastning och Tröghet i systemet.

Kognitiv belastning

Starkt förenklat handlar kognitiv belastning om hur mycket arbetsminne som krävs för att lösa ett problem eller en uppgift - hur hårt belastat ditt arbetsminne är och hur ofta du behöver byta innehållet i ditt arbetsminne.

Ju större kognitiv belastning för att lösa ett problem, desto större risk att ett fel uppstår. Ju större kognitiv belastning, desto längre tid tar det att nå den djupa koncentration som behövs för att arbetsminnet ska nå ett tillstånd då uppgiften kan lösas.

Inom systemutveckling krävs ofta djup koncentration för att lösa problem. Vissa företag har infört mötesfria dagar för att deras anställda ska kunna nå den djupa koncentration och fokus som krävs för att lösa svåra uppgifter. Genom att minimera mängden avbrott och byten av kontext som möten kan innebära, anser man sig få bättre förutsättningar för effektivt arbete.

Ett företag jag läste om - som jag nu tyvärr glömt namnet på - hade totalt mötesförbud tisdag, onsdag och torsdag. Alla förbokade interna möten lades på måndagar och fredagar. För alla. Inklusive chefer och management.

På mötesfria dagar fick man bara spontant sammankalla för att lösa problem relaterade till pågående arbete i produktutvecklingen. Allas fokus låg på att färdigställa pågående arbete så snabbt som möjligt och att röja hinder. Genom att frigöra tre dagar i veckan från möten var sannolikheten stor att man snabbt kunde sammankalla alla som behövdes för att lösa ett problem - inklusive höga chefer - för ingen satt fast i möten.

Nu kan det kanske vara lätt att tro att jag tycker möten är dåliga, men det tycker jag inte. Jag gillar verkligen bra möten!

Tyvärr lider de flesta organisationer av ineffektiva möten med tveksamt syfte, luddig utkomst och dålig facilitering. I bästa fall är mötena bara tråkiga, i värsta fall bidrar de till att öka den kognitiva belastningen i organisationen utan att skapa något värde. Fy fanders!

Vad som skapar den kognitiva belastningen varierar mellan bolag och branscher. Jag kommer återigen dra några exempel från systemutvecklingsvärlden och försöka hålla beskrivningen så generell att ni hajar grejen.

Produktdesign

Vikten av bra kodstruktur och teknisk arkitektur diskuteras ofta inom systemutveckling, i vissa team dagligen. Är koden svår att förstå eller arkitekturen svåröverblickbar så blir jobbet som utvecklare snabbt ohållbart på grund av hög kognitiv belastning.

Jag har själv suttit som programmerare med en produkt som krävde att teamet behärskade tio olika programmeringsspråk - däribland Fortran 90! Produkten hade växt fram under 20-25 år och det saknades helt förståelse för problematiken kring åldrande system från produktchefen, som i slutändan bestämde över tiden.

Så är ofta fallet. Det är inte ovanligt att de som sitter på pengarna saknar förståelse för komplexitetsnivån i IT-system. Om produkten även innehåller en aldrig sinande mängd specialanpassningar till enskilda kunder - vilket också ofta är fallet - så blir det ytterligare ett lager komplexitet.

Produktdesign har flera dimensioner i sig - dels den tekniska designen, men också designen av själva erbjudandet. Är erbjudandet krångligt att förstå, med många specialanpassningar till enskilda kunder, så kommer den tekniska designen förmodligen också bli väldigt spretig och svårbegriplig. Speciellt över tid.

Visst ska man vara kundorienterad, men att gå efter devisen Kunden har alltid rätt kommer snabbt sätta dig i klistret. Kunden vill förmodligen ha en stabil och billig produkt. Då måste produkten vara enkel att underhålla, annars blir den snart både dyr och instabil. Där måste du som utvecklare och leverantör av produkten våga säga nej, när risken för komplexitet ökar mer än värdeökningen i affären. Här krävs därför en ständig dialog mellan säljare, produktansvariga och utvecklare.

Mitt teams produkt hade mängder av små specialanpassningar till olika kunder, som olika personer infört, med olika typer av tekniker genom åren. Det var ett mycket svåröverskådligt lapptäcke. Det enda som höll ihop systemet var gaffatejp och hög servicevilja hos utvecklarna. Men vi mådde inte speciellt bra.

Vi var väldigt stressade av komplexiteten i systemet och av frustrationen att inte få tid att göra något åt det. Det tog lång tid för nya personer att sätta sig in i produktens alla smådelar och hur de hängde ihop.

Det är faktiskt en ganska bra måttstock på hur hög komplexitet man dras med: Hur svårt är det för en ny person att förstå och bli självgående i sitt arbete?

Om man befinner sig i en bransch eller i ett bolag med hög personalomsättning eller som behöver växa snabbt bör man hålla noga koll på det här. Det kan bli väldigt kostsamt om upplärning av nyanställda tar för lång tid. Man riskerar dessutom att tappa folk snabbt igen, om det upplevs som att det inte är ordning på torpet.

Infrastruktur & Verktyg

Har du någon gång blivit tvungen att jobba med verktyg som är långsamma, svåra att begripa, eller som kräver tio klick för att göra väldigt enkla datainmatningar?

Verktygen vi använder ska underlätta för oss. De ska vara ett hjälpmedel, inte en källa till väntetider och frustration.

Här finns en intressant paradox inom systemutveckling. I många fall är man mer noga med vad man levererar ut mot kund än vad man levererar in mot sin egen personal. När kunder kommer med krav och önskemål ser man potentiella inkomster. När den egna personalen kommer med krav och önskemål ser man potentiella kostnader.

Jag raljerar lite, men det finns även sanning i det jag säger. När personalen beklagar sig över långsamma servrar eller otympliga verktyg vill man som beslutsfattare genast veta vad det kommer kosta att uppgradera servern eller byta verktyg? Ställer man den frågan måste man också ställa motfrågan: Vad kommer det kosta att inte uppgradera servern eller byta verktyg?

Det är ofta väldigt svårt att kvantifiera. Vad kostar en ökad kognitiv belastning? Vad kostar medarbetarnas frustration?

Man kommer naturligtvis aldrig kunna vara alla till lags, men många organisationer skulle tjäna mycket på att betrakta sina anställda mer som kunder när det gäller val av verktyg och underhåll av infrastruktur. Frustration och ökad kognitiv belastning på grund av struliga IT-miljöer är väldigt kostsamt!

Som ledare blir man ganska lätt lat i de här frågorna, eftersom man vet att personalen inte kan “gå till en konkurrent” om de inte är nöjda med verktygen. Förutom när personalen får nog, säger upp sig och bokstavligen går till en konkurrent.

Man blir även ganska lätt dumsnål på grund av budget-teknikaliteter. Vi ser inte besparingen i personalens tid i budgeten, däremot ser vi den ökade kostnaden för IT-system och verktyg. Så vi väljer att slösa med personalens tid istället för att lägga pengar på bättre IT-stöd.

Principen måste vara att det mest värdefulla man har är personalens tid och välmående. Kan man bespara personalen tid eller göra deras dag enklare, bör man definitivt överväga investeringen.

Sen finns det förstås begränsningar i hur långt man kan komma i realiteten. Men utan den principen som ledstjärna, kommer man med stor sannolikhet inte att komma någonstans.

Inflöde av arbetsuppgifter

Vänta nu, Marcus, du har redan pratat om Inflöde av arbetsuppgifter i avsnittet om press!

Ja, men inflöde av arbetsuppgifter påverkar faktiskt både upplevelsen av press och komplexitet. Om mängden arbetsuppgifter har ett oberäkneligt inflöde eller om det finns många källor där arbete “kan uppstå” ökar komplexiteten.

Inom systemutveckling skulle jag säga att det finns två huvudspår som ökar komplexiteten för arbetsinflödet.

Det ena är fel i IT-systemen. Det man inom lean kallar failure demand är en bra indikator på komplexitet som uppstår på grund av kvalitetsproblem. Failure demand är mängden arbete som uppstår av att vår produkt inte beter sig som förväntat eller inte uppfyller kundens krav. Till exempel om ett IT-system plötsligt går ner eller en programvara kraschar. Ofta finns det då krav på att felen ska åtgärdas inom en viss tid. Personen som ska fixa problemet får släppa det man håller på med och försöka lösa problemet.

Om man inte kontinuerligt tar sig tid att underhålla - och att underlätta underhåll - av sin produkt, kommer man ganska snart tappa styrsel och kontroll på läget. Man får en växande mängd arbete som bara handlar om att hålla gamla system uppe. Konsekvensen blir växande ledtider på nyutveckling.

Det andra spåret där oberäkneligt arbetsinflöde uppstår är när personer från verksamheten knallar rakt in på IT-avdelningen och direkt hugger folk. Frågar varför Arbetspaket X inte har blivit fixat ännu? Kan du inte fixa det nu med en gång? Det går ju snabbt?

Sånt här är väldigt kostsamt i form av avbrott och context switching för IT-teknikern eller programmeraren som i stunden förmodligen inte kan säga nej. Tyvärr brukar dessa personer från verksamheten se sig lite som "fixaren" - de som går in på IT och "får saker att hända". Att deras beteender orsakar total High Chaparral brukar inte bekomma dem.

Samma problem finner man ofta i så kallade kontaktyrken, alltså yrken med mycket kontakt med människor. Till exempel inom vård och omsorg där det när som helst kan uppstå krissituationer med patienter, samtidigt som man måste hantera en orolig eller förbannad anhörig.

Ett av de mest stressdrabbade yrkena vi har är kommunikatörer. Min fru jobbar som kommunikatör och jag kan se likheter med systemutveckling och förvaltning av IT-system när det gäller inflöde av arbete och struktur.

Det är otydlighet när saker är klart. Många deadlines att hålla koll på. Saker som kommer i retur med krav på revision lite hipp som happ. När som helst kan någon "fixare" knata in och kräva ens tid, tvinga en avbryta det man höll på med för att rätta en petitess på intranätet. “Det tar bara fem minuter!” Det är samtidigt många som tycker saker och dömer ens arbete, många kontaktytor, oberäknelighet i vardagen, samtidigt som den där deadlinen för när vi måste gå i tryck rusar allt närmare. Hur säger man då åt någon som “bara vill ha en enkel grej fixad” att de stör? Att man just satt djupt koncentrerad och att den koncentrationen nu är bruten? Risken är stor att man blir stämplad som sur, tvär och oresonlig.

Allt det där höjer den kognitiva belastningen genom ökad komplexitet i inflödet. Strukturering av arbete och kontroll på inflödet av arbetsuppgifter är bland det viktigaste man som ledare ska stötta sina anställda med.

Se till att en vettig process eller metod finns på plats. Se till att den efterlevs och respekteras.

Tröghet i systemet

Med tröghet i systemet menar jag sådant som strukturellt och organisatoriskt gör det svårare för mig att utföra och avsluta mitt arbete eller minskar min möjlighet att påverka min situation. Sådant som stjäl tid och uppmärksamhet eller gör mitt arbete krångligare utan att det tillför något egentligt värde i slutändan.

Tröghet i systemet brukar vara en starkt bidragande faktor till frustration.

Process

Inom det agila arbetssättet får processer nästan oförtjänt mycket skäll. Man pratar helst inte processer alls i det agila, man pratar metoder och “way of working”. Det är måhända min lean-hjärna som vill standardisera världen med processer för att kunna mäta, följa upp och hitta flaskhalsar. Vi bär alla på någon skevhet i vår verklighetssyn, det här är kanske min…

Nåväl, processer kan definitivt ha sin plats, kan jag tycka, så länge de används på rätt sätt.

Man bör alltid ställa sig frågan huruvida ens processer är utformade för att underlätta för övervakaren eller för utföraren? Jag tycker det allt som oftast är det förstnämnda som är fallet. Uppföljning är definitivt en viktig förmåga för organisationer att ha. Har man ingen uppföljning har man ingen koll på läget och heller inget underlag för åtgärder. Men som sagt, principen måste vara att det mest värdefulla man har är personalens tid och välmående.

Man måste ha enkla sätt att följa upp och processerna ska vara ett stöd för utförandet, inte övervakandet… Såvida övervakandet inte vinner prioritet över effektivitet. Det finns scenarion och verksamheter där fel absolut inte får slinka igenom eller begås på vägen. I det fallet bidrar processen till värde genom att vara långsam och rigorös.

Processer kan också vara en del i ens tekniska strategi för att till exempel förhindra att nya tekniker införs utan granskning och godkännande. Dels ur en säkerhetsaspekt, men också för att man inte ska hamna i samma läge som mitt gamla team, med tio olika programmeringsspråk att hålla koll på. Så processen kan också vara ett styrmedel för strategiarbetet - att säkerställa att vi rör oss i rätt riktning.

Men då är det ett medvetet val och något som vi måste påminna oss själva om. Man måste också göra en avvägning, för det man kompromissar bort kan vara organisationens initiativförmåga och innovationskraft. Ju hårdare du styr, desto mindre kommer du troligen se av initiativ och innovation.

Och kom ihåg vad Peter Drucker sa: What gets measured gets managed – even when it’s pointless to measure and manage it, and even if it harms the purpose of the organization to do so.

Du får vad du följer upp på.

Roller & Ägandeskap

Avsnittet borde egentligen heta Mandat & Ansvar, därför att för många roller och utspritt ägandeskap är ofta bidragande till komplexitet i beslutsvägarna. Vilken “roll” som “äger problemet” blir viktigare att utreda än hur fasiken vi tar oss framåt. Rollerna tenderar lätt att bli många och diffusa och att klistra sig fast på samma ansvarsfulla personer, som plötsligt ska hantera X på 20 %, Y på 30 % och Z på 5 % - utöver alla arbetsuppgifter hen hade sedan innan, så klart!

Roller brukar bara få ägandeskap för symptomen, men inte mandatet att lösa rotorsaken. Över tid tenderar symptomen att växa och bli värre eftersom grundproblemet inte adresseras. Situationen blir då allt mer svårhanterad för individen, som plötsligt lägger 30 % på X, 50 % på Y och 20 % på Z - utöver alla arbetsuppgifter hen hade sedan innan, så klart!

Än värre är att man som organisation får en vana att tillsätta roller för att hantera symptomen i stället för att ta tag i rotorsaken. Man övar sig inte på att bli bättre, utan på att gömma symptom.

Ska vi inte ha några roller då? Jo! Absolut! Men man ska vara sparsam med roller och fokusera på att minimera behovet. Man kan tycka att det blir tydligare vem som bestämmer och har ansvar om det finns en utpekad roll, men resultatet brukar efter ett tag bli att ingen längre minns vem som ansvarar för vad eftersom det finns för många roller att hålla koll på. Risken blir att ingen vågar ta initiativ eftersom ingen vet vem som är ansvarig. Alternativt tar folk initiativ de inte har mandat till och den som har ansvaret har ingen aning om vad som händer, för de får inte reda på det.

Jag vill inte gå så långt som att kalla roller “småpåvedömen”, men risken finns att de blir det. För när någon fått en roll känner sig den personen lätt hotad, eller att ens arbete inte är viktigt om rollen ifrågasätts, och går då i försvar. Roller är betydligt svårare att arbeta bort och bli av med än att tillsätta.

Om någon behövs permanent i en viss funktion, gör det till en befattning. En roll bör vara temporär och det bör ingå i rollen att aktivt arbeta för att den inte ska behövas längre.

I övrigt bör mandat och ansvar ligga så nära utförandet som möjligt. Annars blir systemet trögt och komplext.

Låg flödesoptimering

Organisationer som fokuserar mer på att dra igång nya saker än på att avsluta påbörjat arbete kommer ganska snart att ha en väldigt komplex värld att koordinera och jonglera. Det kan låta som en självklarhet att man inte kan eller bör starta upp mer arbete än man klarar av att avsluta, men i praktiken händer det hela tiden.

Låg flödesoptimering ger längre ledtider, vilket leder till mer konflikt i organisationen och ökade kostnader för allt påbörjat, men ännu icke avslutat arbete som bara ligger och ruttnar.

Har man inte förmågan att avsluta, kommer antalet parallella aktiviteter bli allt fler och svåröverskådliga. Då kanske man tillsätter ett par nya roller som ska koordinera allt man inte klarar av att avsluta. Fler roller, mer organisatorisk komplexitet. Det blir troligtvis också otydligt vad som har högst prioritet, när fler personer har som jobb att tjata på andra om att jobba på just den grejen som de har ansvar för att tjata om. Fast just den grejen kanske inte är det viktigaste just nu.

Till slut kommer organisationen att lägga allt mer tid och energi på att koordinera, men får inget gjort. Busy being busy, brukar man säga. Alla är stressade. Alla är upptagna. Men ingenting händer, för alla är upptagna med att vara upptagna.

Det har skrivits hela böcker om det här, så jag ska inte bli långrandig på ämnet.