Den senaste tiden har jag försökt mig på att vara mer än bara Platform Engineer utan försökt att forma Platform team på mina senaste två arbeten. Bägge fallerade av olika anledningar och jag har kommit ur dessa erfarenheter med några insikter.

Fråga er varför teamet behövs

De team jag varit med om har antingen formats som ett svar från ledningen att det ska passa organisationen eller kretsa kring en teknologi och bägge är fel enligt min mening. I de två senaste teamen var tanken att teamet dels skulle bli mer Platform Engineering, dvs fokusera på tjänster, och det andra att teamet skulle kretsa kring DevOps. I scenario ett hade teamet framförallt att alldeles för stort scope i sig och detsamma gällde team två. Jämfört med vanliga utvecklingsteam så har ofta Platform Engineering-team ansvar för ett flertal interna tjänster som gått omärkt förbi under flera år eftersom inga kunder anmärkt på dem. De har mest varit interna utvecklares huvudvärk och de är ju inte några inkomster för företaget, alltså inget att bry sig om. När man skapar ett team är det viktigt att sätta gränserna för vad teamet levererar och vilka dess intressenter är. Innan man gjort det kommer man troligen inte kunna skapa ett sammanhang där ett team kan florera.

Låt teamet få vara utan ledning

I Scenario två ställdes det nya teamet under den befintliga chefen/managern som redan hade en tanke om vad individerna i teamet skulle göra och vad de skulle leverera. Detta hindrade teamet från att själva sätta sin kultur och fokus utan påtvingades något från en chef som inte hade insikt i vad teamet skulle göra. Detta ledde till missförstånd och orimliga förväntningar där roller från chefens tidigare team direktöversattes till det nya teamet.

Om teamet är nyformat är det ingen som är i behov av deras tjänster än utan de kan få tid att bestämma sin egen struktur och vad de ska leverera och rapportera. Det blir bara krångligt om en befintlig chef som har ett annat team återinför samma regler för det nya teamet. Det finns dessutom ingen “chef”-roll i ett agilt team utan roller för att teamet ska kunna leverera. Chefen finns bara där för att utanför det agila teamet kunna rapportera emot sina chefer. Oftast mår ett team bättre ju mindre chefen tar beslut eller lägger sig i teamets förehavanden.

Definiera teamets interface

Teamet bör i dagens mening leverera tjänster och inte verktyg. De ska leverera värden till stakeholders, inte bara implementation av en funktionalitet i ett verktyg. Verktygen och teknologierna är hjälpmedel som används för att leverera tjänsterna. Om tjänsterna kan sammanfattas och vilka som är beroende av dem blir det tydligare vilka som är beroende av teamet och hur mycket de bör sammansättas. Om ett tidigare team har haft problem med system eller annat som det nya teamet ska fixa är det inte funktionaliteten som är det väsentliga utan vilka tjänster som levererats. Det första teamet bryr sig inte om tekniken byts ut så länge som tjänsten finns kvar.

Till slut beror det på cheferna och hur villiga de är på att lyssna istället för att “ta beslut”. Jag tycker att beslutstagande är det mest illa definierade mätvärdet i dagens arbetsliv. Jag tycker att beslut ska tas och följas upp av de som innehar den tekniska kompetensen och de som förstår användarperspektivet och det är sällan cheferna. Ett nytt team eller ett befintligt team behöver ständigt utvärdera sitt syfte och det sätt de uppfyller syftet på. Inget team är beständigt eller har ett självvärde och det gäller även chefer. När ett team omstruktureras ska även chefer göra det, men det är en annan blogg.