
Rollfällan i teamdesign
När vi bygger produktteam utifrån roller i stället för den förmåga teamet behöver.
I en traditionell projekt- och linjeorganisation är arbetet ofta uppdelat efter specialistroller. Arkitekter ansvarar för arkitektur, utvecklare för utveckling och testare för testning. När ett projekt ska bemannas identifierar vi vilka roller som behövs och hur många personer som krävs inom varje område. Arbetet fördelas mellan specialisterna och lämnas vidare i takt med att olika delar blir färdiga.
Det är en naturlig logik när arbetet kan delas upp i aktiviteter som planeras och följs upp var för sig. Vi utvecklar djup kompetens inom respektive område och låter den som är bäst lämpad utföra uppgiften. Även ledarskapet utgår ofta från individen. Chefen sätter individuella prestationsmål, följer upp leveranser och ansvarar för medarbetarnas kompetensutveckling. Rollbeskrivningar, mål och uppföljning förstärker förväntningarna på vad var och en ska bidra med.
Men när vi går mot en produktorganisation behöver vi tänka annorlunda.
Vi vill bygga stabila, tvärfunktionella team som kan ta ansvar för en produkt och de effekter vi vill åstadkomma. I komplex produktutveckling vet vi inte på förhand vilka lösningar som kommer att fungera. Teamet behöver kunna utforska problem, prova idéer, fatta beslut och lära av resultatet. Därför behöver vi utgå från uppdraget när vi designar teamet. Vilka problem ska det kunna lösa? Vilka beslut behöver det kunna fatta? Vilken kompetens behöver finnas och vilken förmåga behöver teamet utveckla för att nå sina mål utan onödiga beroenden?
Men det är här vi riskerar att hamna i Rollfällan.
När vi skapar produktteam tar vi med oss rollerna från projektorganisationen. Vi försöker få med alla specialistroller som förekommer i utvecklingsprocessen, även om var och en bara bidrar med en liten del. Resultatet kan bli ett stort produktteam med många personer där alla roller finns representerade, men där förutsättningarna för gemensamt arbete är begränsade. Vi har bemannat alla roller, men inte nödvändigtvis byggt den förmåga teamet behöver.
När vi utgår från rollerna blir det också lätt att låta dem styra hur arbetet fördelas. Arkitekten ansvarar för arkitekturen, utvecklaren för utvecklingen och testaren för testningen. När utvecklaren är klar lämnas arbetet vidare till testaren. När en arkitekturfråga uppstår väntar teamet på arkitekten. Och när testaren har fullt upp fortsätter kanske andra med nya uppgifter i stället för att hjälpa till att få det pågående arbetet färdigt.
Vi har flyttat överlämningarna innanför teamets gränser, men inte fått bort dem.

Specialister blir flaskhalsar medan andra väntar eller påbörjar nytt arbete. Teamet blir sårbart när någon är frånvarande och kunskap koncentreras till enskilda personer. De individuella prestationsmålen kan dessutom förstärka problemet. Om utvecklaren bedöms utifrån sina leveranser och testaren utifrån sina tester blir det rationellt att prioritera de egna uppgifterna. Att hjälpa en kollega, lära sig något nytt eller lösa ett problem tillsammans kan då konkurrera med det individen förväntas prestera.
Vi vill att teamet ska ta gemensamt ansvar för resultatet, men fortsätter att styra och följa upp individuella prestationer.
Det betyder inte att specialistkompetensen ska försvinna. Tvärtom behöver vi djup kunskap inom olika områden. Men teamets förmåga är mer än summan av individernas specialistkunskaper. Inom LeSS används begreppet generalizing specialists för personer som behåller sin spetskompetens samtidigt som de breddar sin förmåga. Alla behöver inte kunna allt, men fler behöver kunna bidra inom olika områden så att teamet blir mindre beroende av enskilda personer. Genom multi-learning, där människor lär av och tillsammans med varandra över specialistgränserna, utvecklar teamet successivt sin gemensamma förmåga.
Det ställer också andra krav på ledarskapet. Prestationsmålen behöver vara gemensamma för teamet, medan individuella mål handlar om lärande och utveckling. De behöver ta hänsyn till både personliga ambitioner och den förmåga teamet behöver bygga. Ibland handlar det om att fördjupa en specialistkompetens, ibland om att bredda den. Lärandet behöver också vara en del av det dagliga arbetet.
Även chefens uppföljning behöver förändras. Om individuella 1:1-samtal fortsätter att handla om vad varje person levererar riskerar vi att återskapa individuell styrning vid sidan av teamets gemensamma ansvar. Chefen har fortfarande en viktig roll i att stödja individens utveckling, lärande och välmående, men behöver skilja på teamets prestation och individens utveckling.
Rollfällan uppstår när vi bygger produktteam utifrån traditionella specialistroller och fortsätter låta dessa styra hur arbetet fördelas, prestationer följs upp och kompetens utvecklas. Det är först när vi utgår från uppdraget och utvecklar förmågan att arbeta och lära tillsammans som vi börjar bygga ett verkligt tvärfunktionellt team.





