Specifik feedback på prestationer, ofta i form av "performance reviews", spelar en central roll i vidareutvecklingen av mjukvaruutvecklare. I den här artikeln visar vi några praktiska exempel på hur man kan ge – feedback till mjukvaruutvecklare i olika situationer, t.ex. vid utvecklingssamtal, årliga utvecklingssamtal eller medarbetarsamtal, dvs. i alla former av enskilda samtal och kontakter.
Varför är feedback så viktigt (och svårt) för mjukvaruutvecklare?
Motiverande feedback för introverta mjukvaruutvecklare
Mjukvaruutvecklare är traditionellt sett mer intresserade av att arbeta med tekniska detaljer än av att arbeta med andra människor. Det kan därför vara en utmaning för chefer att kommunicera feedback på ett effektivt och motiverande sätt, särskilt med mer introverta mjukvaruutvecklare.
Som chef för mjukvaruutvecklare måste du dock lära dig att kommunicera både positiv och negativ feedback på ett konstruktivt sätt under medarbetarsamtalen, så att mjukvaruutvecklarna verkligen motiveras att förverkliga den utvecklingspotential som identifierats. Följande exempel på feedback i den här artikeln hjälper dig att göra detta.
Observera: Utvärdera programvaruutvecklare individuellt
För din information: Studier visar att mjukvaruutvecklare traditionellt sett är mer introverta. Trenden går dock mot mer varierande personlighetstyper bland mjukvaruutvecklare. Du bör därför alltid granska och bedöma vilken personlighetstyp som sitter mittemot dig och kommunicera därefter.
Källa: Utveckling av mjukvaruingenjörers personlighetsprofil
Frågor och en enkät för feedbackdiskussioner
Utvärderingsintervju för mjukvaruutvecklare: typiska frågor
En anteckning innan jag ger dig massor av exempel, mallar och fraser för din utvärderingsintervju med programvaruutvecklaren: Naturligtvis är det i många situationer vettigt att börja med att ställa frågor för att först kontrollera den gemensamma förståelsen av status quo – inte bara i IT-branschen.
Därför har jag sammanställt några frågor för medarbetarsamtal med mjukvaruutvecklare:
🎯 1 till 1 frågor för mjukvaruutvecklare: Fokus
- Vad stör din koncentration på jobbet?
- När upplevde du senast ett tillstånd av flow på jobbet? Hur lätt är det för dig att komma in i flow?
- När och hur insåg du att du hade överskridit din personliga "work in progress limit"?
- Vad skulle vi kunna ändra på för att hjälpa dig att uppnå en lämplig WIP i framtiden?
- Hur fördelas anförandena i ditt team? Hur reflekterar du över din roll i det?
- Vilka är våra kunder som företag och hur bidrar ditt arbete specifikt till att uppfylla deras behov?
- Vad är det du vill lära dig när du tänker på dina kollegor i och utanför bolaget?
🏦 1 till 1-frågor för mjukvaruutvecklare: Affärsmässighet
- Vad hindrar oss från att uppfylla våra kunders behov?
- Vad tycker du om vårt affärsmål: är det lätt att förstå, begripligt och motiverande?
- Hur kan vi stärka kopplingen mellan ditt dagliga arbete och våra affärsmål?
- Hur kan vi bättre göra det möjligt för dig att bidra till våra affärsmål?
Källa med ytterligare frågor: 100+ smarta frågor om On-On-One-Meeting (för chefer)
Detta bör ge dig en god uppfattning om hur du på ett intelligent sätt kan ta dig an en sådan utvärderingsintervju. Om du också vill ha en specifik enkät kan jag förse dig med en första mall.
Medarbetarsamtal för mjukvaruutvecklare: en undersökning
Motsvarande undersökningar kan bidra till att göra mjukvaruutvecklarnas utveckling mätbar över tiden.
Men de kan också fungera mycket bra som ett interaktivt underlag för en gemensam diskussion.
Följande undersökning fokuserar på fyra olika områden som är viktiga för programvaruutvecklare. Dessa påståenden bedöms vanligtvis på en skala från till exempel ett (instämmer inte alls) till 7 (instämmer helt).
🪞Intervjuundersökning för anställda: För mjukvaruutvecklare
- Jag granskar vårt arbete utifrån min förståelse av #-teamets mål och våra #-kunders behov.
- Jag bidrar proaktivt till den kontinuerliga förbättringen av vårt team. #Tlagspel
- Jag känner till de utmaningar och problem som våra #-kunder har.
- Mina arbetsuppgifter går oftast mycket snabbt, även om det krävs extern # feedback.
Obs: I den här mallen för utvecklingssamtal efterfrågas svar på frågorna i Health Check (frågeformuläret) på en skala från 1-7.
Som du ser på den gröna knappen kan du till och med använda den här enkäten i vårt 1 till 1-mötesverktyg Echometer gratis om du känner för det. Vi har också många andra mallar för frågor och hela coachningsmallar.
Men nu, längre fram i text –, kommer vi till konkreta exempel och fraser för feedback till programvaruutvecklare.
Allmän mall för feedback till programvaruutvecklare
Undvik klassiska återkopplingsmetoder som t.ex. återkopplingssmörgåsen
Mallar för feedback i enskilda möten är ofta baserade på sandwichmetoden. Undvik detta när det gäller mjukvaruutvecklare. Att "gå runt busken" i medarbetarsamtal hjälper ingen och just mjukvaruutvecklare är ofta allergiska mot sådana metoder (se: Kritik mot sandwichmetoden för återkoppling).
När chefer ger generisk positiv feedback inser mjukvaruutvecklare oftast att det bara är ett verktyg för att få den andra personen att må bättre.
Lyckligtvis fungerar det bättre också.
Radical Candor: Feedbackmetoden som fungerar bättre för mjukvaruutvecklare
Istället för att packa in din feedback från ett personligt möte i en feedbackmacka rekommenderar jag att du använder metoden Radical Candor som grund för din feedbackmall. För övrigt är den inte bara användbar inom IT-branschen, utan även inom den privata sektorn – låt oss gå djupare.
Radical Candour innebär att ge så ärlig och direkt feedback som möjligt i medarbetarsamtalet. Samtidigt innebär det också att visa empati och fokusera på den andra personens välbefinnande. Radical Candor visar att man inte behöver välja det ena eller det andra: Antingen direkt och ärlig eller empatisk och omtänksam. Istället kan du göra båda samtidigt:
Mer under: Vad är radikal uppriktighet?
Mjukvaruutvecklare kommer att vara tacksamma om du går rakt på sak med negativ feedback.
Feedbackmall för mjukvaruutvecklare baserad på Radical Candor
Den här mallen bygger på SBI-modellen (Situation, Beteende, Inverkan). Den hjälper dig att kommunicera på ett uppriktigt, direkt och samtidigt uppskattande sätt.
Se även "Playbook för att ge feedback"
Här följer instruktioner för de enskilda delarna av feedbackmallen:
Feedbackmall del 1: Förberedelser i förväg
Innan du ger feedback bör du ta några minuter på dig att tänka igenom följande punkter:
- Situation: Vilken situation är det du specifikt syftar på?
- Beteende: Vilket beteende observerade du hos personen?
- Påverkan: Vilken påverkan hade personens beteende (på dig och andra)?
- Önskemål: Vilket tillstånd skulle du vilja uppnå och varför? (Obs: Det här handlar inte om att direkt önska ett specifikt beteende – detta är en del av åtgärden (se nedan). Det handlar snarare om det bredare sammanhanget där du förstår varför effekten är ett problem för dig).
- Åtgärd: Vilka förslag har du till personen? Vilka förändringar i beteendet skulle kunna föra oss närmare måltillståndet? Vilket stöd kan du erbjuda?
Det är bäst att skriva ner punkterna kortfattat så att du inte glömmer något under samtalet.
Feedbackmall del 2: Inleda samtalet
I stället för att börja med en lång feedbackmacka i ett enskilt möte kan du nu börja direkt med situationen som en samtalsstart:
- "Jag ville prata med dig om situationen när vi..."
Beskriv situationen och fråga sedan:
- "Minns du fortfarande situationen?"
Feedbackmall del 3: Beteende
Därefter kan du ta upp personens beteende som du har observerat under medarbetarsamtalet:
- "Du skakade på huvudet åt situationen och sa..."
Innan du talar om effekten ska du ge den andra personen möjlighet att kommentera din uppfattning eller ditt minne:
- "Återger jag det här på rätt sätt ur din synvinkel?"
Ge personen utrymme att beskriva sitt perspektiv på saker och ting. Försök att låta båda perspektiven stå i rummet på lika villkor utan att kommentera dem. Begränsa dig till att ställa frågor om innehållet i den andra personens perspektiv.
Feedbackmall del 4: Påverkan
Det är först i denna del som det handlar om att diskutera effekterna av beteendet. Håll dig så objektiv som möjligt till en början:
- "Mitt intryck var att min kollega Marc efter ditt [observerade beteende] verkade mycket förolämpad och inte längre ville fortsätta att samarbeta med oss."
Men om effekterna också påverkar dig är det viktigt att dela med sig av detta också. Naturligtvis ska du alltid vara professionell, men du kan också visa din mänskliga sida:
- "Jag blev själv uppriktigt generad i den situationen och jag tyckte att samtalet var obehagligt från och med då."
Feedbackmall del 5: Önskemål
Uttryck din specifika begäran i denna del av medarbetarsamtalet:
- "Det är viktigt för mig att vi hittar en bra grund för samarbete med vår kollega Marc igen."
Sätt in det i sitt sammanhang igen:
- "Och utöver det är det ett stort behov för mig att vi arbetar tillsammans för att säkerställa att vi upprätthåller ett gott samarbete och goda relationer med alla angränsande specialistområden."
Hänvisa också till relevanta mål som förklarar varför du har denna önskan:
- "Det är bara genom en god relation som vi kan nå våra mål som ett team i det här företaget. Det är också viktigt för mig att vi har ett gott rykte som team inom företaget."
Feedbackmall del 6: Mätning
Innan du presenterar dina egna lösningsidéer kan du ställa öppna frågor i det enskilda samtalet:
- "Jag har några idéer om det här. Men jag skulle vilja höra din åsikt först: Hur tror du att vi kan uppnå målet?"
Ni kan sedan dela med er av era idéer. Kom överens om en bindande och specifikt definierad uppföljning tillsammans. Dokumentera detta skriftligen.
Feedbackmall del 7: Avslag
Fråga om medarbetarsamtalet var till hjälp för den andra personen och om det finns några obesvarade frågor. Stäm av nästa gång ni ska prata om ämnet.
Visa din uppskattning för den öppna dialogen och tacka personen för hans eller hennes insikter och samarbete.
Feedbackmall del 8: Reflektera över din feedback i efterhand
I slutet av varje återkopplingssession bör du ställa dig själv följande fråga:
- Ärlighet: Har jag delat med mig av min feedback på ett ärligt och så osminkat sätt som möjligt?
- Uppskattning: Känner sig personen uppskattad av min feedback?
Om du kan svara "ja" på alla frågorna gick din feedback-session mycket bra. Om inte, var inte orolig. Reflektera över hur du kan formulera dig annorlunda i framtiden. Och återigen, de flesta av dessa tips gäller inte bara för mjukvaru-IT-branschen.
Här vill jag påpeka att det naturligtvis också finns programvara för att förenkla motsvarande feedbackdiskussioner och även mer långsiktig coachning av mjukvaruutvecklare.
Vår programvara för enskilda möten erbjuder dig olika mallar för medarbetarsamtal med mjukvaruutvecklare och gör till och med medarbetarutveckling mätbar. Ta en titt på vårt verktyg och prova följande mall:
1:1 Mötesverktyg Mall: Stämning som väder
- Om du skulle beskriva ditt känslomässiga tillstånd som vädret, hur är vädret i ditt projekt eller dina arbetsuppgifter just nu?
Hur är vädret i förhållande till din arbetsgivare, ditt privatliv och ditt privatliv?
Verktyg för 1:1-möten Mall: Kommunikation
Var ser du ditt team: Hur fördelas bidragen?
Var ser du dig själv? Vilken roll spelar du, beroende på mötet?
Vad skulle vara ett första steg för att se till att bidragen fördelas jämnare inom teamet?
Verktyg för 1:1-möten Mall: Misslyckas framåt
När hade du senast en känsla av att du hade gjort ett misstag med något?
Hur reagerade du på det här misstaget?
Vad skulle vara en konstruktiv syn på detta "misstag"?
Vilka är de nästa viktiga misstagen du behöver göra för att komma närmare dina mål?
Verktygsmall för 1:1-möten: Lär dig av de bästa
Vem i ditt team ser du upp till och varför?
Vad är det du vill lära dig när du tänker på dina kollegor i och utanför bolaget?
Ta kontakt med de personer som du vill lära dig av.
Verktyg för 1:1-möten Mall: Konflikttyper
Nämn en konflikt som du nyligen hade i ditt team.
Ta en titt på de 5 olika konfliktstilarna: Kan ditt beteende och din attityd klassificeras enligt en eller flera av konfliktstilarna?
Hur kunde du ha hanterat konflikten på ett bättre sätt?
Låt oss nu komma igång med hjälp av denna mall för medarbetarsamtal och gå igenom några praktiska exempel!
Exempel på feedback till mjukvaruutvecklare i enskilda möten
Exempel på feedback till mjukvaruutvecklare i 1 till 1-möten: Kodkvalitet
Med Tanja 👩🏼🦰 i rollen som teamleader och Marc 👨🏽 i rollen som medarbetare.
Beskriv situationen
👩🏼🦰
Tanja (Team Lead): "I vår senaste kodgranskning tittade vi på din pull request för att implementera den nya funktionen i instrumentpanelen. Koden var funktionellt korrekt och uppfyllde kraven."
👨🏽
Marc (anställd): "Ja, det minns jag!"
Observerat beteende
👩🏼🦰
"Jag kommenterade avsnitt som var ganska komplexa och svåra att läsa. Till exempel fanns det en metod med över 50 rader som kombinerade flera ansvarsområden. Men du kommenterade bara den kommentaren ytligt och gick inte in på den mer."
👨🏽
"För mig lät kommentaren som ett valfritt förslag. Det verkade för tidskrävande att ändra lösningen igen."
Påverkan
👩🏼🦰
"Hur som helst, din kommentar gjorde mig lite frustrerad för att vara ärlig och istället för att insistera på en lösning från dig förbättrade jag bara metoden själv efteråt eftersom jag ändå redan hade tänkt mig in i koden."
👨🏽
"Åh, det visste jag inte."
Mål och önskan
👩🏼🦰
"Vårt gemensamma mål är att vår kod inte bara ska vara funktionell, utan också underhållbar och lätt att förstå för alla."
👨🏽
"Det är precis så jag ser det!"
Mått
👩🏼🦰
"Vad är ditt förslag på hur vi kan förbättra kvaliteten på koden på ett smidigare sätt i sådana här fall i framtiden?"
👨🏽
"Det skulle hjälpa mig om det var lättare att se i kommentarerna om en förbättring bara föreslås eller krävs."
👩🏼🦰
"Ja, vi gör det – Jag tar med det i teamets möte igen. Men jag tycker fortfarande att du måste följa upp din egen sida också."
👨🏽
"Vad sägs om att vi går direkt till parprogrammering tillsammans i nästa ämne så att du kan skärpa min förståelse för kraven på kodkvalitet?"
Slutsats
👩🏼🦰
"Det låter som två bra uppföljningar! Då håller vi det på det sättet. Jag skulle vilja sätta ett datum i min dagbok i mitten av nästa vecka för att börja med parprogrammeringen."
👨🏽
"Okej, jag ser fram emot det!"
Exempel på feedback till mjukvaruutvecklare i 1 till 1-möten: Ägarskap
Med Tanja 👩🏼🦰 i rollen som teamleader och Marc 👨🏽 i rollen som medarbetare.
Beskriv situationen
👩🏼🦰
Tanja (Team Lead): "Marc, jag vill prata med dig om den senaste uppgiften där vi utvecklade den nya funktionen för exportprocessen. Funktionen är nu live, men det fanns några utmaningar längs vägen."
👨🏽
Marc (anställd): "Ja, det minns jag. Vad exakt menar du?"
Observerat beteende
👩🏼🦰
"Jag märkte att det förekom flera långa förseningar efter att koden hade överlämnats för testning. Till exempel besvarades vissa kommentarer från QA-kollegor inte på flera dagar. Det hände också att jag var tvungen att påminna dig två gånger om en saknad granskning."
👨🏽
"Hmm, jag förstår. Ärligt talat var det ganska mycket som pågick och jag trodde att testerna skulle fortsätta parallellt."
Påverkan
👩🏼🦰
"Jag märkte att det förekom flera långa förseningar efter att koden hade överlämnats för testning. Till exempel besvarades vissa kommentarer från QA-kollegor inte på flera dagar. Det hände också att jag var tvungen att påminna dig två gånger om en saknad granskning."
👨🏽
"Åh, det visste jag inte ens. Jag trodde att du skulle höra av dig om det var något brådskande."
Mål och önskan
👩🏼🦰
"Vårt mål är att minimera onödiga förseningar och att utvecklarna ska ha ett ägarskapstänk under implementeringen. Det innebär att alla aktivt ser till att deras ärende går igenom från början till slut – och det inkluderar även kommunikation med QA."
👨🏽
"Jag förstår vad du menar. Jag vill definitivt att processerna ska löpa smidigare."
Mått
👩🏼🦰
"Från ditt perspektiv, vad kan vi göra för att du ska kunna agera mer proaktivt och visa ägarskap i sådana situationer?"
👨🏽
"Jag tror att det skulle hjälpa om vi satte upp tydligare förväntningar, till exempel att jag gör en daglig check-in på öppna frågor under testfasen. På så sätt kan jag se till att inget lämnas ogjort."
👩🏼🦰
"Det låter bra. Och jag skulle föreslå att du för nästa stora uppgift efter att koden har slutförts gör en kort plan för hur du vill följa ämnet fram till lanseringen i realtid. Du kan visa planen för mig eller en QA-kollega."
👨🏽
"Jag håller med. Då kan jag själv hålla ett bättre öga på saker och ting."
Slutsats
👩🏼🦰
"Jättebra. Låt oss registrera de två åtgärderna så här: Du gör dagliga avstämningar under testfasen och planerar uppföljningen för din nästa stora uppgift. Är det genomförbart för dig?"
👨🏽
"Ja, det passar. Jag ska skriva det direkt i min dagbok."
👩🏼🦰
"Jättebra. Jag är säker på att det kommer att göra stor skillnad. I vårt nästa personliga möte ska vi titta på statusen för våra åtgärder igen. Tack så mycket!"
Exempel på feedback till mjukvaruutvecklare i utvecklingssamtalet
En anmärkning: Traditionella utvecklingssamtal tenderar att vara impopulära bland både mjukvaruutvecklare och chefer, och många hävdar att bra personliga möten är tillräckliga och bör ersätta utvecklingssamtalen. Se här: "Utvecklingssamtal är meningslösa och förolämpande" by Forbes
Medarbetarsamtalen är dock ofta fortfarande ett förutbestämt format inom företaget. Detta ska naturligtvis inte hindra dig från att genomföra utvecklingssamtal som en dialog i ögonhöjd med dina medarbetare istället för att begränsa dig till att göra bedömningar uppifrån och ned. Följande exempel på en-till-en-dialog visar hur det kan fungera.
Exempel på feedback till mjukvaruingenjörer i utvecklingssamtal: Teamarbete
Med Tanja 👩🏼🦰 i rollen som Team Lead och Marc 👨🏽 i rollen som Software Engineer.
Beskriv situationen
👩🏼🦰
Tanja (teamledare): "När jag skulle betygsätta punkten 'Teamarbete' i din mall för medarbetarsamtal kunde jag tyvärr bara ge dig 5 av 10 möjliga poäng. Jag skulle vilja förklara detta för dig för att ge dig en rättvis chans att förbättra dig på denna punkt."
👨🏽
Marc (anställd): "Åh, okej. Snälla hjälp mig att förstå."
Observerat beteende
👩🏼🦰
"Jag har märkt att det har funnits situationer under de senaste månaderna där samarbetet med teamet inte har varit optimalt. I vår senaste sprint fanns det till exempel flera fall där du arbetade med uppgifter på egen hand, trots att de kunde ha lösts bättre tillsammans med andra. Ett specifikt exempel var integrationen av det nya API:et. Vi hade övervägt att låta dig och Alex arbeta med det tillsammans, men du tog dig an de flesta stegen på egen hand och involverade bara Alex minimalt."
👨🏽
"Jag trodde att det skulle vara mer effektivt att göra det snabbt själv. Jag insåg inte att det sågs som ett problem."
Påverkan
👩🏼🦰
"Detta ledde dock till en förlust av transparens i teamet. Alex hade senare svårt att engagera sig i relaterade uppgifter eftersom han inte visste exakt hur API:et var uppbyggt. Jag fick också feedback från andra teammedlemmar att de ibland inte kände sig tillräckligt involverade och tyckte att det var svårt att få stöd från dig när de hade frågor."
👨🏽
"Det förvånar mig, om jag ska vara ärlig. Jag trodde att jag skulle hjälpa till när jag blev tillfrågad."
Mål och önskan
👩🏼🦰
"Vårt mål som team är inte bara att arbeta effektivt, utan också att dela med oss av kunskap och involvera alla. Det stärker samarbetet och gör att vi alla kan företräda varandra. I framtiden skulle jag vilja att du i större utsträckning utnyttjar din roll som kunskapsbärare i det här teamet för att aktivt dela med dig av kunskap och stärka andra teammedlemmar. Teamets produktivitet är viktigare än den individuella prestationen."
👨🏽
"Okej, jag förstår vad du menar. Jag tror bara att jag har fokuserat för mycket på min egen produktivitet hittills."
Mått
👩🏼🦰
"Vad skulle kunna hjälpa dig att ägna mer uppmärksamhet åt att involvera teamet i ditt arbete och dela med dig av kunskap?"
👨🏽
"Jag skulle kunna ta för vana att redan från början klargöra vem som får arbeta med större uppgifter och hur. Kanske skulle vi också kunna ha något som liknar en kick-off för uppgifter för att komma överens om de stora arkitekturella besluten och identifiera uppgifter som någon annan bör göra ensam eller som vi till och med bör göra i parprogrammering."
👩🏼🦰
"Det låter bra. Jag fick också en idé: vad sägs om att du tar för vana att inte bara rapportera framsteg vid våra veckomöten, utan också aktivt ge insikter i koden och arkitektoniska beslut?"
👨🏽
"Det är en bra poäng. Det skulle kunna göra det lättare för våra oerfarna kollegor att arbeta med min kod senare."
Slutsats
👩🏼🦰
"Jättebra. Sedan antecknar vi uppföljningarna i vår mall för utvecklingssamtalet:
- Från och med nu kommer du att proaktivt dela med dig av dina kunskaper och arkitektoniska beslut till teamet i veckorna.
- Från och med nu kommer du att starta dina ämnen med en annan utvecklare så att ni kan arbeta fram lösningen tillsammans och dela upp implementeringen."
👨🏽
"Låter bra."
👩🏼🦰
"OKEJ. Jag skulle notera båda åtgärderna för en genomgång om två månader. Då kan vi diskutera statusen i vårt enskilda möte och se hur vi går vidare."
👨🏽
"Ja, och låt oss också se om du inte kan förbättra din poäng för 'teamwork'. Jag skulle vilja få minst 8 av 10."
👩🏼🦰
"Det gläder mig att höra! Jag tror absolut att det är realistiskt och kommer att stödja dig så gott jag kan."
👨🏽
"Tack så mycket!"
Exempel på feedback till Software Engineers Performance Reviews: Ägarskap
Låt oss gå vidare till nästa exempel på en en-till-en-konversation, som handlar om feedback till programvaruutvecklaren om ämnet ägande.
Som alltid med Tanja 👩🏼🦰 i rollen som Team Lead och Marc 👨🏽 i rollen som Software Engineer.
Beskriv situationen
👩🏼🦰
Tanja (teamledare): "När jag skulle sätta betyg på punkten "Ägarskap" i din mall för medarbetarsamtal kunde jag bara ge dig 6 av 10 poäng. Jag skulle vilja förklara varför det är så och ge dig chansen att utvecklas ytterligare inom det här området."
👨🏽
Marc (anställd): "Oj, det förvånar mig lite. Jag har ju trots allt arbetat med fler ämnen än nästan någon annan i teamet. Var snäll och förklara det för mig."
Observerat beteende
👩🏼🦰
"Under de senaste månaderna har jag märkt att det ofta uppstår förseningar i era uppgifter. Det finns flera exempel där QA-kommentarer eller kodgranskningar har förblivit obesvarade av dig under en lång tidsperiod. Som ett resultat av detta har era ämnen inte kunnat tas i drift förrän efter flera veckors förseningar. Ett specifikt exempel var buggfixningen för exporten. Du svarade på feedback från QA först efter upprepade förfrågningar, och det tog totalt tre veckor innan ändringarna gick live."
👨🏽
"Ja, det minns jag. Jag jobbade med två andra ämnen samtidigt och hann inte skriva in feedbacken så snabbt."
Påverkan
👩🏼🦰
"Detta påverkade hastigheten och produktiviteten i hela teamet. QA var tvungna att följa upp flera gånger, vilket tog upp deras kapacitet. Releaseplanen fick också skjutas upp. Dessutom känns det som om du inte tar fullt ansvar för att slutföra dina frågor, vilket sätter press på teamdynamiken. Vissa teammedlemmar har berättat för mig att de känner sig osäkra på om de kan lita på dig när det gäller beroenden."
👨🏽
"Åh, jag är ledsen för det. Det insåg jag inte. Jag försökte göra uppgifterna parallellt, men det fungerade tydligen inte så bra."
Mål och önskan
👩🏼🦰
"Mitt mål är att du ska fokusera på färre ämnen, men att du ska ta fullt ansvar för varje uppgift från början till slut. Det innebär att du inte bara skriver den första koden, utan också ser till att QA-feedback behandlas snabbt och att ämnet håller tidsplanen. På så sätt kan vi undvika att uppgifter förblir öppna under längre tid och blockerar andra."
👨🏽
"Det låter logiskt. Jag kände mig ofta överväldigad eftersom jag hade för många ämnen på gång samtidigt. Kanske är det verkligen bättre att koncentrera sig på färre uppgifter."
Mått
👩🏼🦰
"Hur skulle vi kunna få dig att fokusera på några få ämnen och ta ansvar för att genomföra dem fullt ut?"
👨🏽
"Jag kan försöka begränsa mig till högst två ämnen per sprint och aldrig arbeta med mer än tre ämnen samtidigt. Jag bör också blockera fasta tider i min kalender för att regelbundet arbeta med kommentarer och granskningar så att inget glöms bort."
👩🏼🦰
"Det låter vettigt. Dessutom tror jag att det skulle vara bra om man proaktivt kunde be om hjälp i våra stand-ups om man arbetar med för många ämnen samtidigt. Det borde oftast finnas någon som kan ta över ett ämne från dig."
👨🏽
"Okej, det är rättvist."
Slutsats
👩🏼🦰
"Låt oss sätta dessa mått som mål för de kommande två månaderna:
Mindre arbete parallellt:
- Du tar dig an maximalt två ämnen per sprint och arbetar inte med mer än tre ämnen parallellt.
- Kräva aktivt stöd från teamet vid stand-ups
- Fasta tider i kalendern för att arbeta igenom kommentarer och recensioner."
👨🏽
"Det låter realistiskt. Låt oss göra det på det sättet."
👩🏼🦰
"Jättebra. Vi kan se om två månader i utvecklingssamtalet om de här åtgärderna har fungerat och om vi kan höja ditt betyg i utvecklingssamtalet till 'Ownership' igen."
👨🏽
"Tack så mycket, Tanja. Jag ska försöka omsätta det i praktiken. Jag brukade alltid få toppbetyg för 'Ownership'. Tror du att jag kommer att få det igen vid nästa medarbetarsamtal?"
👩🏼🦰
"Det gläder mig. Ja, jag tror att en snabb förbättring absolut är möjlig med dessa åtgärder. Låt oss diskutera status och om du behöver stöd i våra personliga möten varannan vecka."
👨🏽
"Tack så mycket! Ja, det skulle glädja mig mycket om vi kunde uppnå en märkbar förbättring här inom några veckor!"
Exempel på feedback till mjukvaruutvecklare i den årliga utvärderingen
Om du redan har regelbundna enskilda möten eller utvecklingssamtal med dina utvecklare under året, behöver du förmodligen inte längre ha detaljerade årliga möten. Utbytet om prestationer, feedback och vidareutveckling bör redan vara en pågående dialog:
Det finns dock företag som kräver en klassisk årlig utvärdering.
💡
Om du som chef för mjukvaruutvecklare redan har regelbundna 1:1-möten eller utvecklingssamtal bör den årliga utvärderingen bara vara en formalitet:
Programvaruutvecklaren bör redan vara medveten om feedbacken och bör redan arbeta med utvecklingspotentialen.
Så om du som chef för programvaruutvecklare måste uppfylla formalian med ett möte i slutet av året (eventuellt utöver regelbundna personliga möten), låt oss också gå igenom ett exempel på ett årligt medarbetarsamtal med en programvaruutvecklare.
Exempel på agenda och mall för ett årligt möte med en mjukvaruutvecklare
Granskning och resultat
Framgångar: Vilka projekt eller uppgifter gick bra? Var överträffades förväntningarna?Utmaningar: Vad fungerade inte så bra, och varför? Hur kan dessa utmaningar övervinnas i framtiden?Reflektion: Hur ser utvecklaren på sin egen prestation? Vilken feedback har teamet eller chefen?
Samarbete och teamkultur
Kommunikation: Hur upplevs samarbetet inom teamet och med chefen?Arbetsklimat: Finns det förbättringspotential i teamkulturen eller arbetsmiljön?Feedback om ledarskap: Hur kan chefen bättre stödja utvecklaren?Feedback från utvecklaren: Finns det några förslag på hur man kan förbättra processer, verktyg eller arbetskulturen?Balans mellan arbete och privatliv: Vad tycker du om din nuvarande arbetsbelastning? Finns det några övertids- eller stressfaktorer?Resurser: Är verktygen, processerna och ramvillkoren tillräckliga för ett effektivt arbete?
Kompetens, mål och utveckling
Styrkor: Vilka tekniska, metodologiska eller sociala färdigheter kännetecknar utvecklaren?Ytterligare utbildning: Vilka nya tekniker eller färdigheter vill utvecklaren lära sig? Finns det några relevanta kurser, konferenser eller projekt?Karriärmål: Vilken position eller vilket ansvar siktar utvecklaren på att få på medellång till lång sikt? Vilka steg leder dit?Projektfokus: Vilka projekt eller tekniker skulle utvecklaren vilja arbeta mer intensivt med?
Ersättning
Prestationsrelaterad ersättning: Finns det behov av att justera lön eller bonusar?
Slutsats
Kortsiktiga mål: Vilka specifika mål bör sättas upp för det kommande året?Överenskommelser: Vilka är de kommande kontrollpunkterna för respektive åtgärd?
Följande är ett typiskt exempel på återkoppling inom ramen för en utvärdering i slutet av året eller ett årligt utvecklingssamtal: Medarbetarens begäran om en rollförändring.
Exempel på återkoppling i årsmötet: Önskan om rollförändring
Med Tanja 👩🏼🦰 i rollen som Team Lead och Marc 👨🏽 i rollen som Software Engineer.
Inträde och situation
👩🏼🦰
Tanja (Team Lead): "Marc, det är fantastiskt att vi kan prata om din årliga feedback och dina mål idag. Är det några specifika ämnen som är särskilt viktiga för dig?"
👨🏽
Marc (anställd): "Ja, jag har funderat på min fortsatta utveckling. Jag skulle kunna tänka mig att utvecklas i riktning mot mjukvaruarkitektur. Jag har länge varit intresserad av ämnet och jag skulle vilja bli mer involverad i arkitekturbeslut och strategisk teknikhantering."
👩🏼🦰
"Det är spännande, Marc. Det gläder mig att du har så tydliga mål. Låt oss prata om hur vi kan förbereda dig för dem. Det finns några punkter där jag tror att du behöver utvecklas ytterligare innan vi tar nästa steg."
Ge feedback
👩🏼🦰
"För det första vill jag understryka att ni har gjort stora framsteg under året, särskilt när det gäller kvaliteten på era implementeringar och hanteringen av ny teknik. Ni har också visat att ni har ett öga för helheten, t.ex. genom införandet av det nya cachningssystemet."
👨🏽
"Tack, det gläder mig att höra!"
👩🏼🦰
"När jag tänker på rollen som mjukvaruarkitekt finns det dock fortfarande en del krav som jag inte tror uppfylls fullt ut i dag. Till exempel är kommunikation med teamet och att involvera andra i tekniska beslut en nyckelkomponent. Där ser jag fortfarande potential för dig. Du fattar ofta beslut på egen hand utan att involvera teamet tillräckligt tidigt."
👨🏽
"Okej, jag förstår det. Jag ville inte hålla upp någon ibland, men jag inser att det inte är idealiskt för rollen som arkitekt."
Mål och önskan
👩🏼🦰
"Exakt så är det. En mjukvaruarkitekt är också en coach och kommunikatör. Det handlar om att få med sig andra, att kommunicera tekniska koncept och att utveckla lösningar tillsammans."
👨🏽
"Det låter vettigt. Jag inser också att jag ännu inte kan förmedla mina tankar om arkitektur till mina medarbetare på ett lika effektivt sätt."
Planera åtgärder
👩🏼🦰
"Jag tror att vi kan arbeta tillsammans med detta så att du kvalificerar dig för rollen inom de närmaste 6 månaderna. Vad sägs om att vi definierar konkreta åtgärder?"
👨🏽
"Det skulle jag gärna göra. Vad har du i åtanke?"
👩🏼🦰
"Framför allt skulle jag vilja se dig som moderator i beslutsprocessen för programvaruarkitekturen i stället för att själv fatta besluten. Vad sägs om att moderera en arkitekturkick-off för vart och ett av de kommande huvudämnena? Syftet skulle vara att stötta kollegorna i beslutsprocessen och sedan låta dem själva implementera lösningen."
👨🏽
"Det låter bra. Jag lär mig att utöva mitt inflytande som coach i stället för att genomföra allt själv."
👩🏼🦰
"Jag kan också tänka mig att det finns bra kurser som förbereder utvecklare för rollen som mjukvaruarkitekt. Förutom de hårda färdigheterna kommer dessa kurser säkert också att täcka de mjuka färdigheter som krävs för rollen."
👨🏽
"Ja, jag har faktiskt redan valt ut en kurs."
Slutsats
👩🏼🦰
"Bra, då noterar jag följande till vårt årsmöte:
- Utvecklingsmål: Programvaruarkitekt
- Mått:
- Moderering av kick-offs för arkitektur i ett team
- Deltagande i en kurs för mjukvaruarkitekter
Vi pratar naturligtvis om dessa ämnen kontinuerligt i våra personliga möten, men nästa officiella avstämning är vid vårt utvecklingssamtal om tre månader."
👨🏽
"Låter bra. Vi borde ha hunnit med en hel del då."
👩🏼🦰
"Det tycker jag också! Om du under tiden kommer på något annat som jag kan göra för att stödja dig i det här arbetet, är du välkommen att kontakta mig när som helst."
👨🏽
"Kan vi prata om mitt planerade rollbyte igen om tre månader?"
👩🏼🦰
"Visst, jag kan naturligtvis inte lova dig något när det gäller att byta roller. Men jag har noterat din önskan och ska försöka stötta dig så gott jag kan."
👨🏽
"Tack så mycket!"
Slutsats: Motiverande feedback för programvaruutvecklare
Exemplen och mallarna visar att det inte behöver vara så svårt att ge motiverande feedback till mjukvaruutvecklare i enskilda möten och vid årsslutsmöten, eller hur? Förbli autentisk och välvillig, gå inte runt busken och visa att du är intresserad av en gemensam lösning.
Om du lyckas implementera "Radical Candour" i dina medarbetarsamtal och därefter genom att visa uppskattning och ärlighet, kan reaktionen till och med bli mer positiv och konstruktiv än du tror.
Lycka till med nästa feedback-session!
Och om du gillar hacks som gör ditt liv enklare rekommenderar jag vår Echometer-programvara. Du kan prova den helt kostnadsfritt.
Vår programvara för enskilda möten erbjuder dig olika mallar för medarbetarsamtal med mjukvaruutvecklare och gör till och med medarbetarutveckling mätbar. Ta en titt på vårt verktyg och prova följande mall:
1:1 Mötesverktyg Mall: Stämning som väder
- Om du skulle beskriva ditt känslomässiga tillstånd som vädret, hur är vädret i ditt projekt eller dina arbetsuppgifter just nu?
Hur är vädret i förhållande till din arbetsgivare, ditt privatliv och ditt privatliv?
Verktyg för 1:1-möten Mall: Kommunikation
Var ser du ditt team: Hur fördelas bidragen?
Var ser du dig själv? Vilken roll spelar du, beroende på mötet?
Vad skulle vara ett första steg för att se till att bidragen fördelas jämnare inom teamet?
Verktyg för 1:1-möten Mall: Misslyckas framåt
När hade du senast en känsla av att du hade gjort ett misstag med något?
Hur reagerade du på det här misstaget?
Vad skulle vara en konstruktiv syn på detta "misstag"?
Vilka är de nästa viktiga misstagen du behöver göra för att komma närmare dina mål?
Verktygsmall för 1:1-möten: Lär dig av de bästa
Vem i ditt team ser du upp till och varför?
Vad är det du vill lära dig när du tänker på dina kollegor i och utanför bolaget?
Ta kontakt med de personer som du vill lära dig av.
Verktyg för 1:1-möten Mall: Konflikttyper
Nämn en konflikt som du nyligen hade i ditt team.
Ta en titt på de 5 olika konfliktstilarna: Kan ditt beteende och din attityd klassificeras enligt en eller flera av konfliktstilarna?
Hur kunde du ha hanterat konflikten på ett bättre sätt?
