Skal jeg ansætte flere for at øge produktiviteten?
Kære brevkasse,
Jeg har et problem med et team i min startup. Planen var at de skulle eksekvere her i Q1, for jeg har lovet en række features til vores investors, men det går alt for langsomt med udviklingen, så vores KPI’s er helt ad helvede til. Jeg snakkede lige med vores CTO, som er en makker, jeg gik i gym med. Han foreslår at hyre flere udviklere til teamet for at få produktiviteten op.
Er det pengene værd? I så fald har vi ikke råd til vores nye FIFA-hjørne.
Vh. CEO, hvid mand, 36 år, KBH“
Kære CEO, hvid mand, 36 år, KBH
først og fremmest tak for dit brev.
Det gode er, at du ikke er endt med en unik problemstilling. Jeg har set dette problem næsten alle steder, jeg har arbejdet.
Men før vi kan komme frem til, hvad du skal gøre, er vi nødt til at forstå, hvad produktivitet er, og hvad et sundt team er. Og særligt hvordan de to ting hænger sammen. Det gør vi ved hjælp af Tuckman’s teamstadier og Will Larson’s teamstadier.
Tuckman’s stadier
Tuckman har defineret fire stadier et team kan være i:
Forming
Storming
Norming
Performing
Forming er det indledende stadie i teamet. Det er her, at de lærer om de muligheder og udfordringer teamet har, før de så enes om et mål at arbejde hen mod.
I dette stadie er folk i teamet typisk meget selvstændige og samarbejder sjældent.
Storming er når konflikter blandt deres måder at arbejde på opstår. Dennis foretrækker at arbejde asynkront, mens Jens og Thomas gerne vil programmere sammen via Zoom i timevis.
Norming er det stadie, hvor I endelig har løst jeres konflikter og nu kan værdsætte hinandens styrker. I begynder måske endda at dokumentere, hvordan I gerne vil samarbejde.
Performing er målet for ethvert team. Her arbejder alle sammen uden gnidninger mod det samme mål.
Hvad mange misforstår ved denne model er, at man ikke forbliver i performing for altid. Faktisk er det sjældent, jeg overhovedet ser teams prøve at være i den kategori. For ligeså snart der sker en ændring med teamet, kan I blive skubbet tilbage til et af de andre stadier igen.
Lad os sige dit team nu er i norming-stadiet. De har arbejdet sammen i et godt stykke tid, kender hinanden og sætter pris på deres manager. Men problemet er bare, at de ikke er produktive nok.
At tilføje nye medlemmer til teamet vil næsten uden undtagelse sætte dem tilbage til storming eller forming. Det betyder en stærk tilbagegang i produktiviteten i en kortere periode.
Så nu ved du, hvor dit team er. Men hvad kan du så gøre?
Will Larson’s stadier
Will Larson’s Four Stages of a Team beskriver fire teamstadier, der fungerer enormt godt sammen med Tuckman’s.
Bagud: Hvis et team er bagud kan du tilføje flere til teamet.
Stagnering: Hvis et team stagnerer kan du reducere /work in progress/ for at skabe rum til langsigtede forbedringer.
Betaler gæld: Hvis et team allerede laver langsigtede forbedringer, kan du øge den tilgængelige tid, så de kan fjerne al teknisk gæld.
Innovation: Hvis et team innoverer kan du give dem mere /slack/, så de kan få plads til at gøre det, der er bedst til.
Så nu kan vi placere dit team i vores matrix og forstå, hvor de er:
De er et team i norming-stadiet, der stagnerer.
I så fald tyder meget på, at du skal give dem plads til at arbejde. Du skal fjerne projekter fra dem og lade dem fokusere på det, der er allervigtigst.
Men hvis du alligevel lytter til din makker fra gym og ansætter flere, så er du også nødt til at forstå de konsekvenser det kan have for din organisation:
Hvis en manager har mere end otte udviklere, der rapporterer til sig, er du nødt til at ansætte endnu en manager til at aflaste.
For hver 10. udvikler (cirka) er du nødt til at oprette et nyt team, de kan arbejde i. Og det kræver meget mere koordination blandt de andre teams.
For hver ny udvikler du ansætter, kommer der flere daglige commits, deployments og stress på dit udviklingsmiljø. Siden de fleste incidents er skabt af deployments, så skal du også være forberedt på mere nedetid.
Så hvis du alligevel ansætter udviklere, skal du have råd til at tænke langsigtet og give dit team og din organisation plads til at kunne forholde sig til de ændringer.
Hvis du ikke har råd til en tilbagegang, så vil jeg ikke anbefale at ansætte flere i teamet lige nu. I stedet bør du reducere mængden af deres projekter. Og så skal du nok genoverveje, om du bør love features til investors uden at snakke med dem, der kan bygge dem først.