Dit is een vraag die ik mezelf vaak stel... Ik ben geen ingenieur. Waarom ben ik dan een succesvolle manager van ingenieurs?
Ten eerste weet ik wat ik niet weet, en ik vertrouw hen als materiedeskundigen.
Ten tweede, ik vertrouw maar verifieer. Hoewel ik misschien niet ben opgeleid als ingenieur, heb ik jarenlange ervaring met het luisteren naar ingenieurs, het beheren van IT voor verschillende industrieën, het beheren van complexe IT-projecten en het leiden van IT-ingenieurs. Daarom heb ik manieren ontwikkeld om mijn kennis te koppelen aan die van hen. Dit is de sleutel als het gaat om toonaangevende ingenieurs
Kortom, je hoeft niet per se hetzelfde niveau van technische expertise te hebben als de mensen die je begeleidt om een effectieve manager en leider te zijn. Maar in dit artikel leg ik je uit wat je wel moet weten.
Leidinggeven op technisch niveau – een voorbeeld
Laten we dit bespreken aan de hand van een voorbeeld, een nieuw project. Hieronder vind je enkele overwegingen en een werkproces terwijl jij je team door een technisch proces leidt.
Waar begint een projectgesprek? Uiteraard met de behoeften van de klant en een oplossing die wordt aanbevolen door een verkoper of een ingenieur (afhankelijk van jouw bedrijfsstructuur). Vervolgens moet een materiedeskundige, oftewel een ingenieur, de oplossing verifiëren en eventuele ontbrekende stukjes invullen. De stappen die ik zou voorstellen en staan hieronder.
Bekijk de lessen die zijn geleerd uit eerdere projecten. Onderhoud een database met projecten per branche, besturingssysteem, applicatie en meer, of een verzameling projectplannen - inclusief afsluitingsdocumenten - om als referentie te gebruiken. Projectplannen, vergaderagenda's en notulen, en urenstaten moeten ons vertellen waar we het hebben gehaald, overschreden of onder het budget zaten. Wijzigingsorders moeten ons informeren over aanvullende vragen en mogelijke hindernissen die wellicht moeten worden overwonnen. Dit is verplichte lectuur. Als iemand verklaart "dat zal niet gebeuren met dit project", moeten ze het team kunnen vertellen waarom. Dat antwoord kan nog een andere invalshoek oproepen die moet worden onderzocht.
Vraag de ingenieur om de oplossing te tekenen. Zorg dat voor elke stap een regelitem in het projectplan staat en een urenbudget om dezen te voltooien. Het urenbudget mag zich niet beperken tot het afronden van de werkzaamheden; voeg ook het volgende toe: voorbereiding (het maken van nieuwe of bijwerken van bestaande documentatie van de huidige omgeving, het maken van back-ups van huidige configuraties, OS- of applicatie-upgrades, bijvoorbeeld), voltooiing van het werk - inclusief onderbrekingen buiten kantooruren indien vereist door de klant - en vervolgens het maken of bijwerken van omgevingsdocumentatie .
Zorg dat de projectplannen van nieuwere ingenieurs worden beoordeeld door ervaren veteranen. Zelfs als de veteraan dit exacte project niet heeft voltooid (zelden of nooit zijn twee IT-projecten hetzelfde), zal hun praktijkervaring waardevol blijken, hetzij in de vorm van suggesties of in eenvoudige verificatie dat "het" zal werken.
Er is meer dan één manier om elke taak te voltooien. Stimuleer dialoog. Dat we allemaal anders denken, is de beste manier om te zorgen dat we het project vanuit elke hoek hebben benaderd die we kunnen bedenken, individueel en collectief.
Als je dit nog niet hebt gedaan, begin dan met het documenteren van succesvolle, gestandaardiseerde installaties. Deze, die naast je projectbibliotheek worden gebruikt, bieden je niet alleen het kader voor dit project, maar ook voor het volgende. Zet de dialoog rond deze standaard voort met elke ingenieur die deze omgeving bouwt, en wijzig deze naarmate besturingssystemen en applicaties veranderen en naarmate nieuwe lessen worden geleerd. Deze gestandaardiseerde installaties dienen voor elke fase een voorgesteld budget te bevatten. Als je nu je tijd besteedt aan het documenteren van deze kennis, zal je toekomstige planning efficiënter en je projecten nauwkeuriger worden, waardoor niet alleen de klanttevredenheid toeneemt, maar ook de tevredenheid van de ingenieurs en je bedrijf.
Hoe een MSP-team op interpersoonlijk niveau te leiden?
Hoewel het bovenstaande een goed voorbeeld is, is het meer procedureel en procesgericht, toch? Het zijn waarschijnlijk dingen die je al doet (of al zou moeten doen). Tot nu toe wordt alleen geschetst hoe je op technisch niveau met ingenieurs kan communiceren. Maar hoe communiceer je als mens met ingenieurs? Dit is waar MSP-leiderschap een kunst wordt en minder een proces.
Om te beginnen is het belangrijk dat je gelooft dat jouw team elke dag naar het werk komt met de wens om succesvol te zijn.
Zorg dat je hen regelmatig spreekt, zowel als groep als als individu. Ik vind het een succes om maandelijks een vergadering met mijn team tijdens de lunch te houden, waarbij ik hun lunch aanbied (en hen de mogelijkheid geef om het eten te beslissen). Soms heb ik een agenda (bedrijfsupdates, geruchten om te verduidelijken, doelen te stellen, input nodig), en soms praten we gewoon over wat hen bezighoudt. Ja, we maken aantekeningen (maar niemand heeft ooit gevraagd om ze te zien.) Moedig een vrij, respectvol dialoog aan. Het factureerbare werk, dat van tevoren wordt gepland, kan meestal om deze vergaderingen heen worden gepland, zodat het hele team er persoonlijk bij kan zijn. Dit is belangrijk omdat het zeldzaam is dat IT-teams allemaal tegelijk aan hun bureau zitten met de mogelijkheid om als teamgenoten te werken.
Werken bij een MSP is stressvol werk. De eisen van meerdere klanten, meer werk dan tijd om het af te ronden, onverwachte storingen... dit alles kan zwaar wegen op de ingenieurs. Als een ingenieur voelt dat er niemand is om de verantwoordelijkheid te delen, kan dit leiden tot een burn-out. Als de ingenieur weet dat hij/zij een team heeft om op te vertrouwen als/wanneer dat nodig is, is de werktevredenheid (en dus het behoud) hoger.
Bij elke bijeenkomst vraag ik ze iets te vertellen dat ze onlangs hebben geleerd. En ook al zijn ze in loondienst, ik respecteer hun recht op een belastingvrije pauze en moedig ze aan om voor of na onze lunchbijeenkomst een uurtje voor zichzelf te nemen.
Ik plan elk kwartaal gesprekken met individuele leden van mijn team. (Hierover volgt meer.) Door hen individueel en als team te spreken, kan ik het verschil onderscheiden tussen een individuele zorg en een zorg die door het team wordt gedeeld. Dit helpt me te weten waar ik mijn inspanningen moet richten op het begeleiden en ondersteunen van ingenieurs.
Inmiddels vraag je jezelf af: "wanneer moet ik in al deze vergaderingen houden?" Je bent er al mee bezig. Maar de tijd die je besteedt, is waarschijnlijk eerder reactief dan proactief. Ik werk hard om de gesprekken met mijn personeel te plannen, in plaats van tijd te maken voor gesprekken die moeten plaatsvinden omdat er iets mis is gegaan. Hier is hoe.
Effectieve vergaderingen houden met je team
Teamvergaderingen (lunch) – Kies een dag van de week die waarschijnlijk de minste impact heeft op de factureerbare tijd. Kies een week van de maand. Stuur een uitnodiging voor een vergadering naar je team, inclusief een vergaderruimte en al het administratief personeel dat nodig is om dit tot een succes te maken, maak het een terugkerende vergadering, 12 maanden per keer. Markeer in je agenda 3 maanden voor de laatste vergadering om de dag van de week en week van de maand opnieuw te evalueren en de nieuwe terugkerende vergadering te maken (en te delen) (of ga door zoals het is, verleng het einde van de terugkerende vergadering.), voor jezelf, een terugkerend agenda-item een paar dagen voor elke vergadering om lunch te bestellen, Agenda-items op te roepen en het eerste concept van de Agenda te maken. Maak direct voorafgaand aan de vergadering een terugkerend agenda-item om de agenda af te ronden, de ruimte in te stellen en de lunchbezorging te beheren.
Ontmoeting met individuen – Plan op de eerste dag voor een nieuwe medewerker een follow-up binnen de eerste week; nog een follow-up na een periode van twee weken; nog een follow-up drie weken later; daarna maandelijks gedurende de eerste 6 maanden. Daarna zijn de individuele bijeenkomsten driemaandelijks, in lijn met de indienstnemingsdatum. Deze zijn eenvoudig van tevoren in te plannen. Als er iets moet veranderen, moet de ingenieur een nieuwe afspraak met mij maken (of ik met de ingenieur). Laat het onbekende je niet van weerhouden om te plannen. Zet het nu in de boeken en je zult het niet over het hoofd zien. De huidige medewerkers hebben een afspraak met mij voor hun evaluatie in de maand van hun aanstelling. Ze zullen ook elk kwartaal een ontmoeting met mij hebben. Maak een spreadsheet met de naam en datum van inhuur. Documenteer de corresponderende data per kwartaal. Verstuur uitnodigingen voor vergaderingen. Wanneer dit een gewoonte is, worden de vergaderingen in de regel vrij kort.
Hieronder een voorbeeld voor de agenda van individuele gesprekken. Plaats deze vragen in de uitnodiging van de vergadering, zodat iedereen voorbereid naar het gesprek komt.
HOU je van je werk?
Zo ja, waar hou je specifiek van?
Zo nee, wat weerhoudt je om van je werk te houden?
Wat zijn 3 dingen die je hebt bereikt en waar je trots op bent, sinds onze laatste een-op-een?
Wat heb je van mij nodig om te slagen?
Wat moet je doen om te slagen?
Hoe was het (kijkend naar de afgelopen 90 dagen) om door mij begeleid en ondersteund te worden? (Deze vraag stelt je in staat om jouw 'niveau' en stijl van management aan te passen als dat nodig zou zijn voor de ingenieur of voor het team.)
Wat zou je willen dat <naam van CEO of andere leidinggevende> wist? (Deze vraag is vooral goed binnen een groter bedrijf of wanneer er onenigheid lijkt te zijn binnen een team)
Eis niet van ingenieurs dat ze van hun werk houden, of dat ze jou waarderen als hun manager. Ik zelf neem dit soort vergaderingen niet op. De enige aantekeningen die ik maak zijn die items die ik mezelf moet begeleiden om te verbeteren of door te gaan, mocht er iets in mijn managementtoolbox zitten dat de ingenieur nuttig vindt. Maar deze open dialogen werken. Het maakt het voor mij gemakkelijker om toezicht te houden en te ondersteunen, omdat maar weinig dingen in me opkomen die me verrassen. Je zal zien dat je je geïnformeerd en verbonden zal voelen, wat betekent dat de retentie hoog is. Als een ingenieur toch besluit te vertrekken, zal je hem moeten laten weten zijn keuze te waarden.
Final Thoughts
Een bonus van deze methode van supervisie en ondersteuning is dat ik vind dat ingenieurs het gemakkelijk vinden om in mijn kantoor te komen als dat nodig is, omdat ze me zien als een medewerker, niet alleen als hun baas. En ze weten dat ik gewoon zal luisteren. Als een medewerker vraagt of ik even tijd heb of gewoon in mijn kantoor verschijnt, en het lijkt erop dat iets in zijn/haar gedachten is, vraag ik of ze hier zijn om te luchten of dat ze hulp nodig hebben bij het oplossen van een probleem. Hun antwoord bepaalt hoe ik luister. Als een medewerker binnenkomt om zijn hart te luchten, zoekt hij/zij mijn moed en geruststelling. Als hij/zij hulp zoekt bij het oplossen van een probleem, moet ik reageren met mijn vaardigheden en ervaring.
Is mijn systeem onfeilbaar? Bij lange na niet. Ik ben best goed in het lezen van mensen, maar als ik het mis heb, heb ik het echt vreselijk mis. Het doet pijn om blind te zijn. Maar ik leer. En ik stop niet met proberen. Jij ook niet.
Meer tips over hoe jij je bedrijf nog efficiënter, productiever en winstgevender kan inrichten? Plan een gratis adviesgesprek met één van onze adviseurs.