Elke websitewijziging wacht op een developer: waarom je marketingteam niets meer live zet

Een marketeer heeft dinsdagochtend een betere kop klaar. Vijf woorden anders, meer niet. Ze maakt er een ticket van, want dat is de enige manier om de wijziging op de live site te krijgen. Een developer pakt het midden in een sprint op, en vrijdag staat de nieuwe kop online. Vier dagen voor vijf woorden. De gangbare verklaring is dat het team te krap bezet is en er een developer bij moet. Maar als elke websitewijziging een developer nodig heeft, ligt dat zelden aan een tekort aan developers. Het ligt aan een stack waarin de tekst op een pagina verweven zit met de code, zodat je voor één alinea al een deploy nodig hebt. Elke aanpassing wordt een ticket. En een team dat een ticket moet indienen voor een kop, stelt op den duur geen nieuwe koppen meer voor.

Die laatste zin beschrijft precies wat de backlog verbergt. Het zichtbare probleem is dat wijzigingen traag gaan. Het echte probleem is stiller en duurder: de wijzigingen die nooit zijn voorgesteld, omdat ze de moeite van de wachtrij niet waard leken. Dit artikel loopt het hele mechanisme door, van waarom de tickets zich opstapelen tot waarom het team stil wordt. Daarna komt elke oplossing aan bod, inclusief het punt waarop die ophoudt te werken. Het doel is niet om je een platform te verkopen. Het doel is dat je ziet welk deel van je stack de backlog echt veroorzaakt. Dan zie je ook of een oplossing het probleem wegneemt, of dat je alleen sneller tegen dezelfde muur aanloopt.

Zo ziet het eruit als je team “niets meer live zet”

Een developer-bottleneck ontstaat wanneer gewone contentwijzigingen, de tekst en beelden op een pagina, alleen op de live site komen via iemand die code schrijft. Het symptoom is een wachtrij. De oorzaak is dat content en structuur als één geheel zijn gebouwd: wie aan de content zit, zit aan de bouw. Is dat eenmaal zo, dan is elke aanpassing een deploy, en elke deploy vraagt een developer, hoe klein de wijziging ook is.

Om het te herkennen heb je geen diagnose nodig. Een korte check volstaat. Pak je laatste tien websiteverzoeken erbij, waar ze ook staan: tickets, Slack, mails aan je bureau. Stel bij elk één vraag: veranderde dit wat de site zegt, of wat de site kan? Een kop, een alinea, een andere afbeelding, een nieuwe landing page uit bestaande onderdelen: die veranderen wat de site zegt. Een nieuwe integratie, een checkout-flow, een interactie op maat: die veranderen wat de site kan. Waren de meeste van je laatste tien van de eerste soort en had je er toch een developer voor nodig? Dan heb je geen personeelstekort. Je content zit vast in je code, en de wachtrij is de prijs die je daar elke week opnieuw voor betaalt.

Oorzaak één: content en code staan op dezelfde plek

De eerste oorzaak zit in de opbouw. De teksten die je wilt kunnen aanpassen, staan hard in de pagina gecodeerd, in plaats van als content waar iemand zonder programmeerkennis bij kan. Staat een kop direct in de paginatemplate, dan moet je voor een andere kop de template aanpassen. En de template aanpassen is per definitie werk voor een developer. De content hoefde daar niet te staan. Hij is er bij de bouw neergezet, meestal omdat snel live gaan goedkoper was dan een goede contentlaag bouwen. Die keuze legde ongemerkt de regel vast dat elke toekomstige aanpassing via development loopt.

De kosten stapelen zich op, en dat zie je makkelijk over het hoofd. Staat dezelfde klantquote of productomschrijving op negen plekken hard in de code, dan pas je hem ook op negen plekken aan. Negen losse wijzigingen, negen kansen dat er één blijft staan. Meestal ontdekken teams dit in de week van een rebranding, als de oude slogan opduikt in hoeken waar niemand meer aan dacht. Waar je moet ingrijpen, is helder te benoemen en ook echt te bouwen: content die verandert of vaker dan één keer voorkomt, hoort in een contentlaag met eigen velden, los van de lay-out die hem toont. Haal die twee uit elkaar, en voor een hele categorie aanpassingen heb je geen developer meer nodig.

Oorzaak twee: geen veilige bewerkingsomgeving, dus marketing staat buitenspel

De tweede oorzaak zit in de rechten. Ook als content technisch bewerkbaar is, kun je marketing vaak geen tekst laten aanpassen zonder dat ze ook de lay-out kunnen breken. Dus sluit je ze buiten om de site veilig te houden. Een site die is gebouwd voor één technische beheerder, kent niets tussen volledige toegang en geen toegang. Geef marketing de sleutels, en op een donderdag om vijf uur breekt iemand iets op de hele site. Houd ze achter, en elke wijziging gaat terug naar die ene persoon die hem veilig kan doorvoeren. Voor die keuze gesteld, kiezen de meeste bedrijven voor buitensluiten. En dan belandt elke aanpassing, ook de kleinste, in de wachtrij van de developer.

Daarom is “geef het team gewoon toegang” op de meeste stacks geen echt antwoord. Toegang zonder vangrails ruilt het ene probleem in voor een erger. Waar je moet ingrijpen, is bewerken op basis van rollen: een omgeving waarin marketing kan veranderen wat de site zegt, dus de tekst, de beelden en het samenstellen van pagina's, maar niet wat de site kan, dus de code, de integraties en de structuur. Met vangrails kan een eigenaar de sleutels van de content overdragen zonder bang te zijn voor de lay-out. Zonder zo'n omgeving is buitensluiten echt de veilige keuze. De wachtrij is dan het directe gevolg van een veiligheidsbesluit dat niemand ooit zo heeft genoemd.

Oorzaak drie: de wachtrij verandert gedrag, niet alleen de doorlooptijd

De derde oorzaak is die de backlog verbergt, en het is de dure: een wachtrij vertraagt niet alleen aanpassingen, hij verandert ook wat het team nog probeert. Kost elke wijziging een ticket en wachttijd, dan stellen mensen alleen nog wijzigingen voor die die prijs duidelijk waard zijn. Het halfgevormde idee, de kleine test, het “laten we de hero eens anders aanvliegen”: ze sneuvelen allemaal voordat er een ticket voor is, want een ticket indienen is het niet waard. Het team past zich aan de wachtrij aan door minder te willen.

Hier houdt experimenteren ongemerkt op. Een nieuwe kop testen heeft alleen zin als je er tien kunt testen en de beste houdt. Dat kan alleen als een kop aanpassen niets kost. Hang aan elke poging drie dagen wachten en de aandacht van een developer, en de rekensom van experimenteren klopt niet meer. Niemand draait tien tests via een ticketwachtrij. Dus wordt de site niet meer beter. Niet omdat iemand besloot te stoppen, maar omdat de kosten verbeteren onlogisch maakten, één klein idee tegelijk. De backlog die je ziet, bestaat uit de wijzigingen waar mensen nog de moeite voor namen. Het echte verlies is de onzichtbare wachtrij van alles wat ze niet aanvroegen. Die staat in geen enkel dashboard, en juist daarom blijft hij groeien. Een team dat heeft geleerd dat de site duur is om aan te passen, ziet hem niet meer als iets wat het zelf vormgeeft. Het ziet hem als iets waar het omheen moet werken.

De echte bottleneck: dit is architectuur, geen bezetting

Zet de drie oorzaken naast elkaar en de beperking is duidelijk. De bottleneck is bij de bouw vastgelegd, in hoe content, rechten en structuur in elkaar zijn gezet. Niet in het aantal developers dat je in dienst hebt. Daarom werkt de reflex om er mensen bij te zetten niet. Een extra developer laat de wachtrij sneller doorlopen. Maar een andere kop moet nog steeds door die wachtrij. Je betaalt voor een snellere doorgang door dezelfde muur, en die muur is de architectuur.

Waar het om draait: een trage wachtrij is een symptoom, en extra mensen bestrijden het symptoom. De kwaal is dat gewone content staat waar alleen de mensen met toegang tot de code erbij kunnen. Welke van de twee jij hebt, zie je met de check van hierboven. Nul tot twee contentwijzigingen die een developer nodig hadden? Dan werkt je architectuur grotendeels en is wat bijsturen in capaciteit prima. Drie of meer? Dan lossen geen stand-ups, sprints of nieuwe collega's het op, want het probleem is niet de doorvoer. Het probleem is dat de verkeerde dingen achter slot zitten. Een architectuurprobleem dat je met extra personeel beantwoordt, blijft een architectuurprobleem, alleen met een hogere loonsom.

Waar elke gangbare oplossing vastloopt, en waar de hefboom echt zit

Elke populaire oplossing helpt tegen één oorzaak en loopt vast op een andere. Het loont dus om te weten waar elk ervan ophoudt, voordat je erin investeert. Meer developers laten, zoals gezegd, de wachtrij sneller lopen en de architectuur ongemoeid. Het is de duurste manier om het probleem niet op te lossen.

Een vrije drag-and-drop-builder is de omgekeerde valkuil. Marketing krijgt een leeg canvas en de developer valt uit het proces. Dat voelt als de oplossing, tot meer mensen meer pagina's maken zonder gedeelde structuur, en de site binnen een kwartaal uit de huisstijl loopt en zijn samenhang verliest. Je hebt een content-bottleneck geruild voor een governance-bottleneck. De aanpassingen gaan snel en de site is een rommeltje. Ook dat is een schuld die je later aflost, en vaak een die lastiger terug te draaien is.

Een headless CMS lost de eerste oorzaak, content in de code, netjes op: content staat in gestructureerde velden, redacteuren vullen ze, developers leggen het schema één keer vast. Maar op zichzelf laat het lay-out en paginastructuur vaak nog achter slot. Marketing kan dan een blogpost bewerken, maar heeft nog steeds een developer nodig om een nieuwe pagina voor een campaign samen te stellen. De grens schuift op, en dat is echte vooruitgang, maar hij verdwijnt niet. Teams zijn soms verrast dat er een nieuwe wachtrij ontstaat voor alles wat met structuur te maken heeft.

De hefboom zit waar de drie oorzaken samenkomen: een stack die content scheidt van structuur, een bewerkingsomgeving met vangrails biedt, en marketing een bibliotheek van geteste componenten geeft om nieuwe pagina's mee samen te stellen zonder aan de code te komen. Precies daarom bouw je op moderne omgevingen waarin je direct kunt bewerken. Framer bijvoorbeeld introduceerde on-page editing waarmee iedereen een live site kan bijwerken zonder het canvas te openen of op een deploy te wachten. Daarmee zijn oorzaak één en twee in één keer opgelost. De grotere stap zit in de architectuur, niet in één tool: een site die is gebouwd als een schaalbaar systeem in plaats van een verzameling losse pagina's. Dan gaat marketing over wat de site zegt, en development over wat de site kan. In de projecten waarin Flatline een corporate site rond die grens opnieuw heeft gebouwd, waaronder UX-gedreven werk voor merken als Fugazzi, ging de verandering minder over de tool en meer over wie wat veilig kan aanpassen. Leg de grens goed, en de wachtrij wordt niet sneller. Hij wordt korter, omdat het meeste wat erin stond er nooit in had hoeven staan.

Veelgestelde vragen

Waarom heb je voor elke websitewijziging een developer nodig?

Omdat content en code als één geheel zijn gebouwd. Staan de tekst en beelden van een pagina hard in de template in plaats van in een contentlaag, dan zit je bij elke aanpassing aan de bouw. En aan de bouw zitten is werk voor een developer. Het ligt dus niet aan hoe ingewikkeld de wijziging is. Het ligt aan waar de content staat.

Moet marketing de website kunnen aanpassen zonder developer?

Voor content wel. Een marketingteam kan veilig alles beheren wat verandert wat de site zegt: teksten, beelden, calls-to-action en pagina's samenstellen uit bestaande componenten. Voorwaarde is dat de stack een omgeving met vangrails biedt die ophoudt waar de code begint. Wat de site kan, zoals integraties, structuur en functionaliteit op maat, blijft bij development. De verdeling volgt de grens tussen content en functionaliteit.

Lossen extra developers de backlog van je website op?

Nee, niet als de backlog vooral uit gewone contentwijzigingen bestaat. Meer developers laten de wachtrij sneller lopen, maar een andere kop moet nog steeds door die wachtrij. Dat is een beperking in de architectuur, vastgelegd bij de bouw, en extra mensen bestrijden het symptoom in plaats van de oorzaak. Aannemen helpt alleen als het werk in de wachtrij echt development vraagt.

Welke wijzigingen moet een marketingteam zonder developer kunnen doen?

Alles wat verandert wat de site zegt of laat zien: koppen, lopende tekst, calls-to-action, beelden en video, metatitels en -omschrijvingen, en nieuwe pagina's opgebouwd uit geteste componenten. Alles wat verandert wat de site kan, zoals nieuwe integraties, checkout-logica en interacties op maat, hoort bij development. Kan je team dat eerste lijstje niet zelfstandig afwerken, dan zit de beperking in de architectuur.

Is een no-code websitebuilder de oplossing?

Deels, en alleen met structuur. Een no-code- of headless-aanpak haalt content uit de code. Maar een vrije builder zonder gedeelde componenten ruilt die bottleneck vaak in voor een site die uit de huisstijl loopt en zijn samenhang verliest, zodra meer mensen meer pagina's bouwen. Wat standhoudt, is bewerkbare content gecombineerd met een componentsysteem en vangrails. Dan kost snelheid je geen samenhang.

De belangrijkste punten

• Heeft elke websitewijziging een developer nodig, dan is dat meestal een architectuurprobleem, geen bezettingsprobleem. De beperking is bij de bouw vastgelegd, in hoe content en structuur in elkaar zijn gezet.

• Doe de check: tel van je laatste tien websiteverzoeken hoeveel er alleen veranderden wat de site zegt en toch een developer nodig hadden. Zijn het er drie of meer, dan zit het probleem in de architectuur.

• Drie oorzaken vormen de backlog: content die hard in de pagina staat, geen bewerkingsomgeving met vangrails waardoor marketing buitenspel staat, en een wachtrij waardoor het team helemaal geen wijzigingen meer voorstelt.

• De verborgen kosten zitten in gedrag. De zichtbare backlog bestaat uit de wijzigingen die nog worden aangevraagd. Het echte verlies zijn de experimenten die nooit zijn gedraaid, omdat een wachtrij kleine gokjes onlogisch maakt.

• Elke oplossing loopt ergens vast. Meer developers maken de wachtrij sneller, maar de muur blijft staan. Een vrije builder ruilt een content-bottleneck in voor een governance-bottleneck. Een headless CMS maakt content vrij, maar kan de lay-out achter slot laten. De hefboom is alle drie tegelijk oplossen: content los van structuur, een bewerkingsomgeving met vangrails en herbruikbare componenten.

De backlog zegt niet dat je iemand moet aannemen. Hij zegt dat de site zo is gebouwd dat je moet verbouwen om iets nieuws te zeggen, en dat het team zich daar stilletjes op heeft aangepast door minder te zeggen. Dat is op te lossen, maar niet met een extra stoel in de sprint. Je lost het op door de grens te verleggen tussen wat marketing kan aanpassen en wat alleen development kan. Dan is de tekst op de pagina eindelijk van de mensen wier werk het is om die tekst goed te krijgen.