Senior developer of tech lead: wie is in uw team echt verantwoordelijk voor codekwaliteit?

Een situatie die zich in veel softwareteams in een of andere vorm afspeelt. De applicatie gaat steeds kapot op plekken waar niemand aan heeft gezeten. De manager ziet dat sommige developers tests schrijven en andere niet, en wendt zich tot de meest ervaren persoon in de kamer: “Jij bent de senior. Zorg dat iedereen tests schrijft.”

De senior antwoordt dat hij graag helpt, maar dat het niet aan hem is om te bepalen wat collega’s moeten doen. De manager hoort “dat is mijn werk niet”. De senior hoort “jij bent nu verantwoordelijk voor het werk van anderen, zonder enige zeggenschap erover”. Beiden lopen gefrustreerd weg, en er verandert niets.

Het probleem zit zelden in de mensen. Het zit in een rol die niemand heeft gedefinieerd. Dit artikel is bedoeld voor degene die die rol kan definiëren: de eigenaar, de CTO of het hoofd ontwikkeling.

Twee verschillende functies met vergelijkbare namen

Een senior developer wordt bepaald door technische diepgang: lastige problemen oplossen, goede ontwerpbeslissingen nemen, code reviewen, collega’s helpen groeien. Zijn invloed komt voort uit expertise. Hij kan voorstellen, uitleggen en voordoen, maar collega’s zijn niet verplicht hem te volgen.

Een tech lead wordt bepaald door verantwoordelijkheid voor de manier waarop het team software bouwt: welke standaarden gelden, hoe code wordt gereviewd, welke technische schuld wordt afgelost en wat er gebeurt als iemand een afgesproken regel negeert. Zijn invloed komt voort uit een mandaat dat het management hem geeft.

Dezelfde persoon kan beide doen, en dat gebeurt ook vaak. Maar de tweede functie komt niet automatisch mee met de eerste. Die moet worden gegeven, en het team moet weten dat die is gegeven.

De vraag die het gat blootlegt

Stel bij elke standaard in uw team één vraag: wat gebeurt er als een developer zich er niet aan houdt?

• Is het antwoord “de tech lead spreekt het aan, en zo nodig gaat het naar het management”, dan heeft de standaard een eigenaar.
• Is het antwoord “de senior moet even met hem praten”, vraag dan wat de senior concreet kan doen als de collega nee zegt. Meestal: niets, behalve escaleren, en daarmee wordt een collega een leidinggevende die niemand heeft benoemd.
• Is het antwoord een schouderophalen, dan is de standaard een wens.

Wie doet wat

Een eenvoudige manier om het helder te maken: schrijf per soort beslissing op wie voorstelt, wie beslist, wie het uitvoert en wie optreedt als het wordt genegeerd.

Beslissing	Stelt voor	Beslist	Voert uit	Als het wordt genegeerd
“Nieuwe code krijgt geautomatiseerde tests”	Senior of tech lead	Tech lead, met steun van het management	Het hele team, met hulp van de senior	Tech lead, daarna het management
Hoe code review werkt	Tech lead	Tech lead	Iedereen	Tech lead
Architectuur van een nieuwe feature	Senior developer	Tech lead	De developers op die feature	Tech lead
Welke technische schuld dit kwartaal wordt afgelost	Tech lead	Management, op advies van de tech lead	Het team	Management
Prioriteiten tussen features	Product owner of management	Management	Het team	Management
Een collega helpen die vastzit	Iedereen	Niemand hoeft te beslissen	De senior	Niet van toepassing

Staat in de kolom “beslist” de senior bij zaken die het werk van anderen raken, en heeft niemand in het management dat hardop gezegd, dan zit daar de wrijving.

Wat u redelijkerwijs mag verwachten van een senior zonder mandaat

Situatie	Redelijk om te verwachten	Niet redelijk om te verwachten
Er ontbreken tests	Het signaleren en een oplossing voorstellen	Collega’s dwingen ze te schrijven
Een collega vraagt hoe je een test schrijft	Het hem laten zien	Elke dag ieders werk controleren
Het team heeft een standaard nodig	Een opzet maken en die uitleggen	Namens iedereen beslissen
Iemand negeert de standaard	Het één keer benoemen	Hem op het matje roepen
Er wordt een riskant ontwerp gebouwd	Bezwaar maken met argumenten	Het in zijn eentje tegenhouden

Een goede senior tilt de kwaliteit van een team op door voorbeeld, review en hulp. Hem vragen regels af te dwingen bij gelijken, zonder dat iemand heeft gezegd dat dat mag, beschadigt precies de verhoudingen waar die invloed op draait.

Signalen dat de rol ontbreekt

U hebt geen audit nodig om het te zien. Herkent u drie of meer van deze punten, dan is niemand in uw team echt eigenaar van de technische kwaliteit:

• Elke developer heeft zijn eigen idee van wat “klaar” betekent.
• Code review gebeurt als iemand tijd heeft, en goedkeuren is vooral een formaliteit.
• Dezelfde discussie over tests of structuur komt om de paar maanden terug en eindigt zonder besluit.
• Uw meest ervaren developer is gefrustreerd, en u weet niet precies waarom.
• Bugs die bij klanten terechtkomen worden besproken als pech, niet als een gat in het proces.
• Vraagt u bij een technische keuze “wie heeft dit besloten?”, dan is het antwoord “het is gewoon zo gegroeid”.

Geen van deze punten is op zichzelf een ramp. Samen betekenen ze dat het team elke dag betaalt voor een beslissing die niemand heeft genomen: wie de regels bepaalt.

Het mandaat op één pagina

Wilt u dat iemand eigenaar wordt van de technische kwaliteit, leg het dan vast. Het hoeft niet lang te zijn. Een pagina als deze, afgestemd met de persoon en aangekondigd aan het team, neemt het grootste deel van de verwarring weg:

De laatste twee regels zijn het belangrijkst. Zonder escalatiepad heeft de lead verantwoordelijkheid zonder zeggenschap. Zonder tijd wordt de rol onbetaald overwerk, en houdt uw beste developer langzaam op dat te zijn.

Drie manieren om het in te richten

• Benoem een tech lead binnen het team. Meestal het juiste antwoord voor een gevestigd team met een ervaren senior die de rol wil. Geef hem het mandaat en de tijd, en maak het bekend.
• Maak er een gezamenlijke teamafspraak van. In kleine teams kunnen de standaarden samen worden afgesproken en vastgelegd, en handelt het management de uitzonderingen af. Niemand controleert niemand; de regel is van iedereen.
• Haal voor een afgebakende periode een externe senior binnen. Als niemand intern de rol wil, of het team nog jong is, kan een ervaren buitenstaander de standaarden, de tests en het reviewproces opzetten, met een mandaat van het management, en dat daarna overdragen aan iemand in het team. Hoe dat in de praktijk werkt, leest u in ons artikel over wat u doet zolang u een senior .NET developer zoekt.

Het gesprek, zonder misverstand

Voor managers: een betere opening dan “zorg dat iedereen tests schrijft”:

“Ik wil dat geautomatiseerde tests standaard worden voor nieuwe code. Wil jij de regels opstellen en het team helpen ze toe te passen? Ik maak bekend dat ze voor iedereen gelden, en ik pak het op als iemand zich er niet aan houdt.”

Voor seniors: een beter antwoord dan “dat is mijn werk niet”:

“Ik wil graag de standaard opstellen en iedereen helpen die toe te passen. Kunnen we afspreken dat het een officiële teamregel is, en wie optreedt als die niet wordt gevolgd?”

Beide versies zeggen hetzelfde als het oorspronkelijke gesprek. Het verschil is dat verantwoordelijkheid en zeggenschap op dezelfde plek terechtkomen.

Waarom het voor het bedrijf telt

Codekwaliteit is geen hobby van developers. Ontbrekende tests en inconsistente standaarden komen terug als bugs in productie, als features die elk jaar langer duren en als systemen waar nog maar één persoon aan durft te komen. Ons artikel over technische schuld en trage ontwikkeling laat zien hoe dat zich opstapelt.

Het meeste daarvan is te voorkomen, maar alleen als iemand duidelijk verantwoordelijk is voor dat voorkomen, en dat ook te horen heeft gekregen.

Het is ook een van de meest voorkomende redenen waarom goede mensen vertrekken: verantwoordelijkheid zonder bevoegdheid put hen uit. Meer daarover in waarom goede developers vertrekken.

Vragen die we vaak horen

Moet elke senior developer tech lead worden?

Nee. Veel uitstekende seniors gaan liever technisch de diepte in en hebben geen behoefte aan leidinggeven. Beide paden zijn waardevol. Wie de tweede iemand opdringt, verliest meestal een goede developer en krijgt er een onwillige lead voor terug.

Ons team telt vijf developers. Hebben we wel een tech lead nodig?

U hebt iemand nodig die eigenaar is van de technische standaarden, ook al is het maar een paar uur per week. In kleine teams volstaan een gezamenlijke afspraak en een manager die erachter staat vaak.

Moet de tech lead meer verdienen?

Als de rol echt tijd en echte verantwoordelijkheid vraagt, ja: in salaris of in duidelijk minder ander werk. Een mandaat zonder tijd of erkenning houdt geen stand.

Kan een externe developer deze rol vervullen?

Voor een afgebakende periode wel, en dat werkt vaak goed: een buitenstaander heeft geen verleden in de interne verhoudingen van het team. Het mandaat moet van het management komen, en het doel moet zijn de rol over te dragen aan iemand in het team.

Hoe wij werken

ProCoding is een .NET-studio in Split, Kroatië. Naast ontwikkeling helpen we teams vaak met de technische kant van samenwerken: codeerstandaarden, geautomatiseerde tests, code review en kennisoverdracht, altijd met een duidelijk mandaat van het management en met als doel het bij uw team achter te laten. Als maandelijks blok dagen, of met een freelance .NET developer in uw team. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• The standard of code review, Google Engineering Practices