Empati, en av våre fem personlighetstrekk, er kanskje en av de viktigste når mange skal jobbe sammen. Men likevel er denne egenskapen lite kultivert i mange virksomheter, og kanskje fryktet. Jeg husker fortsatt det kleine øyeblikket mellom en rekrutterer og meg, da jeg felte en tåre i et intervju til en lederstilling. Det skjedde av seg selv når jeg kom inn på historien om en kollega som brått døde på arbeidsplassen. Svaret fra intervjuet var som forventet: “Denne virksomheten skal igjennom en stor endring, og vi trenger en leder som kan ta de nødvendige grep på tross av dagens ansatte.”
Empati er for meg ikke skremmende, men en nødvendighet skal man bygge gode produkter via engasjerte ansatte. Nå skal vi ikke forlange at alle ansatte har like mye av dette personlighetstrekket, men i noen roller er det viktigere enn andre. Empatiske produkteiere som forstår sine kunder og teamkamerater bør være attraktivt for rekrutterere.
Siden menneskene formet sine første stammer, har vi alltid jobbet sammen. Det å føle seg som en del av noe større, jobbe skulder til skulder med kollegaer og få suksess, er gjengangeren når mennesker snakker om sine beste jobberfaringer. Men til tross for at vi alle har dette grunnleggende ønsket om tilhørighet, så har mange arbeidsplasser satt det motsatte i system: Vi setter krav til andre rundt oss, jobber ofte alene og prater ikke med mennesker i andre avdelinger.
Det å sette krav har blitt sett på som profesjonalitet. Faktisk er konseptet så etablert at arbeidsgiverorganisasjonen Abelia mener at dette er løsningen for offentlige virksomheter. De fleste virksomheter jeg har hjulpet har hatt en bestillerfunksjon som sender sine krav over til IT. Bestilleren kan ha tittel som forretningsutvikler, produktsjef, produkteier, prosjektleder eller redaktør.
Jobber du i miljø som har satt bestillinger og krav i system, så er min erfaring at dere har lav teknisk kvalitet og mange feil. Kravstillingen fører til lite forståelse på tvers av funksjoner og ansatte med lite energi som gjør det de får beskjed om. Dessverre er det slik at mange ved overgang til smidig, tar med seg sin bestillermodell inn i det tverrfaglige samarbeidet. Dere vil ikke komme videre i etableringen av smidig før dere klarer å gjøre produkteieren til en fullverdig del av teamet.
Dersom du er produkteier, er du en bestiller eller en teamdeltager? Kjenner du teamdeltagerne? Vet du hva som engasjerer dem? Er du selv engasjert i teamets oppgaver? Gleder du deg til backlog grooming møtet? Er du mer engasjert i oppgaver på utsiden av teamet?
Tradisjonelt så hviler det et stort ansvar på produkteieren. Han skal stå for en engasjerende hensikt og utforme brukerhistorier som løser kundens smerte. Dette er veldig vanskelig. Det er derfor vi trenger å bruke hele teamet til å jobbe med en produkteiers utfordring.
Produkteierskap er ikke en persons ansvar, men et teams ansvar.
Som produkteier kan du derfor ta to valg: 1) Bli en ekte del av teamet og starte med ærlig kommunikasjon eller 2) Si til teamet at du ikke er motivert nok til oppgaven, og be noen andre ta rollen som produkteier.
Velger du strategi 2) så kan du bli en av sikkert mange viktige interessenter som teamet tar hensyn til, men du erkjenner at du ikke har tid eller lyst til å jobbe mer som produkteier. Da holder du ikke teamet som gissel, og du lar noen andre få mulighet til å ta ansvar.
Velger du strategi 1) så starter du i morgen med å invitere teamet inn i ditt arbeid. Spør teamet om du lager engasjerende brukerhistorier, og forklar teamet om hva du synes er vanskelig. Prøv å finne ut om det som er utviklet fram til nå har gitt dere flere engasjerte brukere, eller om det motsatte har skjedd. Teamet er dine kollegaer, ikke noen du kan styre og kontrollere som du selv ønsker. Produkteierskap er et ansvar, ikke en rettighet.
Hva skal teamet gjøre?
Det er lett for et team å klandre en autoritær eller fraværende produkteier for deres manglende framdrift. Det løser ingen problemer.
Sett deg derfor ned med ditt team i dag, og still spørsmålene:
For å lykkes med en bedre dialog mellom produkteier og teamet, så har jeg sett en effektiv løsning; full transparens på teamets utfordringer. Overvåkning av teknisk gjeld, kompleksitet, advarsler og driftsfeil kan derfor være meget viktig skal dere vise ikke tekniske ressurser at det lønner seg å levere god kvalitet. Hver gang dere møter tekniske problemer, lag en brukerhistorie av dem og send dem til produkteieren. Ved driftsproblemer, lag en brukerhistorie på hva som kan stoppe slike feil for framtiden og send dem til produkteieren. Jobber du med rutineoppgaver, lag en historie om automatisering og send den til produkteieren.
Konklusjon
Det er lett å klandre andre mennesker for å være inkompetente når de ikke gjør det du hadde forventet, men vit at det fører deg ingen steder enn inn i bitterhetens kaotiske og selvdestruktive tilstand. Isteden for å klandre enkeltpersoner, forstå at i komplekse systemer tar ulike personer beslutninger fra ulike ståsted. Det som virker som idioti for deg, kan være fornuftig for en annen.
Løsningen er meget enkel: Prat sammen, jobb sammen, forstå hverandre. Still spørsmål, vær nysgjerrig. Be om hjelp, hjelp andre. Samarbeid på tvers av fagområder kan være vanskelig, men bruk kunden og dens behov som en rød tråd i dialogen. Dersom du står alene i dag, finn allierte på tvers av fagområder, og vit at 8 personer som står sammen er mye sterkere enn en stemme. Men bruk faktiske utfordringer, og gå til bunns i disse. Hvorfor dukket de opp, og hvordan burde dere ha løst dem? Da kan dere forandre systemet, en problemstilling om gangen.
------------------------------
Produkteiers viktigste verktøy: Empati was originally published in
Coworkforce on Medium, where people are continuing the conversation by
highlighting and responding to this story.
