Functioneringsgesprek softwareontwikkelaar: 6 feedback voorbeelden
Concreet feedback over prestaties, vaak in de vorm van ‘Performance Reviews’, spelen een centrale rol in de verdere ontwikkeling van softwareontwikkelaars. In dit artikel laten we een paar praktische voorbeelden zien van hoe je feedback aan softwareontwikkelaars kunt geven in verschillende situaties, zoals functioneringsgesprekken, jaarlijkse beoordelingen of prestatiebeoordelingen - dus in elke vorm van een-op-eengesprek en contact.
Belang van feedback voor softwareontwikkelaars
Waarom is feedback zo belangrijk (en moeilijk) voor softwareontwikkelaars\*innen?
Motiverende feedback voor introverte softwareontwikkelaars
Softwareontwikkelaars zijn traditioneel meer geïnteresseerd in het werken met technische details dan in het werken met andere mensen. Het kan daarom een uitdaging zijn voor managers om feedback op een effectieve en motiverende manier te communiceren, vooral met meer introverte softwareontwikkelaars.
Als manager van softwareontwikkelaars moet je echter leren om zowel positieve als negatieve feedback op een constructieve manier te communiceren tijdens beoordelingsgesprekken, zodat de softwareontwikkelaars daadwerkelijk gemotiveerd zijn om het geïdentificeerde ontwikkelingspotentieel te realiseren. De volgende voorbeelden van feedback in dit artikel helpen je daarbij.
Als je geïnteresseerd bent in een algemene inleiding tot regelmatige één-op-één gesprekken, bekijk dan ons bericht over dit onderwerp: Een handleiding: 6 tips voor succesvolle 1-op-1 gesprekken.
Let op: Softwareontwikkelaars individueel beoordelen
Ter informatie: Studies tonen aan dat softwareontwikkelaars van oudsher meer introvert zijn. De trend gaat echter in de richting van meer verschillende persoonlijkheidstypes onder softwareontwikkelaars. Je moet daarom altijd goed onderzoeken en inschatten welk persoonlijkheidstype tegenover je zit en dienovereenkomstig communiceren.
Bron: Evolutie van het persoonlijkheidsprofiel van software-ingenieurs
Feedback: Vragen en enquêtes
Vragen en een enquête voor feedbackgesprekken
Beoordelingsgesprek softwareontwikkelaar: typische vragen
Een opmerking voordat ik je veel voorbeelden, sjablonen en zinnen geef voor je functioneringsgesprek met de softwareontwikkelaar: uiteraard is het in veel situaties zinvol om vragen te stellen om eerst het gemeenschappelijke begrip van de status quo te controleren - niet alleen in de IT-industrie.
Daarom heb ik een aantal vragen samengesteld voor personeelsbeoordelingen met softwareontwikkelaars:
🎯 1-op-1 vragen voor softwareontwikkelaars: Focus
- Wat onderbreekt je concentratie tijdens het werk?
- Wanneer heb je voor het laatst een flow-toestand ervaren tijdens het werk? Hoe gemakkelijk is het voor jou om in de flow te komen?
- Wanneer en waaraan heb je gemerkt dat je je persoonlijke 'Work In Progress Limit' hebt overschreden? Wat zouden we kunnen veranderen om je in de toekomst te helpen een passend WIP te bereiken?
- Hoe zijn de spreekbeurten in het team verdeeld? Hoe reflecteer je op je rol daarin?
- Wie zijn onze klanten als bedrijf en hoe draagt jouw werk specifiek bij aan het voldoen aan de behoeften van de klanten?
- Wat zijn de dingen die je wilt leren als je aan je collega's in het bedrijf en daarbuiten denkt?
Dit zou je een goed idee moeten geven van hoe je zo’n beoordelingsgesprek slim kunt aanpakken. Als je ook een specifieke enquête wilt, kan ik je een eerste sjabloon geven.
Beoordelingsgesprek met softwareontwikkelaars: een onderzoek
Overeenkomstige onderzoeken kunnen helpen om de ontwikkeling van softwareontwikkelaars in de loop van de tijd meetbaar te maken.
Ze kunnen echter ook heel goed dienen als interactieve basis voor een gezamenlijke discussie.
De volgende enquête richt zich op vier verschillende gebieden die belangrijk zijn voor softwareontwikkelaars. Deze stellingen worden meestal beoordeeld op een schaal van bijvoorbeeld 1 (helemaal mee oneens) tot 7 (helemaal mee eens).
🪞Enquête functioneringsgesprek: Voor softwareontwikkelaars
- Ik stel onze werkwijze kritisch ter discussie op basis van mijn begrip van onze #TeamDoelen en de behoeften van onze #Klanten.
- Ik draag proactief bij aan de continue verbetering van ons team. #TeamPlay
- Ik ken de uitdagingen en problemen van onze #Klanten.
- Mijn werkzaamheden boeken over het algemeen zeer snel vooruitgang, zelfs als externe #Feedback noodzakelijk is.
Opmerking: bij dit sjabloon voor functioneringsgesprekken wordt de instemming met de Health Check-items (vragenlijst) gevraagd op een schaal van 1-7.
In de Echometer One-on-One software vind je, zoals gezegd, veel sjablonen die helpen om medewerkers in functioneringsgesprekken verder te ontwikkelen. Vooral voor agile teams zijn er ook sjablonen die deels interactief en visueel zijn vormgegeven. Een eenvoudig voorbeeld hiervan vind je hier - bekijk gerust ook eens onze tool via de knop hieronder.
Eén-op-één gespreksjabloon Echometer Software
- Kijk eens naar de hier aangegeven gebieden. Waar hebben zowel jij als je team volgens jou het grootste verbeterpotentieel?
Bron: Echometer 1:1 Meeting Software
Zoals je aan de groene knop kunt zien, kun je deze sjablonen zelfs gratis gebruiken in onze 1-op-1 vergadertool Echometer. We hebben ook nog veel meer sjablonen voor vragen en hele coaching sjablonen.
In onze blog staat een ander artikel, voor het geval je interesse hebt in gedetailleerde sjablonen voor verschillende een-op-een gesprekken (bijv. wekelijks, jaarlijks, 1-1 met moeilijke medewerkers…): 15 beproefde sjablonen voor 1-1 vergaderingen om te bewerken (gratis) .
Maar nu verder met de tekst - laten we overgaan op concrete voorbeelden en zinnen voor feedback aan softwareontwikkelaars.
Sjabloon voor feedback aan softwareontwikkelaars
Algemeen sjabloon voor feedback aan softwareontwikkelaars
Vermijd klassieke feedbackmethoden zoals de feedback sandwich
Vaak zijn sjablonen voor feedback in een-op-een gesprekken gebaseerd op de sandwichmethode. Vermijd deze alstublieft bij softwareontwikkelaars. Het “gepraat eromheen” in functioneringsgesprekken helpt niemand verder en vooral softwareontwikkelaars reageren vaak allergisch op dergelijke methoden (zie: Kritiek op de sandwichmethode voor feedback).
Softwareontwikkelaars realiseren zich meestal wanneer managers algemene positieve feedback geven dat dit slechts een middel is om de ander zich beter te laten voelen.
Gelukkig is dat ook beter.
Radicale openheid: de feedbackmethode die beter werkt voor softwareontwikkelaars
In plaats van je een-op-een meeting feedback te verpakken in een feedback-sandwich, raad ik je de Radical Candor-methode aan als basis voor je feedback-sjabloon. Het is trouwens niet alleen handig in de software IT-industrie, maar ook privé - laten we er eens dieper op ingaan.
Radicale openhartigheid betekent zo eerlijk en direct mogelijke feedback geven in beoordelingsgesprekken. Tegelijkertijd betekent het ook empathie tonen en je richten op het welzijn van de ander. Radical Candor laat zien dat je niet hoeft te kiezen voor het een of het ander: Direct en eerlijk of empathisch en attent. In plaats daarvan kun je beide tegelijk doen:
Meer onder: Wat is radicale openhartigheid?
Softwareontwikkelaars zullen je dankbaar zijn als je direct ter zake komt met negatieve feedback.
Feedbacksjabloon voor softwareontwikkelaars gebaseerd op Radical Candor
Deze sjabloon is gebaseerd op het SBI-model (Situatie, Gedrag, Impact). Het helpt je om op een oprechte, directe en toch waarderende manier te communiceren.
Zie ook “Geef feedback draaiboek”
Hier zijn de instructies voor de afzonderlijke delen van het feedbacksjabloon:
Feedbacksjabloon deel 1: Voorbereiding vooraf
Neem een paar minuten de tijd om over de volgende punten na te denken voordat je feedback geeft:
- Situatie: Naar welke situatie verwijs je specifiek?
- Gedrag: Welk gedrag heb je van de persoon waargenomen?
- Impact: Welke impact had het gedrag van de persoon (op jou en anderen)?
- Wens: Welke toestand wil je bereiken en waarom? (Let op: Het gaat er hier niet om direct een bepaald gedrag te wensen - dat is onderdeel van de maatregel (zie hieronder). Het gaat meer om de grotere context, waarom de impact een probleem voor je is.)
- Actie: Welke suggesties heb je voor de persoon? Welke gedragsveranderingen zouden ons dichter bij het doel kunnen brengen? Welke ondersteuning kun je bieden?
Je kunt de punten het beste kort opschrijven, zodat je tijdens het gesprek niets vergeet.
Feedbacksjabloon deel 2: Het gesprek beginnen
In plaats van te beginnen met een lange één-op-één feedbacksandwich, kun je nu direct beginnen met de situatie als gespreksstarter:
- “Ik wilde met je praten over de situatie toen we …”
Beschrijf de situatie en vraag dan:
- “Herinner je je de situatie nog?”
Feedbacksjabloon deel 3: Gedrag
Vervolgens kun je ingaan op het gedrag van de persoon dat je hebt waargenomen in het beoordelingsgesprek:
- “Je schudde je hoofd over de situatie en zei…”
Voordat je over het effect praat, geef je de ander de gelegenheid om commentaar te geven op jouw waarneming of herinnering:
- “Geef ik dit correct weer vanuit jouw gezichtspunt?”
Geef de persoon de ruimte om zijn of haar perspectief op dingen te beschrijven. Probeer beide perspectieven op gelijke voet in de ruimte te laten staan zonder er commentaar op te geven. Beperk je tot het stellen van vragen over de inhoud van het perspectief van de ander.
Feedbacksjabloon deel 4: Impact
Alleen in dit deel gaat het om het bespreken van de effecten van het gedrag. Blijf in het begin zo objectief mogelijk:
- “Mijn indruk was dat mijn collega Marc na jullie [geobserveerd gedrag] erg beledigd leek en niet langer bereid was om met ons samen te blijven werken.”
Maar als de gevolgen ook jou raken, is het belangrijk om dit te delen. Natuurlijk moet je altijd professioneel blijven, maar je kunt ook je menselijke kant laten zien:
- “Zelf schaamde ik me eerlijk gezegd in die situatie en ik vond het gesprek vanaf dat moment onaangenaam.”
Feedbacksjabloon deel 5: Wens
Spreek je specifieke verzoek uit in dit deel van het beoordelingsgesprek:
- “Voor mij is het belangrijk dat we weer een goede basis vinden voor samenwerking met onze collega Marc.”
Zet het nog eens in de juiste context:
- “En verder is het een grote behoefte van mij dat we samenwerken om ervoor te zorgen dat we goede samenwerking en relaties onderhouden met alle naburige specialistische gebieden.”
Verwijs ook naar relevante doelen die uitleggen waarom je dit verlangen hebt:
- “Alleen door een goede relatie kunnen we als team in dit bedrijf onze doelen bereiken. Ik vind het ook belangrijk dat we als team een goede reputatie hebben binnen het bedrijf.”
“Ik mag de medewerker graag, maar hij levert niet de gewenste prestaties. Hoe kan ik dit aanpakken in 1:1’s?”
Los deze uitdaging op
"Ik weet vaak niet of ik te hard – of te zacht – was in mijn 1:1s om een positieve impact te hebben."
Los deze uitdaging op
"Ik kan geen patronen of trends herkennen in mijn 1:1s. Alles lijkt op zichzelf te staan."
Los deze uitdaging opFeedbacksjabloon deel 6: Meten
Voordat je je eigen ideeën voor oplossingen presenteert, kun je open vragen stellen in je één-op-één gesprek:
- “Ik heb hier een paar ideeën over. Maar ik wil eerst jouw mening horen: Hoe denk je dat we het doel kunnen bereiken?”
Je kunt dan je ideeën delen. Spreek samen een bindend en specifiek omschreven vervolg af. Leg dit schriftelijk vast.
Feedbacksjabloon deel 7: Afwijzing
Vraag of het beoordelingsgesprek nuttig was voor de andere persoon en of ze nog onbeantwoorde vragen hebben. Spreek een check-in af voor de volgende keer dat jullie over het onderwerp praten.
Laat je waardering blijken voor de open dialoog en bedank de persoon voor zijn inzicht en medewerking.
Feedbacksjabloon deel 8: Denk achteraf na over je feedback
Aan het einde van elke feedbacksessie moet je jezelf de volgende vraag stellen:
- Eerlijkheid: Heb ik mijn feedback eerlijk en zo ongezouten mogelijk gedeeld?
- Waardering: Voelt de persoon zich gewaardeerd door mijn feedback?
Als je alle vragen met “ja” kunt beantwoorden, dan is je feedbacksessie heel goed verlopen. Zo niet, maak je dan geen zorgen. Denk na over hoe je dingen in de toekomst anders kunt formuleren. En nogmaals, de meeste van deze tips zijn niet alleen van toepassing op de software IT-industrie.
Op dit punt wil ik erop wijzen dat er natuurlijk ook software bestaat voor het vereenvoudigen van overeenkomstige feedbackgesprekken en ook voor het coachen van softwareontwikkelaars op de langere termijn.
Onze software voor één-op-één vergaderingen biedt je verschillende sjablonen voor werknemersvergaderingen met softwareontwikkelaars en maakt zelfs de ontwikkeling van werknemers meetbaar. Bekijk onze tool en probeer de volgende sjabloon uit:
Geen geklets, geen ongemakkelijke pauzes. Deze 1:1 sjabloon werkt gewoon altijd.
💬 Uit de template:
- Op welke prestatie ben je trots die mij misschien nog niet is opgevallen?
- Welke kleine verandering zou je werk onmiddellijk verbeteren?
- Waar zou je meer tijd voor willen nemen op je werk?
…
Laten we nu aan de slag gaan met behulp van dit sjabloon voor beoordelingsgesprekken en een paar praktische voorbeelden doornemen!
1:1 bijeenkomst feedback voorbeelden: Code kwaliteit, eigenaarschap
Voorbeelden van feedback aan softwareontwikkelaars in één-op-één gesprekken
Voorbeeld feedback aan softwareontwikkelaars in 1-op-1 vergaderingen: Codekwaliteit
Met Tanja 👩🏼🦰 in de rol van teamleider en Marc 👨🏽 in de rol van medewerker.
Beschrijf de situatie
“In onze laatste code-review hebben we je pull request voor de implementatie van de nieuwe functie in het dashboard bekeken. De code was functioneel correct en voldeed aan de eisen.”
“Ja, dat herinner ik me!”
Waargenomen gedrag
“Ik heb commentaar gegeven op passages die vrij complex en moeilijk te lezen waren. Er was bijvoorbeeld een methode met meer dan 50 regels die verschillende verantwoordelijkheden combineerde. Je becommentarieerde deze opmerking echter alleen oppervlakkig en ging er verder niet op in.”
“Voor mij klonk de opmerking als een optionele suggestie. Het leek me te tijdrovend om de oplossing weer te veranderen.”
Impact
“Hoe dan ook, je opmerking maakte me een beetje gefrustreerd om eerlijk te zijn en in plaats van aan te dringen op een fix van jou, heb ik de methode achteraf gewoon zelf verbeterd omdat ik me toch al in de code had verdiept.”
“Oh, dat realiseerde ik me niet.”
Doel en verlangen
“Ons gezamenlijke doel is om ervoor te zorgen dat onze code niet alleen functioneel is, maar ook onderhoudbaar en gemakkelijk te begrijpen voor iedereen.”
“Dat is precies hoe ik het zie!”
Maatregelen
“Wat is je suggestie over hoe we de kwaliteit van de code in de toekomst soepeler kunnen verbeteren in zulke gevallen?”
“Het zou me helpen als het makkelijker was om in de opmerkingen te zien of een verbetering alleen wordt gesuggereerd of ook wordt geëist.”
“Oké, laten we dat doen - ik neem dat nog mee in de teamvergadering. Daarnaast is er naar mijn mening toch ook een follow-up van jouw kant nodig.”
“Zullen we voor het volgende onderwerp meteen samen gaan pairprogrammeren, zodat je mijn begrip van de vereisten voor codekwaliteit kunt aanscherpen?”
Conclusie
“Dat klinkt als twee goede vervolgstappen! Laten we dat dan zo houden. Ik zet graag een datum in mijn agenda voor halverwege volgende week om te beginnen met het pairprogrammeren.”
“Oké, ik heb er zin in!”
Voorbeeld van feedback aan softwareontwikkelaars in 1-op-1 vergaderingen: Eigenaarschap
Met Tanja 👩🏼🦰 in de rol van teamleider en Marc 👨🏽 in de rol van medewerker.
Beschrijf de situatie
“Marc, ik wil met je praten over de laatste taak, waarbij we de nieuwe functie voor het exportproces hebben ontwikkeld. De functie is inmiddels live, maar er waren onderweg enkele uitdagingen.”
“Ja, dat herinner ik me. Wat bedoel je precies?”
Waargenomen gedrag
“Ik merkte dat er verschillende lange vertragingen waren nadat de code was overgedragen om te testen. Sommige opmerkingen van QA-collega’s werden bijvoorbeeld dagenlang niet beantwoord. Het kwam ook voor dat ik je twee keer moest herinneren aan een ontbrekende review.”
“Hmm, ik begrijp het. Om eerlijk te zijn was er best veel aan de hand en ik dacht dat het testen parallel door zou gaan.”
Impact
“Het resultaat was in ieder geval dat we onze inzet moesten uitstellen vanwege deze kwestie.”
“Oh, dat had ik niet eens door. Ik dacht dat je wel contact zou opnemen als er iets dringends was.”
Doel en verlangen
“Ons doel is om onnodige vertragingen tot een minimum te beperken en om ontwikkelaars tijdens de implementatie een ‘ownership mindset’ te laten aannemen. Dit betekent dat iedereen er actief voor zorgt dat zijn ticket van begin tot eind – doorkomt en daar hoort ook communicatie met QA bij.”
“Ik begrijp wat je bedoelt. Ik wil zeker dat de processen soepeler verlopen.”
Maatregelen
“Wat zouden we vanuit jouw perspectief kunnen doen zodat je proactiever kunt handelen en eigenaarschap kunt tonen in dergelijke situaties?”
“Ik denk dat het zou helpen als we duidelijkere verwachtingen zouden stellen, bijvoorbeeld dat ik tijdens de testfase dagelijks een check-in doe op openstaande kwesties. Op die manier kan ik ervoor zorgen dat er niets ongedaan wordt gemaakt.”
“Dat klinkt goed. En ik stel voor dat je voor de volgende grote taken, nadat de code is afgerond, een kort plan maakt van hoe je het onderwerp wilt doorzien tot aan de livegang. Je kunt het plan aan mij of een QA collega laten zien.”
“Mee eens. Dan kan ik zelf een beter oogje in het zeil houden.”
Conclusie
“Geweldig. Laten we de twee maatregelen als volgt vastleggen: Je doet dagelijkse check-ins tijdens de testfase en plant de follow-up voor je volgende grote taak. Is dat haalbaar voor jou?”
“Ja, dat past. Ik zal het meteen in mijn agenda zetten.”
“Geweldig. Ik weet zeker dat dit een groot verschil zal maken. In ons volgende één-op-één gesprek zullen we nog eens kijken naar de status van onze maatregelen. Bedankt!”
Leidinggeven door vragen: sjabloon voor 1:1-bijeenkomsten
Een wijsheid uit de managementliteratuur luidt: leid door vragen te stellen. En daar zit veel in.
Als je regelmatig en continu 1-op-1 meetings houdt, waarin je samen met de medewerker reflecteert over het onderwerp feedback (door vragen te stellen), kunnen problemen zich niet “opstapelen”.
Daarom wil ik je graag een ander sjabloon geven dat je kunt gebruiken in onze Echometer tool met je medewerker. In principe kun je dit sjabloon ook regelmatig gebruiken.
Probeer ze uit door simpelweg op de knop hieronder te klikken (inloggen niet nodig):
Aanvang
- Hoe was je week tot nu toe?
📊 Projectupdates
- Hoe lopen je huidige projecten? Zijn er grote successen of obstakels?
- Zijn er technische uitdagingen die je wilt bespreken of samen wilt doordenken?
💻 Codekwaliteit & ontwikkeling
- Hoe voel je je over de kwaliteit van je werk de laatste tijd?
- Zijn er gebieden waarop je jezelf wilt verbeteren of nieuwe vaardigheden wilt leren?
🤝 Team, samenwerking & volgende stappen
- Hoe verloopt de samenwerking in het team? Zijn er communicatiegaten?
- Ondersteunen de door ons gebruikte tools en processen je werk effectief?
- Hoe zie je je carrière in de komende een tot twee jaar voor je?
- Hoe kan ik je helpen om succesvol te zijn?
Afronding
- Waar kijk je de komende maanden het meest naar uit?
- Heb je nog andere vragen of opmerkingen?
⁉️ Stemmingscheck (enquête)
Voorbeelden voor feedback op functioneringsgesprekken: Teamwerk, Eigenaarschap
Voorbeelden van feedback aan softwareontwikkelaars in het functioneringsgesprek
Een opmerking: Traditionele functioneringsgesprekken zijn vaak niet populair bij zowel softwareontwikkelaars als managers, en velen beweren dat goede één-op-één gesprekken voldoende zijn en de functioneringsgesprekken moeten vervangen. Zie: “Functioneringsgesprekken zijn zinloos en beledigend” door Forbes.
Maar functioneringsgesprekken zijn vaak nog steeds een vooraf bepaald format binnen het bedrijf. Dit mag je er natuurlijk niet van weerhouden om functioneringsgesprekken als een dialoog op ooghoogte met je werknemers te voeren in plaats van je te beperken tot top-down beoordelingen. De volgende voorbeelden van een één-op-één dialoog laten zien hoe het kan werken.
Opmerking: Zoals al eerder vermeld, kunnen sjablonen voor personeelsbeoordelingen natuurlijk helpen om feedback op een constructieve manier te communiceren. De volgende blogpost kan je helpen als je meer geïnteresseerd bent in het onderwerp: 5 sjablonen voor regelmatige check-ins van werknemers .
Voorbeeld feedback aan software engineers in functioneringsgesprekken: Teamwerk
Met Tanja 👩🏼🦰 in de rol van Team Lead en Marc 👨🏽 in de rol van Software Engineer.
Beschrijf de situatie
“Toen ik in je Performance Review-template het punt ‘Teamwork’ moest beoordelen, kon ik helaas maar 5 van de 10 mogelijke punten geven. Dat wil ik je graag uitleggen om je een eerlijke kans te geven om je op dit punt te verbeteren.”
“Oh, oké. Help me alsjeblieft om dit te begrijpen.”
Waargenomen gedrag
“Ik heb gemerkt dat er de afgelopen maanden situaties waren waarin de samenwerking met het team niet optimaal was. In onze laatste sprint waren er bijvoorbeeld verschillende gevallen waarin je in je eentje aan taken werkte, ook al hadden ze beter samen met anderen opgelost kunnen worden. Een specifiek voorbeeld was de integratie van de nieuwe API. We hadden overwogen om jou en Alex er samen aan te laten werken, maar je nam de meeste stappen alleen en betrok Alex er slechts minimaal bij.”
“Ik dacht dat het efficiënter zou zijn om het snel zelf te doen. Ik realiseerde me niet dat dit als een probleem werd gezien.”
Impact
“Dit leidde echter tot een verlies aan transparantie in het team. Alex had later moeite om betrokken te raken bij gerelateerde taken omdat hij niet precies wist hoe de API was opgezet. Ik kreeg ook feedback van andere teamleden dat ze zich soms niet betrokken genoeg voelden en het moeilijk vonden om ondersteuning van je te krijgen als ze vragen hadden.”
“Dat verbaast me eerlijk gezegd. Ik dacht dat ik zou helpen als ik gevraagd werd.”
Doel en verlangen
“Ons doel als team is niet alleen om efficiënt te werken, maar ook om kennis te delen en iedereen erbij te betrekken. Dit versterkt de samenwerking en zorgt ervoor dat we elkaar allemaal kunnen vertegenwoordigen. Ik zou graag willen dat je in de toekomst je rol als kennisdrager in dit team meer benut om actief kennis te delen en andere teamleden in hun kracht te zetten. Teamproductiviteit is belangrijker dan individuele prestaties.”
“Oké, ik begrijp wat je bedoelt. Ik denk dat ik tot nu toe gewoon te gefocust ben geweest op mijn eigen productiviteit.”
Maatregelen
“Wat zou je kunnen helpen om meer aandacht te besteden aan het betrekken van het team bij je werk en het delen van kennis?”
“Ik zou er een gewoonte van kunnen maken om meteen aan het begin duidelijk te maken wie aan grotere taken mag werken en hoe. Misschien kunnen we ook zoiets opzetten als een kick-off voor taken om het eens te worden over de ruwe architectuurbeslissingen en taken aan te wijzen die iemand anders alleen moet doen of die we zelfs in pair programming moeten doen.”
“Dat klinkt goed. Ik had ook een idee: hoe zou het zijn als je er een gewoonte van maakt om niet alleen voortgang te rapporteren tijdens onze wekelijkse teamvergaderingen, maar ook actief inzicht te geven in de code en architecturale beslissingen?”
“Dat is een goed punt. Dat kan helpen om het voor onze onervaren collega’s makkelijker te maken om later aan mijn code te werken.”
Conclusie
“Geweldig. Dan noteren we de follow-ups in ons sjabloon voor het functioneringsgesprek:
- Vanaf nu deel je proactief je kennis en architectuurbeslissingen met het team in de Weeklys.
- Vanaf nu doe je bij je onderwerpen een kick-off met een andere ontwikkelaar, zodat jullie de oplossing samen uitwerken en de implementatie onder elkaar verdelen.”
“Klinkt goed.”
“OK. Ik zou beide maatregelen eerst noteren voor een review over twee maanden. Dan kunnen we de status bespreken in ons een-op-eengesprek en kijken hoe we verdergaan.”
“Ja, en laten we dan ook kijken of je je ‘teamwork’ score niet kunt verbeteren. Ik wil graag minstens een 8 uit 10 halen.”
“Ik ben blij dat te horen! Ik geloof absoluut dat dat realistisch is en zal je steunen waar ik kan.”
“Dank je!”
Voorbeeld feedback naar Software Engineers Functioneringsgesprekken: Eigenaarschap
Laten we verder gaan met het volgende voorbeeld van een één-op-één gesprek, dat gaat over feedback aan de softwareontwikkelaar over het onderwerp eigenaarschap.
Zoals altijd met Tanja 👩🏼🦰 in de rol van Team Lead en Marc 👨🏽 in de rol van Software Engineer.
Beschrijf de situatie
“Toen ik in je Performance Review-template het punt ‘Ownership’ moest beoordelen, kon ik maar 6 van de 10 punten geven. Ik wil je uitleggen waarom dat zo is, en je de kans geven om je op dit gebied verder te ontwikkelen.”
“Wow, dat verrast me enigszins. Ik heb immers aan zoveel onderwerpen meegewerkt als bijna niemand anders in het team. Leg het me alsjeblieft uit.”
Waargenomen gedrag
“In de afgelopen maanden heb ik gemerkt dat er vaak vertragingen optreden in je taken. Er zijn verschillende voorbeelden waarbij QA-commentaren of code-reviews lange tijd onbeantwoord zijn gebleven. Als gevolg daarvan gingen je onderwerpen pas na weken vertraging live. Een specifiek voorbeeld was de bugfixing voor de export. Je beantwoordde feedback van QA pas na herhaalde verzoeken, en het duurde in totaal drie weken voordat de wijzigingen live gingen.”
“Ja, dat weet ik nog. Ik was tegelijkertijd met twee andere onderwerpen bezig en kwam er niet zo snel aan toe om de feedback in te voeren.”
Impact
“Dit had invloed op de snelheid en productiviteit van het hele team. QA moest meerdere keren opvolgen, wat hun capaciteit in beslag nam. Het releaseplan moest ook worden uitgesteld. Bovendien voelt het alsof je niet de volledige verantwoordelijkheid neemt voor het afronden van je problemen, wat de teamdynamiek onder druk zet. Sommige teamleden hebben me verteld dat ze zich onzeker voelen of ze op je kunnen vertrouwen als het gaat om afhankelijkheden.”
“Oh, dat spijt me. Dat had ik me niet gerealiseerd. Ik heb geprobeerd de taken parallel uit te voeren, maar dat lukte blijkbaar niet zo goed.”
Doel en verlangen
“Mijn doel is dat je je richt op minder onderwerpen, maar dat je de volledige verantwoordelijkheid neemt voor elke taak van begin tot eind. Dit betekent dat je niet alleen de initiële code schrijft, maar er ook voor zorgt dat QA-feedback snel wordt verwerkt en dat het onderwerp op schema blijft. Op deze manier kunnen we voorkomen dat taken langer open blijven staan en anderen blokkeren.”
“Dat is logisch. Ik voelde me vaak overweldigd omdat ik te veel onderwerpen tegelijk had. Misschien is het echt beter om je op minder taken te concentreren.”
Maatregelen
“Hoe kregen we het voor elkaar om je te laten focussen op een paar onderwerpen en verantwoordelijkheid te nemen voor de volledige implementatie ervan?”
“Ik zou kunnen proberen om mezelf te beperken tot maximaal twee onderwerpen per sprint en nooit aan meer dan drie onderwerpen tegelijk werken. Ik zou ook vaste slots in mijn agenda moeten blokkeren om regelmatig aan opmerkingen en beoordelingen te werken, zodat er niets achterblijft.”
“Dat klinkt verstandig. Daarnaast denk ik dat het goed zou zijn als je proactief om hulp zou kunnen vragen in onze stand-ups als je met te veel onderwerpen tegelijk bezig bent. Er moet meestal wel iemand zijn die een onderwerp van je kan overnemen.”
“Oké, eerlijk.”
Conclusie
Laten we deze maatregelen vastleggen als doel voor de komende twee maanden:
Minder werk parallel:
- Je neemt maximaal twee onderwerpen per sprint aan en werkt niet aan meer dan 3 onderwerpen tegelijk.
- Vraag actieve steun van het team in stand-ups
- Vaste momenten in de agenda voor het afhandelen van commentaren en reviews.
“Dat klinkt realistisch. Laten we het zo doen.”
“Geweldig. We kunnen over twee maanden in het functioneringsgesprek zien of deze maatregelen hebben gewerkt en of we je beoordeling in het functioneringsgesprek voor ‘Eigenaarschap’ weer kunnen verhogen.”
“Dank je, Tanja. Ik zal proberen dat in praktijk te brengen. Vroeger kreeg ik altijd toppunten voor ‘Eigenaarschap’. Denk je dat ik dat bij het volgende functioneringsgesprek weer haal?”
“Daar ben ik blij om. Ja, ik geloof dat een snelle verbetering absoluut haalbaar is met deze maatregelen. Laten we de status bespreken en of je ondersteuning nodig hebt in onze tweewekelijkse één-op-één gesprekken.”
“Dank je wel! Ja, ik zou het geweldig vinden als we hier binnen een paar weken een merkbare verbetering kunnen bereiken!”
Jaarlijkse dialoog Feedback voorbeelden: Verlangen naar rolverandering
Voorbeelden van feedback aan softwareontwikkelaars in het jaaroverzicht
Als je gedurende het jaar al regelmatig één-op-één gesprekken of functioneringsgesprekken hebt met je ontwikkelaars, dan heb je waarschijnlijk geen gedetailleerde jaarlijkse bijeenkomsten meer nodig. De uitwisseling over prestaties, feedback en verdere ontwikkeling zou al een voortdurende dialoog moeten zijn:
Toch zijn er bedrijven die een klassieke jaarlijkse beoordeling vereisen.
💡
Als je als manager van softwareontwikkelaars al regelmatige 1:1-gesprekken of functioneringsgesprekken hebt, zou het jaargesprek slechts een formaliteit moeten zijn:
De feedback zou al bekend moeten zijn bij de softwareontwikkelaar en er zou al gewerkt moeten worden aan het ontwikkelingspotentieel.
Dus als je als manager van softwareontwikkelaars moet voldoen aan de formaliteit van een eindejaarsgesprek (mogelijk naast de reguliere één-op-één gesprekken), laten we dan ook een voorbeeld nemen van een jaarlijkse personeelsbeoordeling met een softwareontwikkelaar.
Trouwens, nog een tip op dit punt: Als je eerste één-op-één gesprek met een nieuwe medewerker voor de deur staat, kan ik je ons artikel over dit onderwerp aanraden: 5 tips voor één-op-één gesprekken met nieuwe medewerkers .
Voorbeeldagenda & sjabloon voor een jaarlijkse vergadering met een softwareontwikkelaar
- Beoordeling en prestaties
- Successen: Welke projecten of taken gingen goed? Waar werden de verwachtingen overtroffen?
- Uitdagingen: Wat werkte niet zo goed en waarom? Hoe kunnen deze uitdagingen in de toekomst worden overwonnen?
- Reflectie: Hoe ziet de ontwikkelaar zijn eigen prestaties? Welke feedback heeft het team of de manager?
- Samenwerking en teamcultuur
- Communicatie: Hoe wordt de samenwerking binnen het team en met de manager ervaren?
- Werksfeer: Is er ruimte voor verbetering in de teamcultuur of werkomgeving?
- Feedback over leiderschap: Hoe kan de manager de ontwikkelaar beter ondersteunen?
- Feedback van de ontwikkelaar: Zijn er suggesties voor het verbeteren van processen, hulpmiddelen of werkcultuur?
- Balans werk-privé: Wat vind je van je huidige werkdruk? Zijn er overwerk- of stressfactoren?
- Middelen: Zijn de hulpmiddelen, processen en randvoorwaarden voldoende om efficiënt te werken?
- Expertise, doelen en ontwikkeling
- Sterke punten: Welke technische, methodologische of sociale vaardigheden kenmerken de ontwikkelaar?
- Bijscholing: Welke nieuwe technologieën of vaardigheden wil de ontwikkelaar leren? Zijn er relevante cursussen, conferenties of projecten?
- Carrièredoelen: Naar welke functie of verantwoordelijkheid streeft de ontwikkelaar op de middellange tot lange termijn? Welke stappen leiden daar naartoe?
- Projectfocus: Aan welke projecten of technologieën zou de ontwikkelaar intensiever willen werken?
- Vergoeding
- Prestatiegerelateerde beloning: Is het nodig om het salaris of de bonussen aan te passen?
- Conclusie
- Doelen op korte termijn: Welke specifieke doelen moeten er voor het komende jaar worden gesteld?
- Afspraken: Wat zijn de volgende check-ins voor de respectievelijke maatregelen?
Het volgende is een typisch voorbeeld van feedback binnen een eindejaarsgesprek of jaarlijks functioneringsgesprek: Het verzoek van de werknemer om van functie te veranderen.
Voorbeeld feedback in de jaarvergadering: Verlangen naar rolverandering
Met Tanja 👩🏼🦰 in de rol van Team Lead en Marc 👨🏽 in de rol van Software Engineer.
Binnenkomst en situatie
“Marc, fijn dat we vandaag kunnen praten over je jaarlijkse feedback en je doelen. Zijn er bepaalde onderwerpen die voor jou extra belangrijk zijn?”
“Ja, ik heb nagedacht over mijn verdere ontwikkeling. Ik zou me kunnen voorstellen om me in de richting van software-architectuur te ontwikkelen. Het onderwerp spreekt me al lang aan, en ik zou me graag intensiever bezighouden met architectuurkeuzes en strategisch technologiebeheer.”
“Dat is spannend, Marc. Ik ben blij dat je zulke duidelijke doelen hebt. Laten we eens bespreken hoe we je daarop kunnen voorbereiden. Er zijn een paar punten waarvan ik denk dat je je nog verder moet ontwikkelen voordat we de volgende stap zetten.”
Feedback geven
“Ten eerste wil ik benadrukken dat jullie dit jaar veel vooruitgang hebben geboekt, vooral in de kwaliteit van jullie implementaties en in het omgaan met nieuwe technologieën. Jullie hebben ook laten zien dat jullie oog hebben voor het grotere geheel, bijvoorbeeld met de introductie van het nieuwe caching systeem.”
“Dank je, ik ben blij dat te horen!”
“Als ik echter nadenk over de rol van een software-architect, zijn er nog steeds een aantal vereisten waarvan ik denk dat er op dit moment niet volledig aan wordt voldaan. Bijvoorbeeld communiceren met het team en anderen betrekken bij technische beslissingen is een belangrijk onderdeel. Ik zie daar nog steeds potentieel voor je. Je neemt vaak zelfstandig beslissingen zonder het team er vroeg genoeg bij te betrekken.”
“Oké, dat begrijp ik. Ik wilde soms niemand ophouden, maar ik realiseer me dat dat niet ideaal is voor de rol van architect.”
Doel en verlangen
“Precies. Een software architect is ook een coach en communicator. Het gaat erom anderen aan boord te krijgen, technische concepten te communiceren en samen oplossingen te ontwikkelen.”
“Dat klinkt logisch. Ik realiseer me ook dat ik mijn gedachten over architectuur nog niet zo effectief kan overbrengen op mijn teamleden.”
Maatregelen plannen
“Ik denk dat we hier samen aan kunnen werken, zodat je de komende 6 maanden in aanmerking komt voor de functie. Als we nu eens specifieke maatregelen definiëren?”
“Dat zou ik graag willen. Wat heb je in gedachten?”
“Bovenal zou ik graag zien dat je het besluitvormingsproces voor de softwarearchitectuur modereert in plaats van dat je zelf de beslissing neemt. Wat dacht je van het modereren van een architectuur kick-off voor elk van de volgende belangrijke onderwerpen? Het doel zou zijn om collega’s te ondersteunen in het besluitvormingsproces en ze vervolgens zelf de oplossing te laten implementeren.”
“Dat klinkt goed. Zo leer ik mijn invloed als coach uit te oefenen, in plaats van alles zelf te implementeren.”
“Daarnaast kan ik me voorstellen dat er goede cursussen zijn om ontwikkelaars voor te bereiden op de rol van software-architect. In deze cursussen zal het zeker naast de hard skills ook gaan om de soft skills die nodig zijn voor de rol.”
“Ja, ik heb zelfs al een cursus uitgezocht.”
Conclusie
“Super, dan noteer ik voor ons jaargesprek het volgende:
- Ontwikkelingsdoel: Software-architect
- Maatregelen:
- Begeleiden van architectuur kick-offs in een team
- Deelname aan een cursus voor softwarearchitecten
We bespreken deze onderwerpen natuurlijk continu in onze een-op-eenmeetings, maar de volgende officiële check-in zou dan zijn bij onze Performance Review over 3 maanden.”
“Klinkt goed. Tegen die tijd zouden we al het een en ander bereikt moeten hebben.”
“Dat denk ik ook! Als je in de tussentijd nog andere dingen bedenkt waarmee ik je in deze zaak kan ondersteunen, spreek me dan gerust aan.”
“Kunnen we over 3 maanden dan ook nog eens praten over mijn beoogde functiewissel?”
“Natuurlijk, ik kan je natuurlijk niets beloven wat de functiewissel betreft. Maar ik heb je wens genoteerd en probeer je zo goed mogelijk te ondersteunen.”
“Dank je!”
Conclusie: Feedback geven aan software engineers in 1:1 gesprekken, functioneringsgesprekken en jaarlijkse beoordelingen
Conclusie: Motiverende feedback voor softwareontwikkelaars
De voorbeelden en sjablonen laten zien dat het niet zo moeilijk hoeft te zijn om motiverende feedback te geven aan softwareontwikkelaars in één-op-één gesprekken en eindejaarsbijeenkomsten, toch? Blijf authentiek en welwillend, draai er niet omheen en laat zien dat je geïnteresseerd bent in een gezamenlijke oplossing.
Als het je lukt om “Radical Candor” in je medewerkersgesprekken en daarbuiten toe te passen, door waardering en eerlijkheid te tonen, zal de reactie misschien zelfs positiever en constructiever uitvallen dan je denkt.
Veel succes met je volgende feedbacksessies!
En als je van hacks houdt die je leven makkelijker maken, dan raad ik je onze Echometer software aan. Je kunt het helemaal gratis uitproberen.
Onze software voor één-op-één vergaderingen biedt je verschillende sjablonen voor werknemersvergaderingen met softwareontwikkelaars en maakt zelfs de ontwikkeling van werknemers meetbaar. Bekijk onze tool en probeer de volgende sjabloon uit:
Geen geklets, geen ongemakkelijke pauzes. Deze 1:1 sjabloon werkt gewoon altijd.
💬 Uit de template:
- Op welke prestatie ben je trots die mij misschien nog niet is opgevallen?
- Welke kleine verandering zou je werk onmiddellijk verbeteren?
- Waar zou je meer tijd voor willen nemen op je werk?
…
