Hade jag arbetat i finansbranschen hade jag varit tvungen att lära mig det språk som används på den avdelningen jag jobbar på, även om jag arbetar med tech. Hade jag arbetat med lån hade jag lärt mig om olika typer av lån och deras användningsområden; hade jag arbetat med finansiering hade jag lärt mig om risker och modeller etc. Jag anser att det är min plikt att förstå vilka problem jag löser, för vem, och att jag arbetar med det som är relevant för företaget och den avdelning man råkar vara på.
Detsamma önskar jag skulle gälla för människor med icke-IT backgrund som arbetar på IT-avdelningar. Men på IT-avdelningar ska de med tech-bakgrund förklara mycket för icke-tech-människor, annars är det legio att bara dra sig ur konversationen med argumentet “låt dem snacka tech”. Jag skulle aldrig som IT-kunnig på en försäkrings-avdelning kunna hävda att: “låt dem snacka försäkringar” och ändå anses anpassad för mitt jobb. Men det går när man jobbar på en IT-avdelning.

Skapa en bas så skapar du förståelse

Om det inte är uppenbart för den som redan läst något på denna blogg, förespråkar jag kommunikation mellan roller och anser att förståelse mellan roller i sin domän skapar en gemensam bas för vidare diskussioner. Att ha ett möte kring något, är det för mig nödvändigt att se till att alla har samma bas och grundförståelse för mötets syfte innan man ens börjar mötet, annars kommer mötet komma av sig och syftet kommer att gå om intet. Ett bra exempel på en god idé men illa genomförd var när ett möte med 50 deltagare ordnades och mötesledaren sa: “Jag vill ha era förslag om hur vi kan förbättra område x”. Förslag och åsikter haglade om varannat men inget konstruktivt kom fram av mötet och en timme senare gick flera därifrån med tanken att man kunde gjort bättre av sitt liv.
Vad som hänt var att mötesledaren inte satt basen för mötet och inte förmedlat förståelsen mellan de olika roller som befann sig i mötet. Behoven från de olika rollerna förmedlades inte och på så sätt gav inte mötet det som ledaren hade för avsikt med.

Förstå kontextbytet för de i mötet

Att “tala tech” innebär för mig att den som lyssnar inte är införstådd i tekniken som diskuteras. Det händer mig dagligen att jag inte förstår vissa aspekter av tekniken och jag får be mina kollegor att uppdatera mig kring ämnet, problemställningen, begränsningarna och kunden/användaren. När många utvecklares främsta frågeställning är “hur implementerar jag denna teknik på bästa sätt” är det svårt att byta till ett möte som handlar om ex. Agila arbetssätt eller information om hur detta kvartal sett ut för företaget. Istället för att samla hela företaget och informera på ett generellt sätt skulle det vara bättre om man samlade roller från olika delar av företaget och sammanställde information relevant just för de specifika rollerna i mötet. Det kanske inte blir tidseffektivt, men jag tror informationen skulle bli mer relevant för deltagarna och transparensen i företaget bli tydligare.
Detsamma gäller de agila mötena som tenderar att bli rena pannkakan om man inte har en duktig agil coach. Med en sådan gäller inte bara en god förståelse för de agila principerna och metodiken utan också skiftet i fokus för teamet från att implementera en teknik till att förstå slutanvändarens behov och analysera vad som kan göras bättre för att möta dem. Utvecklarens primära mål är att implementera något tekniskt, men att i agila möten också ta ställning till varför de implementeras och för vilka. Om en bra agil coach kan hjälpa teamet med den förflyttningen varje gång ett agilt möte hålls, skulle mycket bättre resultat av mötet kunna nås.

Respektera rollerna

Bara för att du inte förstår tekniken eller annat specifikt för ett team betyder det inte att rollen eller personen är betydelselös. Ju mindre du respekterar rollen ju mindre sannolik är det att den personen som är rollen kommer att respektera dig. Och i förlängningen kommer personen inte att komma på dina möten även fast den är essentiell för ditt arbete/möte. Du har förlorat personens respekt och kommer ha väldigt lite inflytande på hur du påverkar andra team.