Släng titlarna

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Finns nu i bokform på Leanpub

Detta är den fjärde posten i en serie om agil HR “from the trenches”.

Del 1: Continuous investment
Del 2: Lägg ner utvecklingssamtalen
Del 3: Lön är rättvis ersättning – inte belöning
Del 4: Släng titlarna
Del 5: Ny kunskap – ett gemensamt ansvar, avsnitt 1
Del 6: Hitta rätt folk – släpp dem lös

Släng titlarna

Låt oss börja med två okontroversiella påståenden: Företag bygger på vertikala hierarkier och horisontell specialisering Ok?

Låt oss ta det en gång till.

Företag är hierarkier. Jag skriver här medvetet företag och inte organisationer i största allmänhet. Huruvida organisationer måste vara hierarkiska låter jag nämligen vara en öppen fråga, men företag är hierarkier, per definition.

Det finns förvisso många olika teorier om varför företag finns, men i princip alla går ut på att förklara varför människor som utför aktiviteter på en marknad “väljer” att karva ut en bit av denna ekonomiska aktivitet och där slopa marknadsmekanismerna.

Huruvida skälet till detta är att det minskar transaktionskostnaderna, eller att det löser problem med så kallade externa effekter (marknadsmisslyckanden), eller för att det ökar effektiviteten i hantering av olika egendomar, eller för att det ger makt att hantera ekonomiskt överskott, eller att det helt enkelt ligger i den mänskliga naturen att dominera andra, spelat för vårt resonemang här ingen roll.

Poängen är att kärnan i företag är att någon (företagaren) skriver långsiktiga kontrakt med en eller flera (anställda) som avsäger sig vissa av sina friheter för att i stället bli företagarens agenter. Som en av pristagarna till Sveriges Riksbanks pris i ekonomi till Alfred Nobels minne sammanfattar: Företagaren “försöker utforma avtal med agenterna som ska stimulera dem att öka hans vinst, och han kontrollerar deras prestationer”.

Eller som Henry Ford uttryckte det i lite mer klartext: “Jag tänker betala er tillräckligt mycket för att ni ska finna det värt att acceptera mina diktat i jobbet”.

(Att det finns alternativa sätt att använda de juridiska formerna för företag, vilket Crisp delvis är ett exempel på – är en annan och spännande fråga som jag lämnar vid sidan här.)

I de allra flesta företag är dessutom denna hierarki djupare än bara dessa två grundläggande nivåer. Genom företagen löper en kedja av delegerad auktoritet över företagets resurser (inklusive de anställda) i form av chefer och arbetsledare.

En hel del talar för att ett av de viktigaste skälen till att just organisera sig i en hierarkisk organisation som ett företag är att det gör det enklare och effektivare att integrera en grupp som utför olika arbetsmoment som i slutändan ska utgöra en helhet. Så har det inte alltid varit (och kanske är vi om igen på väg tillbaka till en sådan situation). Vapentillverkning i USA på 1800-talet var exempelvis organiserade i form av olika specialister som arbetade som fristående entreprenörer som utförde sin specialitet – så som att tälja gevärsstocken eller svarva pipan – och sedan lämnade vidare till nästa självständiga entreprenör (lite som utvecklare av öppen källkod arbetar).

Detta sätt att organisera arbete förmådde dock till slut inte konkurrera mot en massproduktion där horisontella specialiteter integrerades med hjälp av vertikala hierarkier.

Se där, det moderna företaget, med Max Webers ord för byråkratier, en järnbur av avtal som fixerar agenten vertikalt i hierarkin och horisontellt i en specialtet. Åtminstone är det lätt hänt att det blir resultatet av att organisera sig som företag.

Men hur fungerar det om man har ambitionen att inspireras av agila (eller andra) metoder som argumenterar för självorganisation? Fungerar det över huvud taget särskilt bra om man arbetare med komplexa produkter mot komplexa marknader?

Tveksamt.

Det finns en hel del erfarenheter och forskning som pekar rakt in i något av en paradox: vi har hierarkiska företag eftersom det är effektivare än att använda marknadsmekanismer för att koordinera en grupp människor under vissa omständigheter. Men hierarkier bär (förutom förlust av personlig autonomi) på sina egna inneboende effektivitetsproblem, som förvärras desto mer komplex och beroende av samverkande grupper verksamheten blir.

Ju mer komplex verksamheten är, desto svårare blir det för leviathan – som många teoretiker med hänvisning till Hobbes kallar den hierarkiska makten – att skapa incitaments- och kontrollsystem som verkligen fungerar.

Finns det något vi lärt oss från bland annat agil mjukvaruutveckling är det hur stort vårt behov av att lära oss och kunna ändra oss är när vi arbetar i komplexa system. Och hur viktigt det är att specialisering eller arbetsdelning inte ställer sig i vägen för fokus på det gemensamma målet eller uppgiften (arbetsdelning i silos skapar också köteoretiska problem som riskerar att leda till överproduktion, slöseri och långa ledtider).

Behovet av flexibilitet utmanar därmed det inre DNA:t i företag.

Eller låt oss i stället formulera det som en utmaning: hur kombinerar man hierarki och specialisering (som ju, för att repetera, är skälet till att vi är organiserade i företag) med behovet av lärande och gemensamt ansvar som vi också vet krävs när vi i stället för att producera en sak många gånger, ska producera många saker en gång?

Alla artiklar i denna serie handlar förstås i grunden om detta. Men här rör vi oss in mot mörkrets hjärta, där det antagligen blir verkligt utmanande, både för arbetsgivare och arbetstagare. Hierarkierna inne i företagen måste delvis monteras ner.

Alltså en gång till: om ditt företag är full av titlar, som formar arbetsuppgifterna i företaget och utgör vägarna för avancemang eller karriär, lägg ner. Risken är nämligen stor att de utgör en osynlig järnbur som direkt hindrar eller åtminstone försinkar möjligheterna att prova sig fram, att experimentera och anpassa sig. Och därmed i slutändan hindrar det som var ursprunget till företaget: ett effektivare sätt att organisera arbete än andra alternativ.

Jag tar det en gång till: skilj kontrakten från arbetsuppgiften. Läbbigt va?

Det här kräver förstås en hög grad av förtroende från bägge sidor. Som arbetsgivare måste man uttrycka och bevisa sitt förtroende för att alla gör sitt bästa. Som anställd måste man lita på att arbetsgivaren inte utnyttjar de öppna kontrakten på ett för den anställde negativt sätt, exempelvis genom att tvingas ta arbetsuppgifter långt utanför professionen eller otydlig löneutveckling. Kan man inte skapa dessa förtroenden kan man heller inte ersätta de stelbenta hierarkierna (och därmed – om jag och andra har rätt – kommer man stå och stampa med en lägre effektivitet än vad som är möjligt). Det finns till och med de som menar att ledarskap i moderna företag därmed mer liknar politik än klassisk fordism (militärt).

Vad ska vi ha i stället?

Jag kan villigt erkänna att det företag där jag hämtat den mesta av erfarenhet ifrån för denna artikelserie redan från början var både väldigt platt och med låg formell specialisering. Men över tid, med växande mängd anställda och med växande antal år på företaget, lockade ändå sirenernas sång: nya arbetsuppgifter krävde väl ändå nya titlar? Och därmed skapade man ju också bra karriärvägar: Produktägare, ScrumMaster, Arkitekt, Team Lead.

Jag hade inte tänkt igenom det här särskilt mycket när jag började som chef. Som tur var, vågar jag säga, hade en position som chefsarkitekt nyligen uppstått och den innehades av en god vän till mig. Jag tror vi höll på i över ett år och kämpade med konsekvenserna av hur denna position skulle förenas med vårt nya agila arbetssätt med självorganiserande team med eget ansvar för hur saker och ting skulle göras.

Vilken auktoritet skulle chefsarkitekten ha? Hur skulle denne interagera med teamen? Till slut lade vi ner idén att denna position innebar formella rättigheter eller skyldigheter och i stället gick personen in i ett team och verkade som han alltid hade gjort, som en senior utvecklare med ytterst stort förtroende bland alla och som därigenom hade ett avgörande inflytande på arkitekturbeslut i vardagen.

Om det här inte varit en väldigt informell miljö tror jag effekterna av utnämningen och positionen hade varit mycket svårare att hantera.

För att underlätta dessa typer av förändringar i framtiden började vi i stället tala om olika roller. Vad en roll var kan man inte säga var tydligt definerad. Men i huvudsak gick tanken så här: när vi arbetar tillsammans och provar olika sätt att organisera vårt arbete uppstår eller behövs olika funktioner. Som anställd ska det vara möjligt att ta på sig en eller flera sådan roller efter eget intresse. Det ska vara lätt att prova om man trivs i en roll och också kliva ur en roll utan att det upplevs av andra som en stor sak. Dessa funktioner ändras förstås över tid. Vi vill då inte att vi tvingas upprätthålla en viss organisation, eller för den delen hitta på ersättningspositioner, bara för att dessa roller råkade vara knutna till organisatoriska positioner eller titlar.

Ta till exempel rollen ScrumMaster. När vi mer seriöst ville basera vårt sätt att arbeta på agila principer började vi med Scrum och tog – som man bör tycker jag – hela paketet. Under flera år hade vi med andra ord Scrum Masters i teamen. Men vi gjorde det aldrig till en titel eller position.

Den omedelbara effekten blev att flera olika personer kunde prova om det trivdes och fungerade som ScrumMaster utan allt för stor dramatik. Med tiden började rollen dock både urholkas och stå i vägen för att ta agile och Scrum till nästa nivå. Varför skulle ett självorganiserande team ha en ScrumMaster? Det hade ju alla möjligheter att tillsammans ta ansvar för allt som behövdes för att utföra ett gott jobb. Boka backloggrooming? Hålla retrospektiver? Skriva stories? ScrumMaster eller någon annan? I ett självorganiserande team blir det till slut konstigt att någon har en roll som är utpekad från någon utanför teamet. “Take it to the team”, som någon känd agil coach uttryckt det.

Tack vare att vi redan talade om dessa olika funktioner som roller var det inte hela världen att lägga ner detta med ScrumMaster. Som en följd av det gjordes rollbegreppet delvis ännu mer dynamiskt. Vem eller vilken i teamet som tog på sig olika uppgifter som teamet och företaget i övrigt behövde blev en fråga som teamet och dess medlemmar fick sköta själva.

Vi ville således undvika att frysa ner en viss organisatoriskt matris i tron att den skulle vara framgångsrik i all framtid. Jag tycker att detta sätt att se på organisation fungerade utmärkt och den satte också avtryck i hur vi behandlade lönesättning. Möjligheten och lusten att ta sig an en eller flera roller skulle avspeglades i lönekuvertet, oberoende av om man just nu hade en roll eller om den ens var uttalad. Att vara den som skapar glädje i ett team till exempel eller den som alltid kollar av nattens tester är också roller som har ett stort värde.

En viktig sida av att arbeta med roller i stället för titlar och positioner är frågan om hur personalansvar ska hanteras. Hierarki i ett företag handlar ju i grunden om detta, det är ett delegerat ansvar för “kontraktet”. Vad som antagligen är självklart utifrån det jag skrivit ovan är att så fort en roll kopplas till personalansvar blir den rollen en position i hierarkin, och därmed är det inte längre en enbart roll enligt försöket till definition ovan.

När bör en roll i själva verket också innehålla personalansvar? På det tror jag inte det finns något svar som passar alla. Det man efter ett tag kommer underfund med när man arbetar med självorganiserande team och dynamiska roller är dock detta: mycket att det som (ofta av slentrian) hamnar på den som har personalansvar kan i själva verket utföras lika bra eller till och med bättre av andra.

Mitt personliga svar blir därför detta: börja med att avlänka så många roller som möjligt från den som bär personalansvar och se vad som händer. Här är en rad aktiviteter som jag av egen erfarenhet vet fungerar eller bör fungera som separata roller:

  • Ansvar för vad som bör arbetas med, till exempel produktägare
  • Ansvar för hur saker bör göras, exempelvis team
  • Ansvar för att stödja och lära ut hur man arbetar bättre tillsammans, exempelvis coaching
  • Ansvar för arkitektur, exempelvis ett arkitektforum
  • Ansvar för kompetensutveckling, exempelvis en skråmästare

Listan kan göras betydligt längre och det finns säkert också många situationer där en eller flera av dessa roller passar bra att förena med personalansvar. Jag betraktar det dock som empiriska problem: poängen här är egentligen bara denna. Om det är ett empiriskt problem, låt bli att låsa fast en viss lösning genom att göra den till en del av den hierarkiska kärna.

Kort sagt: gör den hierarkiska kärnan i företaget så liten som möjligt genom att använda roller i stället.

Var det allt?

Nja, jag har ju nästan inte skrivit något om den horisontala dimensionen, om specialisering I någon mån kan man säga att vissa av våra roller handlade om denna dimension, men vi hade heller inte så väldigt stort behov av att arbeta specifikt med specialisering, i huvudsak räckte det med att vi hade världens vassaste utvecklare och att dessa odlade sina egna intressesfärer.

Det råder emellertid knappast något tvivel om att specialisering är en viktig egenskap i företag och när en som jag numera möter tämligen stora organisationer (upp till några tusen personer som ska utveckla saker tillsammans) framstår specialiseringen som både nödvändig för företags effektivitet, men också som ett svårt hinder.

Det är ett svårt hinder eftersom det är ytterst svårt att hitta en bra avvägning mellan att odla specialisering och att arbeta i korsfunktionella leveranser. Antingen riskerar man för lite fokus på specialistkompetens eller för hård sektionsindelning och onödiga överlämningar.

Jag är övertygad om att specialisering behöver hanteras också som en (eller flera) roller man bär på i ett företaget, men att det också kräver ytterligare stöd eller organisatoriska former som är kopplade till professionell identitet och kompetens. Jag återkommer till det i ett senare inlägg.

5 Comments

  • 1
    2013-02-22 - 18:40 | Permalink

    […] ner utvecklingssamtalen Del 3: Lön är rättvis ersättning – inte belöning Del 4: Släng titlarna Del 5: Kompetens – ditt ansvar Del 6: Hitta rätt folk – släpp dem […]

  • 2
    2013-02-22 - 18:42 | Permalink

    […] 2: Lägg ner utvecklingssamtalen Del 3: Lön är rättvis ersättning – inte belöning Del 4: Släng titlarna Del 5: Kompetens – ditt ansvar Del 6: Hitta rätt folk – släpp dem […]

  • 3
    2013-02-22 - 18:42 | Permalink

    […] 2: Lägg ner utvecklingssamtalen Del 3: Lön är rättvis ersättning – inte belöning Del 4: Släng titlarna Del 5: Kompetens – ditt ansvar Del 6: Hitta rätt folk – släpp dem lös Del 7: Kontor […]

  • 4
    2013-05-30 - 02:04 | Permalink

    Som entreprenör är jakten på titlar för mig något som är helt obegripligt, men samtidigt så är en “ny” titel eller att man blir “headhuntad” ett sätt att visa för andra hur ypperlig man är som yrkesmänniska. Den nya titeln blir som semesterbilder och nyförvärv är på Facebook – ett sätt att visa upp sig. Man kan ju ogärna posta hur mycket man tjänar.

    I mitt lilla konsultbolag så hade jag gärna avskaffat titlar, men det blir genast så mycket svårare att rekrytera. Jag har kunder som har gjort ändringar i de anställdas titlar och de upplevde att de blev “degraderade”. Men vad är vitsen med att det står CIO (=it chef) på visitkortet om du enbart har hand om en webserver och mailserver, båda driftas av ett extern företag (=inget personal ansvar)?

    Om ett jobb innebär mindre ansvar men en ansvarsfull titel så är det lättare att fylla den rollen än tvärtom är min gissning och erfarenhet hittills. Har det gjorts några studier där?

  • 5
    2013-05-30 - 08:00 | Permalink

    Just denna degraderingsrädsla och koppling karriär-titel-lön gör det svårt att experimentera fram det bästa sättet att jobba och att över tid snabbt ändra sig när man lär sig nytt eller omgivningen förändras. Förändringsvilja kräver trygghet. Kanske känner vi oss otrygga på våra arbetsplatser? Möjligen är det då det som måste förändras först.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *