Sådan bygger du en software-ingeniørkultur, hvor alle kan trives

Medierne elsker at fortælle krigshistorier om sexisme, racisme og andre former for fordomme i tech-verdenen. Selv om det at kaste lys over systemiske problemer er god journalistik, for folk, der er interesseret i teknisk karriere, kan det at læse historie efter historie om kulturproblemerne i tech i bedste fald føles som den velkendte brodder om stereotyp trussel og i værste fald som en truende professionel ansvarsfølelse. Men den gode nyhed er, at kulturen i tech-industrien ikke er iboende dårlig - nogle af dem er store, og det er både muligt og ligetil at skabe en software-engineering-kultur, hvor alle kan trives.

Dårlig software-ingeniørkultur er ineffektiv - ud over at skubbe de 75% af mennesker ud, der nogensinde ikke kunne passe til techbro-stereotypen, hvilket gør industrien kunstigt mindre konkurrencedygtig - er en dårlig software-ingeniørkultur ofte en kultur, hvor kun et par dominerende ingeniører er faktisk produktive, mens resten føler sig forvirrede eller minimeret, og en kultur, hvor enorme teams kan tilbringe år og millioner af dollars ved et uheld at løse de forkerte problemer eller opbygge de forkerte produkter. Det mere synlige problem med en fjendtlig arbejdsplads er bare let at måle bevis for de co-morbide problemer med dårlig organisationskultur og organisatorisk ineffektivitet.

Heldigvis er arbejdspladsskulturen meget formbar, og du kan påvirke den på store og små måder. Hvis du finder måder at forbedre softwareteknologi på dit arbejdssted, er chancerne for, at du ikke bare forbedrer miljøet for dig selv, forbedrer du det for alle. Og som et resultat vil alle ikke kun være gladere, men også mere produktive.

Teknisk ved MoveOn kræver organisering i skala. Det arbejde, vi udfører, er vigtigt, og hvordan vi udfører dette arbejde er lige så vigtigt. Mit tech-team bygger ikke kun værktøjer til at mobilisere millioner af amerikanere, forstærke folkets magt og holde vores regering ansvarlige, men vi gør dette med et team, der er ansat via retfærdige ansættelsesprocesser, og vi konstant reviderer og forbedrer vores software-engineering praksis og processer for at sikre, at alle på holdet har en stemme, og at alle er klar til succes. Dette er svært arbejde, der er absolut værd, og når vi får vores teamprocesser rigtige, høster vi enorme belønninger, da vi effektivt og ubetinget bygger den rigtige teknologi til det rigtige tidspunkt, skalerer vores systemer og processer og arbejder sammen med resten af organisationen som tekniske tankepartnere. Vi afviser tanken om, at de nuværende teknologiske stereotyper og kulturelle forventninger er uundgåelige, og at vi er et bedre hold som et resultat.

Så hvordan bygger du faktisk en god softwareteknologi-kultur?

Business Cat er ikke en god software engineering manager

Nøgleingredienser i en god kultur

Ligelig og effektiv softwareteamkultur tager højde for sammensætningen af ​​dit team, operationaliserer processer og gør normer eksplicit, sætter alle teammedlemmer op til succes og holder teamet ansvarligt over for dets erklærede mål.

Her er fem nøgleværdier for at få dette til at ske:

  1. Anerkend holdets mangfoldighed af oplevelser
  2. Angiv tydeligt kommunikations- og samarbejdsnormer
  3. Opret sikre rum til at lære og stille spørgsmål
  4. Omhyggeligt ombord alle teammedlemmer til nye projekter
  5. Opret en kultur med ansvarlighed

Enhver kombination af processer, der implementerer disse værdier, fungerer sandsynligvis for dit team, men ikke alle strategier er den rigtige pasform for hvert team og ethvert projekt og enhver organisatorisk kontekst, så det er vigtigt både at prøve forskellige strategier og også regelmæssigt debrief med dit team om hvad der fungerer og ikke fungerer. Lad teammedlemmer forhandle om procesændringer og forblive fleksible.

Derefter opdeler vi, hvad hver værdi virkelig betyder, og jeg vil dele en prøve af strategier, jeg har brugt til at implementere hver værdi.

Anerkend holdets mangfoldighed af oplevelser

De fleste softwaretekniske miljøer vil omfatte personer med forskellige oplevelsesniveauer, og erfaringerne vil variere på tværs af mange dimensioner: faktisk mængde af tidsbrug, kodning, års erfaring på et bestemt sprog eller ramme, erfaring med en bestemt virksomheds størrelse, type og branche. Hvert sprog, ramme, platform, branche har et sæt forventninger til, hvad rækkefølgen af ​​operationer for et projekt skal være, hvilke problemer der skal være let kontra hårdt, hvilke arkitektoniske mønstre betragtes som standard, og hvilke normer der findes omkring dokumentation, debugging, og implementering. Hver enkelt forskel her betyder noget, og skal overvejes, når man fastlægger kommunikations- og samarbejdsnormer. Udpakning af hvert teammedlems oplevelse og antagelser vil gøre beslutningstagningen klarere og vil glatte over eventuelle misforståelser.

https://xkcd.com/1831/

Strategier til anerkendelse af dit teams mangfoldighed af oplevelser:

  • Team tilbagetrækninger: Når dit teams sammensætning ændres, er det nyttigt at skildre en dag eller to for alle at møde hinanden, dele erfaringer og nulstille normer
  • Team Constitution: lav et sæt værdier og normer sammen, som du ratificerer som dit teams forfatning. Det er nyttigt at holde sproget direkte, holde listen kort og holde sig fokuseret på værdier kontra specifikke projekter. Bed hvert teammedlem om at dele historier om, hvorfor hver værdi er vigtig baseret på deres oplevelse.
  • Faciliterede muligheder for at dele erfaringer: du kan gøre dette som en del af et team tilbagetog eller et regelmæssigt teambuilding-møde. Spørgsmålet betyder ikke så meget som lettelsen. Facilitering er nøglen, så alle (både introverte og ekstroverte, både junior- og senioringeniører) har en chance for at tale og blive hørt. Nogle eksempler på spørgsmål, som jeg har fundet være generative: ”Hvad var den sværeste projektlancering, du nogensinde var en del af?” ”Hvad var de bedste og værste ledelseserfaringer, du nogensinde har haft?” Facilitøren skal opfordre alle i møde og give dem det samme antal minutter at tale og besvare spørgsmål om deres oplevelse.
  • Pak pakker med estimering af software estimering: Dit team vil uundgåeligt komme i diskussioner om, hvor lang tid en opgave vil tage, og vil nogle gange være uenig. Når dette sker, er det nyttigt at udpakke antagelser om, hvilke dele af opgaven eller problemet antages at være komplekse, hvorfor og hvilken fortidserfaring dette er baseret på.
  • Læringsplaner for softwareteknik: opret en læringsplan for softwareingeniører, der ønsker at udvide deres softwaretekniske færdigheder på en understøttet og struktureret måde.

Angiv tydeligt kommunikations- og samarbejdsnormer

Skriv ned og accepterer formelt, hvordan teammedlemmer vil arbejde sammen om et projekt, hvordan opgaver skal styres, og hvordan færdigt arbejde godkendes og indarbejdes. Hvis du ikke eksplicit angiver disse normer, udvikler dit team og dit projekt alligevel normer, men disse implicitte normer fungerer muligvis for nogle ingeniører og ikke andre, og normerne er muligvis mere klare og tilgængelige for dem, der identificerer som din organisations dominerende kultur , og mere forvirrende for dem, der ikke gør det. Det er bedre at bare være eksplicit.

Strategier til indstilling af kommunikations- og samarbejdsnormer:

  • Projekt kickoff-møder: Teamkonstitutioner hjælper hold med at beslutte, hvordan de skal arbejde sammen generelt, men det er også nyttigt at have projekt-kickoff-møder, hvor hold beslutter, hvordan de skal samarbejde om dette specifikke projekt. Dette skal dække, hvordan opgaver styres, hvordan opgaver vil blive bestilt, hvem der samler op, hvilke slags opgaver, hvordan og hvornår man skal bede om hjælp, hvornår man skal arbejde sammen, hvordan ændringer og færdigt arbejde skal godkendes og indarbejdes.
  • Daglige Standup-møder: dette er et grundlæggende princip for de fleste Agile softwarestyringsstrategier. Bed hvert teammedlem om at rapportere om, hvad de gjorde i går, hvad de vil gøre i dag, og om de har brug for hjælp til noget. Hold mødet under 15 min. Hvis det er muligt. Det er vigtigt at gøre dette personligt eller i et videomøde (mod telefon), så teammedlemmer kan være opmærksomme på visuel feedback og tilknyttet social dynamik, som er en del af teammedlemmer, der holder hinanden ansvarlige for teamets mål. Jeg har fundet det uvurderligt at også have et Daily Standup-dagsorden-dok, hvor alle skriver deres opdateringer i omvendt kronologisk rækkefølge forud for dette daglige møde, og dette dokument tilfører alle opdateringer over tid. Dette hjælper introverte med at samle deres tanker forud for selve mødet, og skaber en skannelig papertrail af udført arbejde, som kommer godt med, når man forbereder sig til evaler eller indhenter et teammedlem, der gik glip af et møde.
  • Regelmæssige muligheder for at checke ind på processen: undertiden bliver ingeniører efterladt eller frustrerede over andre ingeniører eller en proces eller den måde et projekt går på. Det er bedre at afværge disse frustrationer direkte med klar kommunikation, der inkluderer hele teamet, og skabe muligheder for lav stress til at dele denne feedback. Til tider har jeg fundet det nyttigt at inkludere "Process Check" på listen over elementer, som hvert teammedlem rapporterer om i daglige Standup-møder. På andre tidspunkter har jeg fundet det nyttigt at udføre dette "Process Check" -trin i sprintplanlægningsmøder hvert par uger. Hver gang "Processcheck" sker, er det nyttigt at ikke bare tale om, men også nedskrive foreslåede procesændringer, så der er en delt aftale om at henvise til, hvis der er fremtidig forvirring.
  • POP'er til møder længere end 15 minutter: Det er let at falde i fælden med Death By Meetings, når der er store beslutninger, man skal tage som et team eller en kaotisk situation at navigere i. En måde at undgå overdrevne møder er at give nogen mulighed for at foreslå et teammøde, men sørg for, at mødet har en POP: Formål, resultat, proces med en dagsorden, der er sat mindst en dag før det foreslåede møde. Dette hjælper med at holde mødet fokuseret og handlingsmæssigt, og ved at dele dagsordenen i forvejen kan folk, der er interesseret i at forberede sig til at deltage, og folk, der ikke skal fravælge det.

Opret sikre rum til at lære og stille spørgsmål.

Alle lærer ved at begå fejl og forkert tusind gange, før de får det rigtigt. Du kan kalde dette "tinkering." Det smukke ved kodning er, at du kan få ting forkert og derefter til sidst lige med den hastighed, du kan tænke, med ringe eller ingen fysiske omkostninger. Men når du udforsker et nyt problemrum, kan forskellige mennesker (baseret på erfaring og personlig præference) søge træet i mulige løsninger mere bredt eller dybere og kan have udviklet mentale modeller, der giver dem mulighed for at have et mere kompakt søgerum end andre til bestemte problemrum. Ingeniører begynder at gøre hinanden smartere og hurtigere, når de har det godt med at dele deres problemløsningsprocesser og trin. Dette involverer naturligvis en masse følelse af stum og at stille “stumme spørgsmål” (hvoraf ingen faktisk er stumme), og for at kunne gøre det overhovedet kræver det en betydelig mængde tillid. Tillid kan være svært at komme ind i job med høje stakes, hvor ego eller omdømme står på spil, og alle prøver at leve op til en slags ”genius engineer” -arketype. Ledere skal eksplicit oprette sikre rum ved at erklære, at der ikke er dumme spørgsmål, model dette ved at stille de "dumme" spørgsmål, skabe struktureret plads til samarbejde og belønne dem, der proaktivt samarbejder. Hvis du ikke gør dette eksplicit, skaber sandsynligvis nogle ingeniører i dit team disse sikre rum, men ikke alle vil automatisk blive inkluderet.

https://xkcd.com/722/

Strategier til at skabe sikre rum

  • Regelmæssig 1–1: Ledere skal have regelmæssige 1–1 med personalet, helst en halv time en gang om ugen. Ledere bør tilskynde personale til at føre dagsordenen for disse møder. Det er nyttigt at vedligeholde et delt dagsordendokument på 1–1 til dette møde, hvor personalet kan tilføje ting forud for tiden, når der opstår problemer. Dette dagsorden doc fungerer også som en nyttig papertrail når man skriver evals eller reflekterer over tidligere udfordringer og muligheder.
  • Regelmæssig 2x2 feedback: Lederen og medarbejderen skriver hver for sig ned og deler to ting, som medarbejderen har det godt, to ting, som medarbejderen kunne gøre bedre, to ting, som lederen har det godt, og to ting, der kunne være bedre. Dette kan være et nyttigt indtjekningspunkt for personalets præstation og også et sikkert sted for personalet at give ledere feedback. Uanset hvor venlig eller tilgængelig du måtte være som manager, vil de fleste medarbejdere tøve med at give dig negativ feedback overhovedet, medmindre du inviterer dem til.
  • Udpak jargon: normaliserer praksis med at markere jargon, når en ingeniør kaster et ukendt udtryk eller akronym, der ikke deles af resten af ​​teamet, og beder dem om at forklare, hvad udtrykket betyder for hele teamet.
  • Planlagt parprogrammering: parprogrammering er en fantastisk produktivitetsforstærker og en fantastisk måde for ingeniører at lære af hinanden. I stedet for at vente på, at parprogrammering skal ske organisk mellem ingeniører, der allerede er komfortable med hinanden, skal du bede teammedlemmer om eksplicit at planlægge dette på deres kalendere, og sørge for, at alle ingeniører har adgang til den parringstid, de ønsker. Bed også ingeniører til at forhandle den rigtige enhed af fokusstid for dem (for nogle er det 60 minutter, andre 90 minutter, andre 120 minutter) og den mest produktive tid på dagen at parre.
  • Eksplicit mentormuligheder: give enhver junioringeniør i teamet muligheden for at have en senior engineer mentor, og eksplicit inkludere effektiv mentoring i senioringeniørens mål. Opmuntr mentorer til at arrangere ugentlige møder med deres mentees og skabe sikre rum til at stille ”stumme” spørgsmål eller afklare processer eller normer med en senior allieret.
  • Øv jævnlige gentagelser: Når en ingeniør lærer andre en ny ramme, går alle gennem en foreslået arkitektur eller ombordstiller medlemmer af teamet til et nyt system, er det undertiden let for lyttere at lukke ned eller blive distraheret. For at holde diskussionen aktiv, bedes lytterne regelmæssigt gentagne gange gentagne gange forklares, efter hvert 5. minut. Den performative karakter af den verbale gentagelse tvinger lytteren til at bevise for sig selv, at de forstår konceptet, ELLER at formulere, hvilke yderligere oplysninger de har brug for at forstå. Normaliser dette, når man går om bord eller gennemfører projekt-kickoff-møder, og opfordrer folk tilfældigt til at gøre gentagelser for at holde alle opmærksomme.
  • Tilskynde og model stille ”dumme” spørgsmål: som manager vil folk nøje se din opførsel og tone og model deres opførsel og sociale normer imod dette. Så det er vigtigt at modellere ovenstående værdier i, hvordan du interagerer med resten af ​​dit team, og især at modellere evnen til at stille direkte spørgsmål, når du ikke helt forstår noget. Dette viser, at effektiv problemløsning altid er vigtigere end ego eller opfattelsen af ​​at altid have ret.

Eksplicit ombord alle teammedlemmer til nye projekter.

Når du starter et nyt projekt, er det vigtigt at pakke ikke kun ud, hvad der skal udføres, men hvorfor dette arbejde er vigtigt, og hvem dette arbejde er vigtigt for. Sørg for, at ingeniørteamene forstår ”hvorfor” såvel som ”hvad” kan lede beslutningstagningen, når uventede valgpunkter dukker op, og minimerer risikoen for at bruge tid på at løse de forkerte problemer. Og efter at have startet et nyt projekt, er det vigtigt at sikre, at alle har det, de har brug for for at afhente en opgave og straks blive produktive til denne opgave. Hvis du ikke gør dette eksplicit, vil nogle ingeniører i dit team slå jorden i gang, og andre vil kæmpe med bootstrapping-trin som at oprette lokale udviklingsmiljøer. At gøre disse trin til en forudsætning for at starte et projekt sikrer, at alle er i stand til at slå jorden i gang.

Strategier til eksplicit onboarding

  • Udviklingsmiljøer: Sørg for, at alle i teamet har et funktionelt udviklingsmiljø, før du kalder et projekt klar til at starte. Ingeniører, unge og gamle, kæmper alle fra tid til anden for at få lokale udviklingsmiljøer i gang, og dette bliver en skjult omkostning i softwareprojektets tidslinjer. Når dette sker, føler ingeniører sig generede og undgår ofte at indse, at de har brug for hjælp, ved at forblive i en rolle, der er perifer for kodning, eller kun laver parprogrammering med ingeniører, der har arbejdsudviklingsmiljøer. Det er bedst bare at fjerne den potentielle kamp og skam og kalde dette det arbejde, det er, og derefter planlægge for at indlæse dette arbejde ved at gøre udviklingsmiljøopsætningen eksplicit og understøttet - noget alle gør sammen, der ikke er markeret som " gjort ”, indtil alle på projektet har et arbejdsmiljø.
  • Guidet tur til codebases: når man starter eller genstarter et projekt, skal ingeniøren, der kender codebase bedst, give en guidet tur til codebase, og holde pause for periodiske “gentagelser” fra mindre kendte teammedlemmer, rotere mellem medlemmerne, så alle er ansvarlig for at lære kodebasestrukturen godt nok til at være i stand til at forklare den tilbage.
  • Debuggers: Når alle har et udviklingsmiljø og en konceptuel forståelse af, hvordan systemet fungerer, skal alle installere en debugger og være i stand til at spore eksekvering gennem systemet til en prøveanmodning eller input. At være i stand til at arbejde lokalt og fejlsøge vil sikre, at når ingeniører begynder at afhente opgaver, vil de mindst være i stand til at starte disse opgaver på egen hånd. Dette reducerer frustrationen og øger produktiviteten og ejerskabet.

Opret en kultur med ansvarlighed

Det kritiske arbejde med software engineering management er at sikre, at dit team udfører det rigtige arbejde på det rigtige tidspunkt i den rigtige rækkefølge, og en kritisk del af at fokusere på det rigtige arbejde forbindes med interessenter på de rigtige måder. Softwareteam har flere interessenter: hinanden, den større organisation og brugere af den software, de bygger. Processer med softwareteamadministration skal skabe ansvarlighed med alle disse interessenter.

Strategier til at skabe ansvarlighedskultur

  • Projekt debrief-møder: Når et projekt er afsluttet og lanceret, er det vigtigt at have plads til et debrief-møde og lette dette, så alle i teamet har en chance for at dele deres feedback. En nyttig prompt, jeg bruger til dette, er “SaMoLo: hvad ville du gøre det samme af / Mere af / Mindre næste gang?” Opfordre teammedlemmer til at dele feedback om både tekniske og procesområder. Dette gør det muligt for teammedlemmer at holde hinanden ansvarlige for, om processer, der blev forhandlet som en del af Project Kickoff-mødet, blev fulgt.
  • Softwareprocesansvarlighed: kodegennemgang og frigørelsesprocesser, der er fastlagt i Project Kickoff-møder, skaber også ansvarlighed i teamet, ligesom Daily Standup-møderne gør.
  • Regelmæssige demonstrationsmøder: regelmæssige demonstrationer af projektforløb skaber ansvarlighed over for den større organisation. Vi kan godt lide at holde plads til ugentlige demonstrationer åben for alle interesserede medarbejdere. Dette er motiverende for teamet, fordi de får vist deres arbejde, det skaber et forum til at fange tidlige feedback fra interessenter og holder projektarbejdet fokuseret på iterative demoable leverancer, når det er muligt.
  • Brugercentriske målinger: skab ansvarlighed over for brugere af din software ved at udføre brugertest og definere og spore succesmålinger baseret på brugerengagement.

Hvorfor dette betyder noget

På trods af massiv fortjeneste er verden af ​​software-engineering i øjeblikket temmelig ineffektiv. 90% af software-opstart mislykkes, og jeg tror, ​​det i vid udstrækning skyldes problemer med udførelse af softwareprojekter. 50% af store firmasoftwareprojekter starter ikke i tide, på budget eller overhovedet. At være et år for sent eller en million dollars over budgettet er ikke nyheder for nogen, der nogensinde har arbejdet hos et stort softwarefirma. Software engineering kultur ofte mærker ledere som overhead eller lavere status end software ingeniører, som fører software ingeniører, der kunne være effektive ledere til at undgå denne forfremmelsessti, og nuværende software ledere til at have svært ved at forhandle med og regere i deres egne teams. Nogle gange kan selv åbent pleje af softwareteknologiprocesser stigmatiseres i miljøer, hvor cowboy-kodere beundres.

Det er desoraliserende at arbejde på et stort softwareprojekt kun for at se fristen blive ved med at blive skubbet tilbage eller projektet annulleret. I den for-profit-verden er dette et ineffektivt spild af tid og penge. I den almennyttige verden vil jeg hævde, at det er en uetisk brug af medlemsdonationer. For softwareingeniører er dette spild af vores dyrebare tid, energi og opmærksomhed.

Af både intellektuelle og økonomiske grunde er det vigtigt at revidere kulturen i dit arbejdsmiljø og kigge efter måder at optimere og forbedre det på. Hvis du starter med at gøre din arbejdskultur mere retfærdig, ansvarlig og retfærdig og et sted, hvor alle kan lykkes, vil du ikke kun gøre softwareingeniører lykkeligere, og software engineering mere effektiv, du vil gøre verden mere fair, ved at nedbringe omkostningerne ved softwareudvikling og fjerne diskriminerende barrierer.

At opbygge en software-ingeniørkultur, hvor alle kan trives, er ikke svært at gøre, men lige nu i en teknologikultur oversvømmet med hubris, grådighed, ego og etiske kvandarer er dette en radikal idé. Jeg betragter med vilje at opbygge en effektiv og støttende teamkultur som en aktivism. Lad os gøre fair og effektiv softwareteamkultur til normen!