De verschuiving in de DevOps-mentaliteit: leiderschapslessen van een CTO
V: Heb je een mentor die je tot nu toe heeft geïnspireerd of geholpen tijdens je loopbaan?
Dat zijn er zoveel. Deel uitmaken van de start-upgemeenschap in Raleigh, North Carolina, is geweldig geweest, en tientallen mensen hebben me geholpen op manieren waarvan ze zich misschien niet eens bewust zijn. Hoewel ik specifieke namen zou kunnen noemen, hebben enkele belangrijke verhalen mijn kijk op de wereld gevormd.
Eén verhaal komt van een verkoopleider die sprak tijdens een van mijn bachelorlessen ondernemerschap. Als student techniek die zich richtte op programmeren en het ontwikkelen van technische vaardigheden, waren verkoop en alles wat daarmee te maken had zowel vreemd als oninteressant voor mij. Deze persoon deelde echter een verhaal waardoor ik de zaken anders ging bekijken.
Hij vertelde over een gesprek met een van zijn technische collega's. De collega zei: “Ik begrijp niet hoe je dat doet.” De verkoper antwoordde: “Wat doen?” De collega reageerde: “Een verkoopquotum halen. Het moet zo stressvol zijn om gedwongen te worden te verkopen om in je levensonderhoud te voorzien.” Hij dacht hier even over na en antwoordde eenvoudig: “Dat is het ook, maar als ik niet verkoop, eet jij ook niet.”
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Dit verhaal hielp me techniek echt in perspectief te plaatsen.
Je kunt het coolste product of de beste dienst bouwen, maar als je de waarde ervan niet kunt aantonen aan de mensen die ermee geholpen zullen worden, ben je slechts aan het werken in een vacuüm.
Een andere persoon die me hielp, was een mentor die leiding had gegeven aan technische bedrijven en afdelingen en daarna zijn carrière verlegde naar het helpen van mensen bij het uitwerken van hun ideeën en het vinden van functies bij verschillende start-ups. Hij coachte me bij veel uitdagingen, maar een van de belangrijkste inzichten die hij me meegaf, was dat de meeste leiders van technische organisaties uitblinken op een van drie gebieden:
de “Hoofdnerd”, de rockster onder de managers of de belangrijkste productpersoon. Hij vervolgde dat een succesvol bedrijf alle drie nodig heeft en dat een goede leider moet vaststellen wie hij of zij is, waarna diegene mensen moet aannemen voor de andere vaardigheden. Dit heeft me geholpen mijn groei als technisch leider te begrijpen en te bepalen wanneer ik meer of juist minder nadruk op bepaalde gebieden moet leggen.
V: Kun je drie sterke punten of vaardigheden noemen die belangrijk zijn geweest tijdens je loopbaan?
Een motto dat ik volg, is: “Pas je aan en onderscheid je daarna.” Hoewel het een gevatte uitspraak is, herinnert het me eraan dat ik eerst het team moet leren kennen wanneer ik met een nieuw team werk. Begrijpen waarom de dingen zijn zoals ze zijn, is essentieel voor het opbouwen van vertrouwen.
Als ik bijvoorbeeld op dag één binnenkom en probeer een grote verandering door te voeren of daarvoor te pleiten, zal de standaardreactie weerstand zijn en heb ik mijn werk voor de toekomst moeilijker gemaakt. Het is belangrijk om binnen een nieuw team eerst te zoeken naar overeenkomsten en gebieden van overeenstemming voordat je de status quo ter discussie stelt of grote veranderingen doorvoert. Deze aanpak geldt voor het opbouwen van nieuwe relaties in elk onderdeel van het leven.
Een ander gezegde dat me richting geeft, is: “Wat mensen zeggen en doen, correleert slechts gedeeltelijk met wat ze denken en voelen.” Hoewel het pessimistisch kan klinken, vind ik het een mooi idee dat mensen vaak onder enorme druk staan om op een bepaalde manier te handelen of te spreken.
Wanneer je iemand bijvoorbeeld vraagt hoe zijn of haar dag verloopt, antwoordt die persoon bijna altijd: “Goed,” in plaats van zich open te stellen en echt te vertellen hoe het met hem of haar gaat. Bij het werken met teams en groepen is het belangrijk aandacht te hebben voor die druk om anderen werkelijk te begrijpen en empathie te tonen. Als iemand bijvoorbeeld aan jou rapporteert, kan het voor die persoon moeilijk zijn verantwoordelijkheid te nemen voor een fout als hij of zij bang is voor de gevolgen.
Als leider is het essentieel om onze omgeving op te bouwen en voortdurend te evalueren, zodat openheid wordt bevorderd. Anders kunnen we onbedoeld een cultuur creëren waarin problemen binnen het team blijven etteren en niet worden aangepakt.
Bij het aansturen van teams moeten mensen voortdurend introspectief en retrospectief zijn om sterke vaardigheden te ontwikkelen. Hoewel “naar binnen kijken” voor mij werkt, hoeft dat niet voor iedereen goed te werken, en een goede leider moet de verschillende manieren herkennen waarop individuele mensen leren en groeien.
Een effectieve leider richt zich op het vinden van een balans tussen prestaties en empathie en reflecteert voortdurend op zijn of haar eigen sterke en zwakke punten, evenals op die van het bredere team.
V: Aan welke vaardigheden probeer je nu nog te werken?
Terugkomend op het advies van een van mijn mentoren: ik werk voortdurend aan de managementpijler van de drie rollen van een technische leider. Ik heb het geluk gehad samen te werken met een collega die daar geweldig in is en die me enkele belangrijke manieren heeft laten zien om te groeien en mezelf te verbeteren.
Als medeoprichter van een technologiestart-up heb ik me sterk gericht op technologie en producten en gewerkt met kleine teams. Nu onze organisatie groeit, moet ik met haar meegroeien. Management is net zo goed een vaardigheid als softwareontwikkeling.
V: Laten we het hebben over een succesvol DevOps-team. Wat zijn de belangrijkste doelen die een DevOps-team kan bepalen voor een traject van digitale transformatie?
Een van de belangrijkste dingen die ik van andere leiders hoor, is dat er binnen je organisatie een gedeeld begrip moet bestaan van wat DevOps betekent. Ik heb organisaties gezien waar "DevOps" betekent dat er een SRE wordt aangenomen, die persoon een DevOps-engineer wordt genoemd en dat men vervolgens feestviert.
Een belangrijke eerste stap is om de kernonderdelen van de DevOps-cyclus te nemen en in kaart te brengen hoe werk en ideeën door je ontwikkelproces stromen. Neem één ontwikkelingsticket vanaf het begin en volg het tot het moment waarop het volgende ticket ontstaat; mogelijk ontdek je dan enkele belangrijke hiaten.
Je kunt bijvoorbeeld ontdekken dat je QA-team afgescheiden is en dat je een mentaliteit hebt van “gooi het over de muur”, waardoor je minder snel kunt werken. Zodra je die processtroom binnen je organisatie begint te definiëren, kun je kijken naar hulpmiddelen die kunnen helpen.
Veel organisaties beginnen met hulpmiddelen en proberen van daaruit langzaam en moeizaam organisatorische verandering te bewerkstelligen. Dat is een achterhaalde manier om te beginnen.
V: Zijn er uitdagingen of veelvoorkomende valkuilen waar DevOps-teams rekening mee moeten houden?
DevOps is een manier van werken. In veel opzichten is het het vervolg op de agile transformatie die decennia geleden door de softwareontwikkelingssector trok. Het is belangrijk om het ook zo te zien. Veel organisaties hadden moeite met agile transformatie door een gebrek aan begrip en draagvlak bij de leiding. Leiders dachten dat we stand-ups zouden gaan houden en 50 procent meer tickets zouden afronden. Achteraf gezien was dat natuurlijk onjuist.
Op dezelfde manier denken leiders vandaag dat we alleen een CI/CD-pijplijn nodig hebben om beter te presteren op DORA-metrieken en dat we een productiviteit van 50 procent zullen zien. De verandering in mentaliteit is cruciaal. DevOps maakt volledig eigenaarschap van de softwareleveringslevenscyclus mogelijk, waardoor teams betere systemen kunnen bouwen. DevOps stelt teams in staat om te bepalen hoe ze beter kunnen worden en dit te implementeren. Daarom moeten leiders de ruimte en ondersteuning creëren om de organisatorische effecten echt zichtbaar te maken.
V: Hoe kunnen effectieve samenwerking en communicatie tussen teamleden de productiviteit en het succes van een DevOps-team vergroten, en welke werkwijzen kunnen dit bevorderen?
Communicatie is cruciaal binnen engineering. Bijna elk probleem komt neer op slechte communicatie, en bij DevOps is dat niet anders. Als we teruggaan naar het hebben van een gedeeld begrip van wat DevOps betekent voor je organisatie, moet je echt begrijpen waar je naartoe gaat en die gedeelde visie hebben om kans van slagen te maken.
Enkele van de belangrijkste werkwijzen die ik heb gezien, zijn het definiëren van eenvoudige fasepoorten in je proces. Deze moeten betrekking hebben op het werk en niet op de mensen die het werk uitvoeren. Door vastgelegde processen te hebben voor de manier waarop taken en informatie door je team stromen, kun je efficiënt schakelen, vooral wanneer er onderbrekingen in het werk optreden. Ook kun je zo verschillende onderdelen van je team onafhankelijk van elkaar opschalen.
Elk team en elk product heeft iets andere behoeften. Door die poorten te definiëren en vast te leggen wat er bij elke poort moet gebeuren, krijg je inzicht in waar je inefficiënties zitten.
Vraag: Welke rol speelt CI/CD in DevOps en wat zijn de beste werkwijzen voor het implementeren van CI/CD-pijplijnen om een naadloos en betrouwbaar software-releaseproces te garanderen?
Het is cruciaal om softwarewijzigingen zo snel mogelijk van idee naar productie te brengen. Handmatige processen zijn extreem traag en afhankelijk van mensen. Mensen zijn weliswaar goed in zaken als probleemoplossing en creativiteit, maar zijn vaak slecht in het honderden keren per dag volledig doorlopen van controlelijsten. Door het vervelende werk te automatiseren, kan je team zich echt richten op waar het in uitblinkt. Bovendien zijn computers uitzonderlijk snel en kunnen ze snel opschalen. Het creëren van een pijplijn die gebruikmaakt van die mogelijkheden is het belangrijkste voordeel van het invoeren van een CI/CD-proces.
Een belangrijk punt om te onthouden bij het opbouwen van een dergelijk proces is dat je snelheid en veiligheid in balans moet houden. Hoewel je elke commit van een ontwikkelaar die rechtstreeks naar productie gaat volledig kunt automatiseren, biedt dat geen enkele veiligheid. Door je pijplijn zo op te bouwen dat dit snelheidsniveau mogelijk is en geleidelijk controles toe te voegen, kun je jezelf in de toekomst helpen. Misschien moet in het begin alles expliciet worden goedgekeurd door een QA-engineer en een release-engineer, maar bestaat het daadwerkelijke proces misschien alleen uit het indrukken van een knop.
Zodra je geautomatiseerd testen hebt ingevoerd, kun je de goedkeuring door QA mogelijk elimineren.
Vraag: Hoe draagt het bevorderen van een DevOps-cultuur en -mentaliteit bij aan het algehele succes van een DevOps-team, en welke strategieën kunnen organisaties gebruiken om deze cultuur binnen hun ontwikkelings- en operationele teams te stimuleren?
De belangrijkste strijd in deze transformatie is het bestrijden van de mentaliteit van “gooi het over de muur“. Als je nieuw bent in dit traject, heb je misschien vijf of zes teams die elk onderdeel van het werk moeten aanraken voordat het in productie terechtkomt. Bij de overgang naar DevOps bevorder je gedeeld eigenaarschap over de volledige levenscyclus van dat product.
Dit kan aanzienlijke veranderingen vereisen in de manier waarop je je oplossing ontwerpt, bouwt en implementeert. Hoewel veel mensen bekend zijn met het creëren van software die beter testbaar is, vereist het invoeren van een DevOps-cultuur het bouwen van systemen en platforms waarvan kleine teams het eigenaarschap van begin tot eind dragen.
Vraag: Wat zijn de “5 essentiële onderdelen van een succesvol DevOps-team”? Deel voor elk onderdeel een verhaal of voorbeeld.
1. Een gedeeld begrip van wat DevOps voor je organisatie betekent. – Een van de meest contraproductieve DevOps-initiatieven ontstaat wanneer het management en het team niet op één lijn zitten wat betreft de resultaten. DevOps is veel meer dan alleen het aannemen van “DevOps”-engineers en het aanschaffen van een CI/CD-tool. Zodra je het erover eens bent dat het om een verandering van mentaliteit gaat, geef je de teams de mogelijkheid om echt eigenaar te zijn van de end-to-end levering van klantwaarde
2. Ruimte en ondersteuning om veranderingen te identificeren en door te voeren – DevOps-teams identificeren vaak veel manieren om de levering en de efficiëntie van het team te verbeteren. Als je geen ruimte biedt voor deze verkenning, beperk je echt de impact die je team kan hebben bij het stimuleren van verandering.
3. Manieren om succes aan de hand van gegevens te meten en identificeren – Iedereen is bekend met de DORA-statistieken: vier belangrijke metingen van je ontwikkelorganisatie waarmee je de DevOps-volwassenheid beoordeelt. Hoewel dit een goed begin is, moet je vaststellen wat het zijn van een DevOps-organisatie voor jouw bedrijf betekent – en dat moet je doen aan de hand van gegevens.
4. Een product dat is gebouwd om eigenaarschap en ontwikkeling van deze filosofie te ondersteunen – DevOps is voor veel organisaties een geweldige filosofie, maar vaak zijn bedrijven nog niet klaar om de transformatie te omarmen. Je moet ervoor zorgen dat je product kan worden ondersteund door een gecombineerd operationeel en ontwikkelingsteam. Producten die lokaal worden gehost, producten met starre releasecycli en producten die simpelweg niet volwassen genoeg zijn om een dergelijk team te ondersteunen, passen mogelijk niet goed. Je zult enkele voordelen zien wanneer je team een meer operationele mentaliteit aanneemt, maar de impact blijft beperkt.
5. Automatisering en hulpmiddelen - Zorg ervoor dat zaken consistent en snel gebeuren en zorg voor verantwoordelijkheid bij het naleven van werkafspraken. Een van de belangrijkste veranderingen in een DevOps-organisatie zijn de werkafspraken die je met je team en tussen je teams maakt. Als je een testproces instelt waarvoor alle code vóór implementatie regressietests moet ondergaan, moet je dit automatiseren. Je moet geautomatiseerde controles en poortwachters instellen om dat te garanderen. Zodra je deze hulpmiddelen en werkwijzen hebt ingevoerd, ontdek je vaak dat ambitieuze doelen zoals continue implementatie nog maar een paar stappen verwijderd zijn.
Zorg ervoor dat het testen niet alleen wordt uitgevoerd, maar ook aan uw kwaliteitsnormen voldoet.
V: Welke opkomende trends ziet u die in de toekomst een aanzienlijke invloed kunnen hebben op strategieën voor digitale transformatie?
Veel van de grootste beloften van zaken als de overstap naar DevOps zijn gebaseerd op gegevens op hoog niveau en brede resultaten. Vaak zijn deze kengetallen, zoals “uw organisatie is 50 procent efficiënter”, vrijwel onmogelijk te meten en kan het moeilijk zijn om te verifiëren dat u dergelijke resultaten daadwerkelijk behaalt.
Ik verwacht dat er meer gerichte inspanningen zullen worden geleverd om voor elke organisatie specifieke resultaten vast te stellen voordat aan een meerjarig traject voor digitale transformatie wordt begonnen. Dit sluit niet alleen aan bij de toegenomen focus op bedrijfsefficiëntie van de afgelopen jaren, maar waarborgt ook succes. In plaats van brede doelstellingen zoals de eerder genoemde, zijn specifieke (maar impactvolle) doelen, zoals “We lossen problemen van klanten 25 procent sneller op”, gerichter.
Groei bevorderen door mentorschap
De kracht van mentorschap en open communicatie blijkt duidelijk uit de reis van Jeremy Freeman. Door actief van anderen te leren en een samenwerkingsgerichte omgeving te bevorderen, kunnen leiders hun DevOps-teams in staat stellen geweldige dingen te bereiken.
Abonneer u op de nieuwsbrief van The CTO Club voor meer interviews, inzichten in DevOps en tips over mentorschap!