Konkrete tilbakemeldinger på prestasjoner, ofte i form av medarbeidersamtaler, spiller en sentral rolle i den videre utviklingen av programvareutviklere. I denne artikkelen viser vi noen praktiske eksempler på hvordan man kan gi –-tilbakemeldinger til programvareutviklere i ulike situasjoner, for eksempel i forbindelse med medarbeidersamtaler, årlige medarbeidersamtaler eller prestasjonsvurderinger, det vil si i alle former for en-til-en-samtaler og -kontakt.
Hvorfor er tilbakemeldinger så viktig (og vanskelig) for programvareutviklere?
Motiverende tilbakemeldinger for introverte programvareutviklere
Programvareutviklere er tradisjonelt sett mer interessert i å jobbe med tekniske detaljer enn i å jobbe med andre mennesker. Det kan derfor være en utfordring for ledere å kommunisere tilbakemeldinger på en effektiv og motiverende måte, spesielt med mer introverte programvareutviklere.
Som leder for programvareutviklere må du imidlertid lære deg å kommunisere både positive og negative tilbakemeldinger på en konstruktiv måte i medarbeidersamtalen, slik at programvareutviklerne faktisk blir motivert til å realisere det utviklingspotensialet som er identifisert. De følgende eksemplene på tilbakemeldinger i denne artikkelen vil hjelpe deg med dette.
Hvis du er interessert i en generell innføring i regelmessige en-til-en-møter, kan du ta en titt på innlegget vårt om emnet: En guide: 6 tips for vellykkede 1-til-1-samtaler.
OBS: Vurder programvareutviklere individuelt
Til informasjon: Studier viser at programvareutviklere tradisjonelt sett er mer introverte. Trenden går imidlertid i retning av flere ulike personlighetstyper blant programvareutviklere. Du bør derfor alltid undersøke og vurdere hvilken personlighetstype som sitter overfor deg, og kommunisere deretter.
Kilde: Utviklingen av programvareingeniørers personlighetsprofil
Spørsmål og en spørreundersøkelse for tilbakemeldingsintervjuer
Intervju med programvareutvikler: typiske spørsmål
Før jeg gir deg en rekke eksempler, maler og formuleringer til medarbeidersamtalen med programvareutvikleren, vil jeg gi deg et lite tips: I mange situasjoner er det selvsagt fornuftig å begynne med å stille spørsmål for å sjekke den felles forståelsen av status quo –, ikke bare i IT-bransjen.
Derfor har jeg satt sammen noen spørsmål til medarbeidersamtaler med programvareutviklere:
🎯 1 til 1-spørsmål for programvareutviklere: Fokus
- Hva forstyrrer konsentrasjonen din på jobben?
- Når opplevde du sist en tilstand av flyt på jobben? Hvor lett er det for deg å komme inn i flyt?
- Når og hvordan innså du at du hadde overskredet din personlige "work in progress-grense"?
- Hva kan vi endre for å hjelpe deg med å oppnå en passende WIP i fremtiden?
- Hvordan er talene i teamet ditt fordelt? Hvordan reflekterer du over din egen rolle i det?
- Hvem er kundene våre som selskap, og hvordan bidrar arbeidet deres konkret til å oppfylle deres behov?
- Hva er det du ønsker å lære når du tenker på kollegene dine i og utenfor selskapet?
🏦 1 til 1-spørsmål for programvareutviklere: Forretningstankegang
- Hva er det som hindrer oss i å oppfylle kundenes behov?
- Hva synes du om forretningsmålet vårt: Er det lett å forstå, forståelig og motiverende?
- Hvordan kan vi styrke koblingen mellom ditt daglige arbeid og forretningsmålene våre?
- Hvordan kan vi gjøre det lettere for deg å bidra til å nå våre forretningsmål?
Kilde med ytterligere spørsmål: 100+ smarte spørsmål til On-On-One-møter (for ledere)
Dette bør gi deg en god idé om hvordan du kan tilnærme deg et slikt evalueringsintervju på en intelligent måte. Hvis du også ønsker en spesifikk undersøkelse, kan jeg gi deg en innledende mal.
Intervju med programvareutviklere: en undersøkelse
Tilsvarende undersøkelser kan bidra til å gjøre utviklingen av programvareutviklere målbar over tid.
Men de kan også fungere svært godt som et interaktivt grunnlag for en felles diskusjon.
Følgende undersøkelse fokuserer på fire ulike områder som er viktige for programvareutviklere. Disse påstandene vurderes vanligvis på en skala fra for eksempel én (helt uenig) til 7 (helt enig).
🪞Intervjuundersøkelse blant ansatte: For programvareutviklere
- Jeg gransker arbeidet vårt basert på min forståelse av #-teamets mål og behovene til #-kundene våre.
- Jeg bidrar proaktivt til kontinuerlig forbedring av teamet vårt. #TeamPlay
- Jeg kjenner utfordringene og problemene til #-kundene våre.
- Arbeidsoppgavene mine går vanligvis svært raskt, selv om det er nødvendig med ekstern # tilbakemelding.
Merk: Denne malen for medarbeidersamtalen ber om enighet i Health Check-elementene (spørreskjemaet) på en skala fra 1-7.
Som du kan se på den grønne knappen, kan du til og med bruke denne undersøkelsen gratis i vårt 1-til-1-møteverktøy Echometer hvis du har lyst. Vi har også mange andre maler for spørsmål og hele coachingmaler.
Det finnes en annen artikkel i bloggen vår hvis du er interessert i detaljerte maler for ulike en-til-en-møter (f.eks. ukentlige, årlige, 1-1 med vanskelige medarbeidere...): 15 velprøvde maler for 1-1-møter som du kan redigere (gratis).
Men nå, lenger fremme i tekst –, kommer vi til konkrete eksempler og formuleringer for tilbakemelding til programvareutviklere.
Generell mal for tilbakemelding til programvareutviklere
Unngå klassiske tilbakemeldingsmetoder som tilbakemeldingssandwichen
Maler for tilbakemeldinger i en-til-en-møter er ofte basert på sandwich-metoden. Vennligst unngå dette med programvareutviklere. Å "snakke rundt grøten" i medarbeidersamtaler hjelper ingen, og spesielt programvareutviklere er ofte allergiske mot slike metoder (se: Kritikk av sandwich-metoden for tilbakemelding).
Programvareutviklere innser som regel at når ledere gir generiske positive tilbakemeldinger, er det bare et verktøy for å få den andre personen til å føle seg bedre.
Heldigvis fungerer det også bedre.
Radical Candor: Tilbakemeldingsmetoden som fungerer bedre for programvareutviklere
I stedet for å pakke inn tilbakemeldingen fra én-til-én-møter i en tilbakemeldingssandwich, anbefaler jeg Radical Candor-metoden som grunnlag for tilbakemeldingsmalen din. Den er for øvrig ikke bare nyttig i IT-bransjen, men også i privat sektor – la oss gå dypere.
Radikal åpenhet innebærer å gi så ærlige og direkte tilbakemeldinger som mulig i medarbeidersamtalen. Samtidig betyr det også å vise empati og fokusere på den andre personens velvære. Radical Candor viser at du ikke trenger å velge enten det ene eller det andre: Enten direkte og ærlig, eller empatisk og hensynsfull. I stedet kan du gjøre begge deler samtidig:
Mer under: Hva er radikal åpenhet?
Programvareutviklere vil være takknemlige hvis du går rett på sak med negative tilbakemeldinger.
Tilbakemeldingsmal for programvareutviklere basert på Radical Candor
Denne malen er basert på SBI-modellen (Situation, Behaviour, Impact). Den hjelper deg med å kommunisere på en oppriktig, direkte og samtidig anerkjennende måte.
Se også "Gi tilbakemelding - Playbook"
Her er instruksjonene for de enkelte delene av tilbakemeldingsmalen:
Tilbakemeldingsmal del 1: Forberedelse på forhånd
Bruk noen minutter på å tenke gjennom følgende punkter før du gir tilbakemelding:
- Situasjon: Hvilken situasjon er det du sikter til?
- Oppførsel: Hvilken atferd observerte du hos personen?
- Påvirkning: Hvilken innvirkning hadde personens atferd (på deg og andre)?
- Ønske: Hvilken tilstand ønsker du å oppnå, og hvorfor? (Merk: Dette handler ikke direkte om å ønske seg en spesifikk atferd – dette er en del av tiltaket (se nedenfor). Det handler snarere om den bredere konteksten for hvorfor påvirkningen er et problem for deg).
- Tiltak: Hvilke forslag har du til personen? Hvilke atferdsendringer kan bringe oss nærmere målet? Hvilken støtte kan du tilby?
Det er best å skrive ned punktene kort, slik at du ikke glemmer noe under intervjuet.
Tilbakemeldingsmal del 2: Start samtalen
I stedet for å starte med en lang tilbakemeldingssandwich i et en-til-en-møte, kan du nå begynne direkte med situasjonen som en samtalestarter:
- "Jeg ville snakke med deg om situasjonen da vi ..."
Beskriv situasjonen, og spør deretter:
- "Husker du fortsatt situasjonen?"
Tilbakemeldingsmal del 3: Adferd
Deretter kan du ta opp personens atferd som du har observert i medarbeidersamtalen:
- "Du ristet på hodet over situasjonen og sa..."
Før du snakker om effekten, bør du gi den andre personen mulighet til å kommentere din oppfatning eller ditt minne:
- "Gjenspeiler jeg dette riktig sett fra ditt ståsted?"
Gi personen rom til å beskrive sitt perspektiv på ting. Forsøk å la begge perspektivene stå i rommet på like fot uten å kommentere dem. Begrens deg til å stille spørsmål om innholdet i den andres perspektiv.
Tilbakemeldingsmal del 4: Effekt
Først i denne delen handler det om å diskutere effekten av atferden. Hold deg så objektiv som mulig til å begynne med:
- "Mitt inntrykk var at min kollega Marc virket veldig fornærmet etter at du [observerte atferd], og at han ikke lenger var villig til å fortsette samarbeidet med oss."
Men hvis du også blir påvirket av effektene, er det viktig å dele dette også. Du skal selvfølgelig alltid være profesjonell, men du kan også vise deg fra din menneskelige side:
- "Selv ble jeg oppriktig flau i den situasjonen, og jeg opplevde samtalen som ubehagelig fra da av."
Tilbakemeldingsmal del 5: Ønske
Uttrykk dine spesifikke ønsker i denne delen av medarbeidersamtalen:
- "Det er viktig for meg at vi finner et godt grunnlag for samarbeid med vår kollega Marc igjen."
Sett det inn i en sammenheng igjen:
- "Og utover det er det et stort behov for meg at vi jobber sammen for å sikre at vi opprettholder et godt samarbeid og gode relasjoner med alle tilgrensende fagområder."
Referer også til relevante mål som forklarer hvorfor du har dette ønsket:
- "Bare gjennom et godt forhold kan vi nå målene våre som et team i dette selskapet. Det er også viktig for meg at vi har et godt omdømme som team i selskapet."
Tilbakemeldingsmal del 6: Mål
Før du presenterer dine egne løsningsforslag, kan du stille åpne spørsmål i en-til-en-samtalen:
- "Jeg har noen ideer om dette. Men jeg vil gjerne høre din mening først: Hvordan tror du vi kan nå målet?"
Deretter kan dere dele ideene deres. Bli sammen enige om en forpliktende og konkret definert oppfølging. Nedtegn dette skriftlig.
Tilbakemeldingsmal del 7: Avvisning
Spør om medarbeidersamtalen var nyttig for den andre personen, og om vedkommende har noen ubesvarte spørsmål. Avtal en avstemming for neste gang dere skal snakke om temaet.
Vis at du setter pris på den åpne dialogen, og takk personen for innsikten og samarbeidet.
Tilbakemeldingsmal del 8: Reflekter over tilbakemeldingene dine i ettertid
På slutten av hver tilbakemeldingsøkt bør du stille deg selv følgende spørsmål:
- Ærlighet: Har jeg delt tilbakemeldingene mine ærlig og så usminket som mulig?
- Anerkjennelse: Føler personen seg verdsatt av tilbakemeldingene mine?
Hvis du kan svare "ja" på alle spørsmålene, gikk tilbakemeldingsøkten veldig bra. Hvis ikke, er det ingen grunn til bekymring. Reflekter over hvordan du kan formulere ting annerledes i fremtiden. Og igjen, de fleste av disse tipsene gjelder ikke bare for IT-bransjen.
Her vil jeg gjerne påpeke at det selvfølgelig også finnes programvare for å forenkle tilsvarende tilbakemeldingsdiskusjoner og også mer langsiktig coaching av programvareutviklere.
Vår programvare for én-til-én-møter tilbyr deg ulike maler for medarbeidersamtaler med programvareutviklere, og gjør til og med medarbeiderutvikling målbar. Ta en titt på verktøyet vårt og prøv ut følgende mal:
1:1-møteverktøymal: Stemning som vær
- Hvis du skulle beskrive din følelsesmessige tilstand som været, hvordan er været i prosjektet eller arbeidsoppgavene dine for øyeblikket?
Hvordan er været i forhold til arbeidsgiveren din, privatlivet ditt og privatlivet ditt?
1:1-møteverktøymal: Stemning som vær
- Hvis du skulle beskrive din følelsesmessige tilstand som været, hvordan er været i prosjektet eller arbeidsoppgavene dine for øyeblikket?
Hvordan er været i forhold til arbeidsgiveren din, privatlivet ditt og privatlivet ditt?
La oss nå komme i gang ved hjelp av denne malen for medarbeidersamtalen og gå gjennom noen praktiske eksempler!
Eksempler på tilbakemeldinger til programvareutviklere i en-til-en-møter
Eksempel på tilbakemelding til programvareutviklere i 1-til-1-møter: Kodekvalitet
Med Tanja 👩🏼🦰 i rollen som teamleder og Marc 👨🏽 i rollen som medarbeider.
Beskriv situasjonen
👩🏼🦰
Tanja (teamleder): "I vår siste kodegjennomgang så vi på din pull-forespørsel om å implementere den nye funksjonen i dashbordet. Koden var funksjonelt korrekt og oppfylte kravene."
👨🏽
Marc (ansatt): "Ja, det husker jeg!"
Observert atferd
👩🏼🦰
"Jeg kommenterte passasjer som var ganske komplekse og vanskelige å lese. For eksempel var det en metode med over 50 linjer som kombinerte flere ansvarsområder. Men du kommenterte bare denne kommentaren overfladisk og gikk ikke nærmere inn på den."
👨🏽
"For meg hørtes kommentaren ut som et valgfritt forslag. Det virket for tidkrevende å endre løsningen på nytt."
Påvirkning
👩🏼🦰
"Uansett, kommentaren din gjorde meg litt frustrert for å være ærlig, og i stedet for å insistere på en løsning fra deg, forbedret jeg bare metoden selv etterpå fordi jeg allerede hadde tenkt meg inn i koden uansett."
👨🏽
"Å, det visste jeg ikke."
Mål og ønske
👩🏼🦰
"Vårt felles mål er å sikre at koden vår ikke bare er funksjonell, men også vedlikeholdbar og lett å forstå for alle."
👨🏽
"Det er akkurat slik jeg ser det!"
Tiltak
👩🏼🦰
"Hva er ditt forslag til hvordan vi kan forbedre kvaliteten på koden på en mer smidig måte i slike tilfeller i fremtiden?"
👨🏽
"Det ville hjelpe meg hvis det var lettere å se i kommentarfeltet om det bare foreslås eller kreves en forbedring."
👩🏼🦰
"Vel, la oss gjøre det –, jeg skal ta det med i teammøtet igjen. Men jeg tror fortsatt at du må følge opp på din side også."
👨🏽
"Hva om vi går rett over til parprogrammering sammen i neste tema, slik at du kan skjerpe min forståelse av kravene til kodekvalitet?"
Konklusjon
👩🏼🦰
"Det høres ut som to gode oppfølgere! Da fortsetter vi slik. Jeg vil gjerne sette av en dato i kalenderen min i midten av neste uke for å starte parprogrammeringen."
👨🏽
"Greit, jeg gleder meg!"
Eksempel på tilbakemelding til programvareutviklere i 1-til-1-møter: Eierskap
Med Tanja 👩🏼🦰 i rollen som teamleder og Marc 👨🏽 i rollen som medarbeider.
Beskriv situasjonen
👩🏼🦰
Tanja (teamleder): "Marc, jeg vil snakke med deg om den siste oppgaven, der vi utviklet den nye funksjonen for eksportprosessen. Funksjonen er nå live, men det var noen utfordringer underveis."
👨🏽
Marc (ansatt): "Ja, det husker jeg. Hva mener du egentlig?"
Observert atferd
👩🏼🦰
"Jeg la merke til at det var flere lange forsinkelser etter at koden ble overlevert til testing. Noen kommentarer fra QA-kolleger ble for eksempel ikke besvart på flere dager. Det hendte også at jeg måtte minne deg på en manglende gjennomgang to ganger."
👨🏽
"Hmm, jeg skjønner. For å være ærlig var det ganske mye som foregikk, og jeg trodde testingen ville fortsette parallelt."
Påvirkning
👩🏼🦰
"Resultatet var at vi måtte utsette utplasseringen på grunn av dette problemet."
👨🏽
"Å, det visste jeg ikke engang. Jeg trodde du ville ta kontakt hvis det var noe som hastet."
Mål og ønske
👩🏼🦰
"Målet vårt er å minimere unødvendige forsinkelser og få utviklerne til å innta en eierskapsholdning under implementeringen. Det betyr at alle aktivt sørger for at saken deres kommer gjennom fra start til slutt, og det inkluderer også kommunikasjon med QA."
👨🏽
"Jeg forstår hva du mener. Jeg ønsker definitivt at prosessene skal gå smidigere."
Tiltak
👩🏼🦰
"Hva kan vi gjøre fra ditt perspektiv for at du skal kunne opptre mer proaktivt og vise eierskap i slike situasjoner?"
👨🏽
"Jeg tror det ville hjelpe hvis vi hadde tydeligere forventninger, for eksempel at jeg daglig sjekker inn åpne problemer i testfasen. På den måten kan jeg sørge for at ingenting blir ugjort."
👩🏼🦰
"Det høres bra ut. Og jeg vil foreslå at du for de neste store oppgavene etter at koden er ferdigstilt, lager en kort plan for hvordan du ønsker å følge opp temaet frem til lanseringen. Du kan vise planen til meg eller en QA-kollega."
👨🏽
"Enig. Da kan jeg holde bedre øye med ting selv."
Konklusjon
👩🏼🦰
"Flott. La oss registrere de to tiltakene slik: Du gjør daglige innsjekkinger i testfasen og planlegger oppfølgingen av den neste store oppgaven. Er det gjennomførbart for deg?"
👨🏽
"Ja, det passer. Jeg skal skrive det rett inn i dagboken min."
👩🏼🦰
"Flott. Jeg er sikker på at det vil utgjøre en stor forskjell. I vårt neste en-til-en-møte skal vi ta en ny titt på status for tiltakene våre. Takk skal dere ha!"
Eksempler på tilbakemeldinger til programvareutviklere i medarbeidersamtalen
Merk: Tradisjonelle medarbeidersamtaler er ofte upopulære blant både programvareutviklere og ledere, og mange mener at gode en-til-en-møter er tilstrekkelig og bør erstatte medarbeidersamtalene. Se mer: "Medarbeidersamtaler er meningsløse og fornærmende" av Forbes.
Medarbeidersamtaler er imidlertid fortsatt ofte et forhåndsbestemt format i bedriften. Dette bør selvsagt ikke hindre deg i å gjennomføre medarbeidersamtaler som en dialog i øyehøyde med medarbeiderne dine, i stedet for å begrense deg til å foreta vurderinger ovenfra og ned. Følgende eksempler på en-til-en-dialog viser hvordan det kan fungere.
Merk: Som allerede nevnt kan maler for medarbeidersamtaler selvsagt bidra til å kommunisere tilbakemeldinger på en konstruktiv måte. Følgende blogginnlegg kan hjelpe deg hvis du er mer interessert i temaet: 5 maler for regelmessige medarbeidersamtaler.
Eksempel på tilbakemelding til programvareingeniører i medarbeidersamtaler: Teamarbeid
Med Tanja 👩🏼🦰 i rollen som teamleder og Marc 👨🏽 i rollen som programvareingeniør.
Beskriv situasjonen
👩🏼🦰
Tanja (teamleder): "Da jeg skulle vurdere punktet "Teamarbeid" i malen for medarbeidersamtalen din, kunne jeg dessverre bare gi deg 5 av 10 mulige poeng. Jeg vil gjerne forklare deg dette for å gi deg en rettferdig sjanse til å forbedre deg på dette punktet."
👨🏽
Marc (ansatt): "Å, ok. Vær så snill og hjelp meg å forstå."
Observert atferd
👩🏼🦰
"Jeg har lagt merke til at det har vært situasjoner de siste månedene der samarbeidet med teamet ikke har vært optimalt. I den siste sprinten vår var det for eksempel flere tilfeller der du jobbet med oppgaver på egen hånd, selv om de kunne vært løst bedre sammen med andre. Et konkret eksempel var integrasjonen av det nye API-et. Vi hadde vurdert å la deg og Alex jobbe med det sammen, men du tok de fleste stegene alene og involverte Alex minimalt."
👨🏽
"Jeg tenkte at det ville være mer effektivt å gjøre det raskt selv. Jeg var ikke klar over at dette ble sett på som et problem."
Påvirkning
👩🏼🦰
"Dette førte imidlertid til at teamet mistet gjennomsiktigheten. Alex hadde senere problemer med å bli involvert i relaterte oppgaver fordi han ikke visste nøyaktig hvordan API-et var satt opp. Jeg fikk også tilbakemeldinger fra andre teammedlemmer om at de noen ganger ikke følte seg nok involvert og syntes det var vanskelig å få støtte fra deg når de hadde spørsmål."
👨🏽
"Det overrasker meg, for å være ærlig. Jeg trodde jeg skulle hjelpe til når jeg ble spurt."
Mål og ønske
👩🏼🦰
"Målet vårt som team er ikke bare å jobbe effektivt, men også å dele kunnskap og involvere alle. Det styrker samarbeidet og sikrer at vi alle kan representere hverandre. I fremtiden ønsker jeg at du i større grad utnytter din rolle som kunnskapsbærer i dette teamet for aktivt å dele kunnskap og styrke de andre teammedlemmene. Teamets produktivitet er viktigere enn individuelle prestasjoner."
👨🏽
"Ok, jeg forstår hva du mener. Jeg tror bare at jeg har fokusert for mye på min egen produktivitet så langt."
Tiltak
👩🏼🦰
"Hva kan hjelpe deg til å bli mer oppmerksom på å involvere teamet i arbeidet ditt og dele kunnskap?"
👨🏽
"Jeg kan gjøre det til en vane å avklare hvem som kan jobbe med større oppgaver og hvordan helt fra starten. Kanskje vi også kunne arrangere en slags kick-off for oppgaver for å bli enige om de grove arkitekturbeslutningene og identifisere oppgaver som noen andre bør gjøre alene, eller som vi til og med bør gjøre i parprogrammering."
👩🏼🦰
"Det høres bra ut. Jeg har også en idé: Hva med om du gjør det til en vane å ikke bare rapportere om fremdriften på de ukentlige teammøtene våre, men også aktivt bidrar med innsikt i koden og arkitektoniske beslutninger?"
👨🏽
"Det er et godt poeng. Det kan bidra til å gjøre det enklere for våre uerfarne kolleger å jobbe med koden min senere."
Konklusjon
👩🏼🦰
"Flott. Da registrerer vi oppfølgingen i malen vår for medarbeidersamtalen:
- Fra nå av vil du proaktivt dele din kunnskap og dine arkitektoniske beslutninger med teamet i Weeklys.
- Fra nå av skal du starte temaene dine sammen med en annen utvikler, slik at dere kan utarbeide løsningen sammen og dele opp implementeringen."
👨🏽
"Høres bra ut."
👩🏼🦰
"OK. Jeg vil notere begge tiltakene for en gjennomgang om to måneder. Så kan vi diskutere status i en-til-en-møtet vårt og se hvordan vi går videre."
👨🏽
"Ja, og så skal vi også se om du ikke kan forbedre poengsummen din på 'teamarbeid'. Jeg vil gjerne ha minst 8 av 10."
👩🏼🦰
"Det er jeg glad for å høre! Jeg tror absolutt at det er realistisk, og jeg vil støtte deg der jeg kan."
👨🏽
"Takk skal du ha!"
Eksempel på tilbakemelding til Software Engineers Performance Reviews: Eierskap
La oss gå videre til neste eksempel på en én-til-én-samtale, som handler om tilbakemelding til programvareutvikleren om temaet eierskap.
Som alltid med Tanja 👩🏼🦰 i rollen som teamleder og Marc 👨🏽 i rollen som programvareingeniør.
Beskriv situasjonen
👩🏼🦰
Tanja (teamleder): "Da jeg skulle vurdere punktet "Eierskap" i malen for medarbeidersamtalen din, kunne jeg bare gi deg 6 av 10 poeng. Jeg vil gjerne forklare hvorfor det er slik, og gi deg muligheten til å utvikle deg videre på dette området."
👨🏽
Marc (ansatt): "Jøss, det overrasker meg litt. Jeg har tross alt jobbet med flere temaer enn nesten alle andre i teamet. Vennligst forklar det for meg."
Observert atferd
👩🏼🦰
"De siste månedene har jeg lagt merke til at det ofte er forsinkelser i oppgavene dine. Det finnes flere eksempler på at QA-kommentarer eller kodegjennomganger fra deg har blitt liggende ubesvart i lang tid. Resultatet er at temaene dine først ble satt i drift etter flere uker med forsinkelser. Et konkret eksempel var feilrettingen for eksporten. Du svarte først på tilbakemeldinger fra QA etter gjentatte forespørsler, og det tok totalt tre uker før endringene ble tatt i bruk."
👨🏽
"Ja, det husker jeg. Jeg jobbet med to andre temaer samtidig og fikk ikke skrevet inn tilbakemeldingen så raskt."
Påvirkning
👩🏼🦰
"Dette hadde innvirkning på hastigheten og produktiviteten til hele teamet. QA måtte følge opp flere ganger, noe som bandt opp kapasiteten deres. Releaseplanen måtte også utsettes. I tillegg føles det som om du ikke tar det fulle ansvaret for å ferdigstille problemene dine, noe som går ut over dynamikken i teamet. Noen teammedlemmer har fortalt meg at de føler seg usikre på om de kan stole på deg når det gjelder avhengigheter."
👨🏽
"Å, jeg beklager det. Det var jeg ikke klar over. Jeg prøvde å gjøre oppgavene parallelt, men det gikk tydeligvis ikke så bra."
Mål og ønske
👩🏼🦰
"Målet mitt er at du skal fokusere på færre emner, men ta fullt ansvar for hver oppgave fra start til slutt. Det betyr at du ikke bare skriver den første koden, men også sørger for at QA-tilbakemeldingene blir behandlet raskt og at temaet holder tidsplanen. På denne måten kan vi unngå at oppgaver blir liggende åpne over lengre tid og blokkere andre."
👨🏽
"Det gir mening. Jeg følte meg ofte overveldet fordi jeg hadde for mange temaer samtidig. Kanskje er det virkelig bedre å konsentrere seg om færre oppgaver."
Tiltak
👩🏼🦰
"Hvordan kunne vi få deg til å fokusere på noen få temaer og ta ansvar for å gjennomføre dem fullt ut?"
👨🏽
"Jeg kan prøve å begrense meg til maksimalt to temaer per sprint og aldri jobbe med mer enn tre temaer samtidig. Jeg bør også sette av faste tidspunkter i kalenderen min til å jobbe med kommentarer og vurderinger, slik at jeg ikke glemmer noe."
👩🏼🦰
"Det høres fornuftig ut. I tillegg tror jeg det ville være bra om du proaktivt kunne be om hjelp i standupene våre hvis du jobber med for mange temaer samtidig. Det bør som regel være noen som kan ta over et tema fra deg."
👨🏽
"Ok, greit."
Konklusjon
👩🏼🦰
"La oss sette oss disse tiltakene som mål for de neste to månedene:
Mindre arbeid parallelt:
- Du tar deg av maksimalt to temaer per sprint og jobber ikke med mer enn tre temaer parallelt.
- Krev aktiv støtte fra teamet i stand-ups
- Faste tidsluker i kalenderen for å gå gjennom kommentarer og anmeldelser."
👨🏽
"Det høres realistisk ut. La oss gjøre det på den måten."
👩🏼🦰
"Flott. Om to måneder kan vi se i medarbeidersamtalen om disse tiltakene har fungert, og om vi kan heve karakteren din i medarbeidersamtalen for 'Eierskap' igjen."
👨🏽
"Takk, Tanja. Det skal jeg forsøke å praktisere. Jeg pleide alltid å få toppkarakter for "Eierskap". Tror du at jeg kommer til å få det igjen ved neste medarbeidersamtaler?"
👩🏼🦰
"Det er jeg glad for. Ja, jeg tror absolutt at det er mulig å oppnå en rask forbedring med disse tiltakene. La oss diskutere status og om du trenger støtte i våre en-til-en-møter hver 14. dag."
👨🏽
"Takk skal du ha! Ja, det ville glede meg om vi kunne oppnå en merkbar forbedring her i løpet av noen uker!"
Eksempler på tilbakemeldinger til programvareutviklere i den årlige gjennomgangen
Hvis du allerede har regelmessige en-til-en-møter eller medarbeidersamtaler med utviklerne dine i løpet av året, trenger du sannsynligvis ikke lenger detaljerte årlige møter. Utvekslingen av prestasjoner, tilbakemeldinger og videreutvikling bør allerede være en løpende dialog:
Likevel finnes det selskaper som krever en klassisk årlig vurdering.
💡
Hvis du som leder for programvareutviklere allerede har regelmessige 1:1-møter eller medarbeidersamtaler, bør den årlige medarbeidersamtalen bare være en formalitet:
Programvareutvikleren bør allerede være klar over tilbakemeldingene og bør allerede jobbe med utviklingspotensialet.
Så hvis du som leder for programvareutviklere må oppfylle formalitetene ved et årssluttmøte (eventuelt i tillegg til vanlige en-til-en-møter), la oss også gå gjennom et eksempel på en årlig medarbeidersamtale med en programvareutvikler.
Forresten, et annet tips på dette punktet: Hvis det første møtet med en ny medarbeider er rett rundt hjørnet, kan jeg anbefale vår artikkel om emnet: 5 tips for en-til-en-møter med nyansatte.
Eksempel på agenda og mal for et årlig møte med en programvareutvikler
Gjennomgang og ytelse
Suksesser: Hvilke prosjekter eller oppgaver gikk bra? Hvor ble forventningene overgått?Utfordringer: Hva fungerte ikke så bra, og hvorfor? Hvordan kan disse utfordringene overvinnes i fremtiden?Refleksjon: Hvordan ser utvikleren på sine egne prestasjoner? Hvilke tilbakemeldinger har teamet eller lederen?
Samarbeid og teamkultur
Kommunikasjon: Hvordan oppleves samarbeidet innad i teamet og med lederen?Arbeidsklima: Er det forbedringspotensial i teamkulturen eller arbeidsmiljøet?Tilbakemelding på lederskap: Hvordan kan veilederen støtte utvikleren bedre?Tilbakemeldinger fra utvikleren: Har du noen forslag til forbedring av prosesser, verktøy eller arbeidskultur?Balanse mellom arbeid og fritid: Hva synes du om den nåværende arbeidsmengden? Er det noen overtids- eller stressfaktorer?Ressurser: Er verktøyene, prosessene og rammebetingelsene tilstrekkelige for å jobbe effektivt?
Kompetanse, mål og utvikling
Styrker: Hvilke tekniske, metodiske eller sosiale ferdigheter kjennetegner utvikleren?Videre opplæring: Hvilke nye teknologier eller ferdigheter ønsker utvikleren å lære seg? Finnes det noen relevante kurs, konferanser eller prosjekter?Karrieremål: Hvilken stilling eller hvilket ansvar sikter utvikleren mot på mellomlang til lang sikt? Hvilke steg fører dit?Prosjektfokus: Hvilke prosjekter eller teknologier ønsker utvikleren å jobbe mer intensivt med?
Godtgjørelse
Resultatavhengig avlønning: Er det behov for å justere lønn eller bonuser?
Konklusjon
Kortsiktige mål: Hvilke konkrete mål bør vi sette oss for det kommende året?Avtaler: Hva er de neste innsjekkingene for de respektive tiltakene?
Følgende er et typisk eksempel på tilbakemelding i en årsavslutningssamtale eller årlig medarbeidersamtale: Den ansattes ønske om en rolleendring.
Eksempel på tilbakemelding i årsmøtet: Ønske om rolleendring
Med Tanja 👩🏼🦰 i rollen som teamleder og Marc 👨🏽 i rollen som programvareingeniør.
Inngang og situasjon
👩🏼🦰
Tanja (teamleder): "Marc, det er flott at vi kan snakke om den årlige tilbakemeldingen og målene dine i dag. Er det noen spesifikke temaer som er spesielt viktige for deg?"
👨🏽
Marc (ansatt): "Ja, jeg har tenkt på min videre utvikling. Jeg kunne tenke meg å utvikle meg i retning av programvarearkitektur. Jeg har lenge vært interessert i emnet, og jeg vil gjerne bli mer involvert i arkitekturbeslutninger og strategisk teknologiledelse."
👩🏼🦰
"Det er spennende, Marc. Jeg er glad for at du har så klare mål. La oss snakke om hvordan vi kan forberede deg på dem. Det er noen punkter der jeg tror du trenger å utvikle deg ytterligere før vi tar neste skritt."
Gi tilbakemelding
👩🏼🦰
"For det første vil jeg understreke at dere har gjort store fremskritt i år, særlig når det gjelder kvaliteten på implementeringene og håndteringen av ny teknologi. Dere har også vist at dere har et blikk for helheten, for eksempel med innføringen av det nye caching-systemet."
👨🏽
"Takk, det er jeg glad for å høre!"
👩🏼🦰
"Når jeg tenker på rollen som programvarearkitekt, er det imidlertid fortsatt noen krav som jeg mener ikke er fullt ut oppfylt i dag. For eksempel er det å kommunisere med teamet og involvere andre i tekniske beslutninger en nøkkelkomponent. Der ser jeg fortsatt et potensial for deg. Du tar ofte beslutninger på egen hånd uten å involvere teamet tidlig nok."
👨🏽
"Ok, jeg forstår det. Jeg ville ikke holde noen oppe noen ganger, men jeg skjønner at det ikke er ideelt for arkitektrollen."
Mål og ønske
👩🏼🦰
"Akkurat. En programvarearkitekt er også en coach og kommunikator. Det handler om å få andre med på laget, kommunisere tekniske konsepter og utvikle løsninger sammen."
👨🏽
"Det gir mening. Jeg innser også at jeg ennå ikke er i stand til å kommunisere tankene mine om arkitektur til teammedlemmene mine på en like effektiv måte."
Planlegg tiltak
👩🏼🦰
"Jeg tror vi kan jobbe sammen om dette slik at du kvalifiserer deg til rollen i løpet av de neste seks månedene. Hva om vi definerer konkrete tiltak?"
👨🏽
"Det vil jeg gjerne. Hva har du i tankene?"
👩🏼🦰
"Fremfor alt skulle jeg gjerne sett at du ledet beslutningsprosessen for programvarearkitekturen i stedet for å ta avgjørelsen selv. Hva med å moderere et arkitektur-kick-off for hvert av de neste store temaene? Målet er å støtte kollegene i beslutningsprosessen og deretter la dem implementere løsningen selv."
👨🏽
"Det høres bra ut. Jeg lærer meg å øve innflytelse som trener i stedet for å gjennomføre alt selv."
👩🏼🦰
"Jeg kan også tenke meg at det finnes gode kurs for å forberede utviklere på rollen som programvarearkitekt. I tillegg til de harde ferdighetene vil disse kursene helt sikkert også dekke de myke ferdighetene som kreves for rollen."
👨🏽
"Ja, jeg har faktisk allerede valgt kurs."
Konklusjon
👩🏼🦰
"Flott, da noterer jeg følgende til årsmøtet vårt:
- Utviklingsmål: Programvarearkitekt
- Tiltak:
- Moderering av arkitektur-kick-off i et team
- Deltakelse på kurs for programvarearkitekter
Vi snakker selvfølgelig kontinuerlig om disse temaene i de individuelle møtene våre, men den neste offisielle innsjekkingen vil være i forbindelse med medarbeidersamtalen om tre måneder."
👨🏽
"Høres bra ut. Vi bør ha oppnådd mye innen den tid."
👩🏼🦰
"Det tror jeg også! I mellomtiden, hvis du kommer på noe annet jeg kan gjøre for å støtte deg i dette arbeidet, er du velkommen til å kontakte meg når som helst."
👨🏽
"Kan vi snakke om det planlagte rolleskiftet mitt igjen om tre måneder?"
👩🏼🦰
"Ja, jeg kan selvsagt ikke love deg noe når det gjelder rollebytte. Men jeg har notert meg ønsket ditt, og jeg skal prøve å støtte deg så godt jeg kan."
👨🏽
"Takk skal du ha!"
Konklusjon: Motiverende tilbakemeldinger for programvareutviklere
Eksemplene og malene viser at det ikke trenger å være så vanskelig å gi motiverende tilbakemeldinger til programvareutviklere i en-til-en-møter og årsavslutningsmøter, ikke sant? Vær autentisk og velvillig, ikke gå rundt grøten, og vis at du er interessert i en felles løsning.
Hvis du klarer å implementere "Radical Candour" i medarbeidersamtalene og i andre sammenhenger ved å vise anerkjennelse og ærlighet, kan reaksjonen bli mer positiv og konstruktiv enn du tror.
Lykke til med de neste tilbakemeldingsøktene!
Og hvis du liker hacks som gjør livet ditt enklere, anbefaler jeg vår Echometer-programvare. Du kan prøve den helt gratis.
Vår programvare for én-til-én-møter tilbyr deg ulike maler for medarbeidersamtaler med programvareutviklere, og gjør til og med medarbeiderutvikling målbar. Ta en titt på verktøyet vårt og prøv ut følgende mal:
1:1-møteverktøymal: Stemning som vær
- Hvis du skulle beskrive din følelsesmessige tilstand som været, hvordan er været i prosjektet eller arbeidsoppgavene dine for øyeblikket?
Hvordan er været i forhold til arbeidsgiveren din, privatlivet ditt og privatlivet ditt?
1:1-møteverktøymal: Stemning som vær
- Hvis du skulle beskrive din følelsesmessige tilstand som været, hvordan er været i prosjektet eller arbeidsoppgavene dine for øyeblikket?
Hvordan er været i forhold til arbeidsgiveren din, privatlivet ditt og privatlivet ditt?
