Bedrijf begrijpt niet wat de "busfactor" is en blijft mij steeds meer verantwoordelijkheden geven

Ik heb het concept “busfactor” uitgelegd aan mijn manager (die de CTO van het bedrijf is; er is niemand boven zijn hoofd om naartoe te gaan) en aan andere senior mensen in het bedrijf, en hun antwoord is “we moeten dit snel doen, je weet hoe het moet, doe het gewoon en verspil je tijd of bedrijfstijd niet aan het lesgeven of coachen van anderen”.

Heeft iemand suggesties over hoe ik mijn eigen persoonlijke “busfactor” in deze situatie kan verlagen?

De CTO heeft je verteld wat je moet doen. Je moet zijn aanwijzingen volgen.

Je kunt echt goede documentatie maken in je vrije tijd, en eenvoudige, eenvoudige systemen en processen bouwen. Beide zullen helpen als je er niet meer bent.

Maar in principe is dit niet jouw probleem om op te lossen**. Per definitie, als je “geraakt wordt door een bus” (of anders niet in de buurt bent), moeten anderen het probleem van je afwezigheid oplossen.

De CTO mag beslissen hoe het werk van zijn team wordt toegewezen. Je hoeft alleen maar mee te gaan.

Het is het probleem van iemand anders.

Het is erg attent van je dat je niet het enige punt van mislukking wilt zijn voor je hele organisatie. Meer mensen zouden zo attent moeten zijn voor hun collega’s en zo loyaal aan hun bedrijf.

Maar als je waarschuwingen in dovemansoren vallen, dan heb je gedaan wat je kon. Dus in plaats van nog meer tijd en energie te verspillen aan het voorkomen dat de CTO zo'n grote fout maakt, gebruik je het gewoon in je voordeel. Geniet van de werkzekerheid. De volgende keer dat je opnieuw wilt onderhandelen over je salaris, vergeet dan niet te vermelden hoe afhankelijk het bedrijf is van je nichekennis en in hoeveel moeite ze zouden zijn als je zou besluiten om te vertrekken.

Je hebt het nummer één ding gedaan dat je kunt doen om het bedrijf te helpen: het onder hun aandacht brengen en hen de kans geven om hier voor te gaan. Ze hebben besloten om geen actie te ondernemen, met de uitspraak “verspil je tijd niet” proberen ze de discussie met kracht te beëindigen. Je blijft in principe achter met een aantal dingen die je zelf kunt doen om het bedrijf te helpen:

1. 1. Schrijf documentatie. Als iemand die softwareprojecten heeft overgenomen waar niemand in het bedrijf weet hoe ze werken, zou ik veel sneller aan boord zijn gekomen met betere documentatie. Algemene bouwkundige schema’s voor het project en state machines voor de gecompliceerde onderdelen bieden waarschijnlijk de grootste knal voor je bok.
2. 2. Schrijf tests. Een goede testsuite zal anderen onmiddellijk informeren dat hun veranderingen dingen breken. En natuurlijk biedt zelfs een slecht testpakket enige bescherming.

Het grote voordeel van beide dingen is dat je ze nodig hebt of je nu wel of niet door een bus wordt aangereden. Stel dat je baas het op een dag op jouw manier ziet en iemand anders inhuurt om het project over te nemen, dan zal het hebben van goede documentatie en testen je helpen om het project door te geven aan iemand anders zonder een vreselijke overgangsperiode. Goede tests zullen je ook helpen om slechte code te weigeren als de persoon die ze inhuren te ambitieus is in het updaten van de code.

Ik ga een paar dingen herhalen die anderen met een andere nadruk hebben gezegd:

• Het hebben van een lage busfactor is goed voor jou.
• Het hebben van een lage busfactor is slecht voor het bedrijf.
• Je neemt te veel verantwoordelijkheid voor het bedrijf.

Je hebt de kwestie aan je superieuren voorgelegd, en dat is goed en eervol en je hebt geprobeerd om het bedrijf robuuster te maken. Als het verhogen van de busfactor niet lukt, dan verhoogt dat alleen maar je persoonlijke waarde en hefboomwerking in de volgende verhogings-/salarisonderhandelingen. (Het is een veel voorkomende grap dat iemand zichzelf op deze manier onmisbaar zou kunnen maken.)

** Neem niet de kant van het bedrijf in je denken over verantwoordelijkheden.** (Tenzij je misschien de eigenaar bent, wat je duidelijk niet bent. ) Maak gebruik van de hefboomwerking die je hebt gekregen in je volgende onderhandelingen. Dit lijkt misschien onaardig of ongaarne, en een beetje vreemd dat je de meeste dagen samenwerkt voor het bedrijf, maar in de salarisonderhandelingen moet je op jezelf letten en niet op het bedrijf. Ze zouden je bijna zeker laten vallen zodra de zakelijke logica zinvol was. Als ze je belasten met meer verantwoordelijkheid voor het welzijn van het bedrijf, dan moeten ze bereid zijn je meer te betalen, of anders te lijden als je naar groenere weiden gaat (met een goedgebrande cv, gezien alles wat je kunt zeggen dat je hebt afgehandeld).

Maar: Het klinkt voor mij alsof je het idee aan je superieuren verkoopt als, “huur meer mensen in zodat ik ze dingen kan leren”, wat zelfs in mijn oren klinkt als een verspilling van middelen (mensen inhuren die alleen maar dingen leren en niets doen, zoals bankzitters?). Het verkooppraatje hier moet in termen zijn die de zakenmensen begrijpen, zoals, “We moeten iemand inhuren die de server kan beheren, omdat ik te veel tijd verlies aan context-schakelen van ontwikkelingstaken”. Je moet een echte job of project pitchen voor mensen om te doen, niet alleen een ontvanger van het leren. Als je eenmaal extra mensen aan je project hebt toegewezen, dan moet het gemakkelijk zijn om een verscheidenheid aan taken uit te delen, zodat ze verschillende delen van de technologie leren. Dat zou het bedrijf geen extra geld kosten, en het zal veel gemakkelijker zijn om de senior mensen te laten accepteren – of misschien hoeven ze gewoon helemaal niets te weten over dat deel. Hoe dan ook, het eerste verkooppraatje aan het bedrijf moet zijn: “We hebben meer mensen nodig die aan dit project werken om het beter/sneller te maken”, niet “We hebben meer mensen nodig om meer te leren”.

Het is een startup , dus de regels van het spel zijn heel anders.

Meestal is een risicovolle strategie van gewoon doen zonder al te veel te plannen voor alle eventualiteiten absoluut de manier om te gaan. Meestal zijn er veel dingen die slechts door één persoon gedaan kunnen worden - er zijn gewoonweg niet genoeg middelen om in te huren voor redundantie van vaardigheden. Het is de aard van het spel.

Ik heb een beetje een probleem… het bedrijf waar ik voor werk… begint me meer en meer verantwoordelijkheid te geven en probeert me verantwoordelijk te maken voor meer en meer stukken van de applicatie

Dat is helemaal geen probleem, het is een fantastische kans voor je - een van de beste dingen over het werken bij een startup. *Grijp het! *

Ik heb het concept van “busfactor” uitgelegd aan mijn manager… en aan andere senior mensen

Hun antwoord is “we need this done fast, you know how to do it, just do it and don’t waste your time or company time teaching or coaching others”

Ze hebben volledige informatie, je hebt je professionele plicht gedaan om daar zeker van te zijn, en ze hebben besloten over deze legitieme strategie. **Voer het uit!

Ik denk dat je de situatie verkeerd inschat. Moderne technische bedrijven hebben de neiging om de jongere arbeidskrachten aan te spreken door het aanbieden van wat onmisbaar en zeer belangrijk lijkt voor de organisatie. Ze doen dit door u de enige verantwoordelijke persoon te maken, u de “go to” persoon te laten lijken voor een bepaald onderwerp en u schijnbaar dure dingen aan te bieden zoals laptops, visitekaartjes, training/lessen/conferenties, en zelfs uw eigen bed of 24/7 toegang tot de fitnessruimte. Dingen die ooit alleen beschikbaar waren voor CEO’s en het hoger management worden nu aangeboden aan de laagste technische medewerker als onderdeel van hun onboarding proces.

Met dat gezegd hebbende, bent u niet de “busfactor”. Ik haat het om te zeggen. Ik kan het zien omdat ze je al verteld hebben dat je moet stoppen met klagen en het werk doen dat ze gezegd hebben.

Mijn advies: maak je er geen zorgen over. Het is niet jouw probleem als het bedrijf ten onder gaat. Mijn gedachte is echter dat je niet zo belangrijk bent voor de organisatie als je denkt dat je bent. Dat is een beetje gemeen, maar het is de waarheid. Doe gewoon je werk en als je overwerkt raakt, betekent het dat je ze te veel hebt toegestaan. Maak jezelf druk en zeg dat je het niet kunt omdat je verplichtingen hebt. Je krijgt minder van de noodgevallen eisen en je zult zien dat ze die nieuwe “ga naar” man helemaal alleen vinden.

Ik ben het eens met de meeste van wat iedereen zegt, maar ik denk dat er iets ontbreekt:

Er zit ook een potentieel cynische kant aan. Tenzij uw CTO zeer onervaren is, zou hij het operationele risico perfect moeten begrijpen door één persoon te hebben die verantwoordelijk is voor zoveel van de tech-stack. Het kan zijn dat hij echt gelooft dat hij elke druppel efficiëntie moet uitknijpen in het hebben van iedereen die in silo’s werkt, maar tot dit uiterste wordt genomen lijkt niet realistisch. In deze markt kan het inhuren van software talent voor startups erg moeilijk zijn en ik heb gezien/gehoord dat startups een aantal verraderlijke dingen doen om hun talent te ontmoedigen om elders te gaan.

Het is mogelijk dat uw CTO wil dat mensen de enige verantwoordelijkheid hebben over dingen, zodat ze zich misschien schuldig voelen over het verlaten van het bedrijf. Als u een ander aanbod krijgt, zou u zich misschien minder schuldig voelen over het nemen van het aanbod als u wist dat uw huidige werkgever slechts een kleine tegenslag zou ondervinden van uw vertrek. In plaats daarvan, omdat er zoveel is waar je verantwoordelijk voor bent, zou het verlaten van hen een grote klap kunnen veroorzaken. Ervan uitgaande dat je goede wil hebt ten opzichte van je huidige collega’s, zou het veroorzaken van grote problemen je natuurlijk schuldig voelen. Ze kunnen je medeleven op deze manier uitbuiten.

Ik ben het eens met de zeer goed gekozen antwoorden die in principe zeggen “dit is niet uw probleem”, maar ik schrijf een antwoord om uw vraag te framen, en de conclusie dat er eigenlijk een probleem is, omdat ik denk dat er een leermogelijkheid aanwezig is in deze kwestie die wordt verdoezeld.

Bedrijven maken beslissingen over wie welk werk doet op basis van een aantal factoren. Vanuit het perspectief van een werknemer kan dit om een aantal redenen verwarrend en zeer eenvoudig verkeerd te interpreteren zijn:

• Soms veranderen ze in de loop van de tijd, of zijn ze inconsistent
• Soms zijn ze ongrijpbaar, of onbewuste “gut feel” factoren
• Maar vaak zijn ze gerelateerd aan factoren waar individuele medewerkers niet aan blootgesteld zijn of waarvan ze niet direct op de hoogte zijn, zoals budgettering, resourcing, of professionele ontwikkelingsplannen voor andere personen

Hierdoor kan het erg moeilijk zijn om werkopdrachten te interpreteren - wat een groot deel van de reden is waarom de “het is niet jouw probleem om op te lossen” antwoorden juist zijn, maar waarschijnlijk een stap verder moeten worden genomen: Dit is relevant voor “busfactor”-problemen, omdat individuele medewerkers vaak niet goed in staat zijn om het grotere geheel te begrijpen van hoe beslissingen worden genomen, en belangrijke factoren kunnen missen. **Iets dat er voor jou als een probleem uitziet, kan perfect in orde zijn voor de leider die er verantwoordelijk voor is.

Als individuele bijdrager klinkt het misschien ideaal om volledige redundantie te hebben op elke rol, volledig getrainde en capabele back-ups voor elk afzonderlijk proces, en een team van mensen die expert zijn in elke vaardigheid in plaats van slechts een enkele persoon. Het laten vastleggen van elk afzonderlijk proces in die mate dat een persoon de documentatie kan ophalen en een probleem kan oplossen zou zeker de stress voor iedereen verminderen!

Echter, vanuit een leiderschapspositie, wanneer je probeert een balans te vinden tussen kosten en winst en risico’s, zou het nemen van die “back up van elke persoon en altijd een plan B hebben voor alles” aanpak waarschijnlijk onbetaalbaar zijn.

Mijn eerste blootstelling aan dit soort besluitvormingsproces kwam vroeg in mijn carrière, maar in een iets andere context: onderhoudsmanagement en de wetenschap van betrouwbaarheid en preventieve onderhoudsplanning. Ik werkte in een software rol voor een adviesbureau dat asset management software opstelde voor grote nutsbedrijven, waaronder verschillende waterzuiveringsinstallaties. Onze software kon regelmatige programma’s voor preventief beheer beheren voor elk apparaat in de faciliteit. Ik merkte echter al snel dat veel van onze klanten ervoor kozen om geen preventief onderhoud uit te voeren aan sommige van de apparatuur in hun installaties. Dat was voor mij een beetje verontrustend: zou je die pomp niet elk jaar opnieuw willen bouwen en zo voorkomen dat hij ooit uitvalt? Is het uiteindelijke doel niet het verminderen of elimineren van storingen en correctief onderhoud, wat er ook gebeurt? En moet er niet een back-up zitten, zodat het proces door kan gaan als er een storing is?

Uiteindelijk heb ik geleerd dat het doel niet is om ten koste van alles redundantie en preventie te realiseren: het doel is om de laagste totale kosten te bereiken. Soms betekent dat dat je een bepaalde pomp moet laten falen. Natuurlijk kregen de pompen die kritisch waren voor de werking zorgvuldig preventief onderhoud en hadden ze online reserveonderdelen, dus storingen waren zeldzaam, en zelfs als er een storing was, zou die prima worden afgehandeld. Maar de pomp voor een minder belangrijk proces had geen back-up en werd niet regelmatig onderhouden. Als het uitviel, kon het enige verstoring veroorzaken, maar het werd aangepakt en het leven ging door. Het was - letterlijk - niet de moeite waard om redundantie te hebben voor die pomp.

Dezelfde aanpak geldt voor procesmanagement voor IT en kenniswerkers. Soms zijn er processen of infrastructuur die vrij kritisch zijn voor de business. Die moeten noodplannen hebben en veel aandacht krijgen. Maar de server die in de hoek zit en die een testbed is voor iets wat niet kritisch is voor de missie? Het is misschien niet belangrijk dat iemand in het bedrijf elke kleine nuance van hoe het moet, begrijpt, veel minder dat er twee mensen zijn die dat wel doen. In principe is de les: alleen maar omdat een bepaalde taak niet volledig gedocumenteerd is, er geen volledige redundantie van het personeel is en de kennis voor 100% wordt gedeeld, betekent dit niet dat er een werkelijk probleem is dat moet worden opgelost. De meeste organisaties zitten vol met processen die niet zo goed onderbouwd zijn, met opzet. Organisaties nemen beslissingen over hoeveel ze bereid zijn te investeren in zaken als cross training, redundantie en kennisoverdracht, en die beslissingen resulteren vaak terecht in _do nothing, laat het mislukken en we komen er wel uit. _

Om dit alles terug te brengen naar uw specifieke situatie:

Aan de ene kant, moet u op uw hoede zijn. Als uw werkgever iets doet wat duidelijk een negatieve invloed heeft op uw carrière, of u in een positie waar je ongelukkig mee bent, moet je die identificeren en samen met je baas proberen op te lossen - of, een andere baan te krijgen als het niet iets is waar de werkgever zich voor zal inzetten. Als je je zorgen maakt over “busfactor” omdat je werkgever de arbeidsrelatie misbruikt door je te verhinderen om vakanties te nemen, of je elke avond om 2 uur ‘s nachts te bellen om de servers te herstarten, dan moet je dat absoluut aankaarten als een zorg.

Maar, als je bezorgdheid gewoon is dat je de enige persoon bent die weet hoe je iets moet doen, of de enige persoon die verantwoordelijk is voor het doen van een specifieke taak, en er zijn geen verdere werkelijke vertakkingen die invloed hebben op je persoonlijk, dat - op zich - misschien niet echt een probleem is. Als u zich zorgen maakt over de mogelijke gevolgen voor uw werkgever als u niet beschikbaar bent om die taak uit te voeren, moet u die zorg aan de orde stellen. Maar uw werkgever kan legitieme redenen hebben om niets te veranderen, als hij op basis van zijn plannen bepaalt dat het risico aanvaardbaar is. In dit geval zal het melden van het probleem helpen om het uit je hoofd te krijgen, en dan kun je verder gaan met je leven in de wetenschap dat het niet jouw probleem is en je hebt de mensen die daadwerkelijk verantwoordelijk zijn gewaarschuwd.

Als je besluit dat je in deze situatie ongelofelijk ongelukkig bent, ongeacht al het bovenstaande (of als je werkgever je misbruikt), en je bent ongelukkig genoeg om te besluiten om een andere baan te zoeken, zorg dan dat je een stap terug doet, identificeer de factoren die leiden tot je ongeluk, en evalueer potentiële toekomstige werkgevers op basis van die factoren. Als je geen enkel punt van mislukking wil zijn in je volgende job, zorg er dan voor dat je potentiële werkgevers onderzoekt om te leren hoe waarschijnlijk dat zal zijn - bijvoorbeeld, werken voor een kleine startup zal waarschijnlijk een slecht idee zijn, want in een kleine startup is zo'n beetje iedereen de hele tijd een enkel punt van mislukking. Maar aan de andere kant van het spectrum zal een grote en gevestigde werkgever in een strak gereguleerd gebied als de gezondheidszorg of de financiële sector waarschijnlijk grondige ontslagen hebben en veel cross-training - dat kan een geweldige omgeving voor u zijn.

Zorg er ook voor dat u tijdens het interview relevante vragen stelt die potentiële werkgevers de kans geven om deze factoren aan u uit te leggen. U kunt vragen stellen over teamgrootte, cross training, werkopdracht of andere gerelateerde factoren, om u te helpen bepalen of die werkgever goed bij u past of niet.

Of, als u zich in een positie bevindt dat u echt de persoon wilt zijn die dit soort dingen voor een bedrijf beslist, overweeg dan om u in leidinggevende functies te begeven, waar u in de bestuurdersstoel kunt zitten om zaken als de busfactor aan te pakken, in plaats van alleen maar het “slachtoffer” te zijn van de keuzes van iemand anders.

Klinkt alsof het tijd is voor een Engineer Appreciation Day!

Heb je betaald verlof waar je binnenkort van kunt profiteren?

Neem een dag of twee vrij, en maak jezelf onbeschikbaar via telefoon / e-mail. Stel degene aan die het meeste weet over uw verantwoordelijkheden als back-up, maar maak hen vooraf duidelijk wat er aan de hand is.

Uw organisatie moet begrijpen hoe de “busfactor” in de praktijk aanvoelt, voordat ze een medewerker kwijtraken.

Dit is een snelle, eenvoudige manier om je hoofd leeg te maken als de zaken zich opstapelen (geestelijke gezondheid is belangrijk!), en het management een waardevolle les te leren over resourcing en documentatie.

Wanneer je weer aan het werk gaat, zorg er dan voor dat je noteert wat niet voltooid is, en doe specifieke suggesties voor hoe je knelpunten in de toekomst kunt voorkomen. Het management zou deze keer wat ontvankelijker moeten zijn, vooral met een nieuw voorbeeld in het achterhoofd.

En als oude gewoontes blijven bestaan en je in de toekomst in dezelfde situatie terechtkomt, geef dan een waarschuwing, en volg deze op met een andere Engineer Appreciation Day.

(Noem het niet werkelijk zo, vertel ze dat je om persoonlijke redenen betaald verlof neemt en laat het daarbij, maar je weet wel welke dag het echt is!)

Ten eerste, je bent niet zo onmisbaar als je denkt dat je bent. Sleutelmensen gaan de hele tijd weg, en het gaat een tijdje langzamer, dan komen de mensen die overblijven erachter. Het leven gaat door.

Er zijn wel een paar dingen die je moet doen. Een daarvan is ervoor zorgen dat je niet de enige bent die toegang heeft om in te loggen op de belangrijkste infrastructuur, zelfs als niemand anders die toegang daadwerkelijk gebruikt. Het andere is ervoor zorgen dat je basisbeoordelingen van je beslissingen krijgt. Mensen hoeven je taken niet op hetzelfde niveau te begrijpen als jij, je hebt gewoon iemand nodig die je beslissingen doorneemt om er zeker van te zijn dat ze redelijk zijn.

Je zou ze kunnen leren wat busfactor betekent, door wat consequenties te laten zien. Neem drie weken vakantie, zeg dat je naar de bergen gaat en dat je je mobiele telefoon niet mee kunt nemen. Voor andere mensen is het verrassend, hoe vaak ze op je moeten vertrouwen. Misschien vindt u uw baas wel ontevreden over uw reis en uw onbeschikbaarheid. Maar dan kun je hem vragen wat er zou gebeuren als je een ongeluk zou krijgen en drie weken in het ziekenhuis zou liggen.

Ik wil niet de man zijn die nooit werk gedaan krijgt omdat iedereen mij altijd vraagt om dingen over te nemen die hun afhankelijkheden zijn. Bijvoorbeeld: de server gaat naar beneden, ik ben de enige die weet hoe ik hem weer omhoog kan krijgen, ik moet alles laten vallen wat ik nog meer doe om de server weer omhoog te krijgen. Ik zou het leuk vinden als de persoon die merkt dat de server down is ook de expertise heeft om het terug op te zetten zonder anderen te storen.

Deze opmerking had in je oorspronkelijke antwoord moeten staan, omdat iedereen die je vertelt dat je het moet negeren, zich niet realiseert dat het ook negatieve gevolgen heeft voor je carrière.

Ik zie twee potentiële paden:

1. 1. Vergroot de moeilijkheidsgraad/vreselijk zijn in één belangrijk onderdeel van je taken. Een vriend van mij is erg goed in het repareren van bugs en is door dat talent aangenomen. Echter, dit bedrijf vergat hem te vertellen dat hij bugs zou repareren op een muf oud systeem met behulp van dingen als Perl en oude versies van Java. Hij wilde natuurlijk geen oude en verouderde technologieën leren, dus zijn oplossing was om er een puinhoop van te maken, maar goed werk te maken van het greenfield project (zijn tijd werd tussen hen verdeeld). Hij werd 100% naar de greenfield verplaatst omdat hij “nutteloos” was op de oudere systemen. Uitstekend werk doen wil niemand en niemand hecht er echt waarde aan om het te doen. Dit heeft het voordeel dat het hun de hand reikt, maar heeft als gevolg dat je minder capabel lijkt. Of dat van belang is, hangt af van de vraag of dit een bedrijf is waar je op lange termijn (lifer) aan vasthoudt. De extra tijd die je wint door incompetentie kun je gebruiken om jezelf te verbeteren. Dus misschien ben je nu wel vreselijk slecht in serverconfiguratie, waardoor je gedwongen wordt om iemand te vinden met die skillset. Je kunt de last met hen delen.

2. Als je een lifer bent, schrijf dan de documentatie en doe toch informele coaching. Als iemand een probleem heeft, stuur je hem of haar eerst naar de documentatie en als dat niet voldoende is, zorg dan dat hij of zij in de buurt blijft terwijl je het probleem oplost. Als je van plan bent om op lange termijn bij dit bedrijf te blijven, doe het dan gewoon. U zult ofwel slagen in uw doel, ofwel beseffen dat u binnenkort toch zal verhuizen uit frustratie en dat er dus geen reden is om discretionaire inspanningen te leveren die niet gewaardeerd of erkend worden. Als de baas het daarna nog steeds niet wil, worden de andere antwoorden juist in die zin dat het niet jouw probleem is.

Ik ben het niet eens met andere antwoorden dit is goed voor je.

Een goed argument is dat er behoefte is aan rust en vakantietijd.

Ik stond ooit in jouw schoenen, en hoewel ik de infra-structuur die ik “geërfd” heb niet heb gestabiliseerd, betekende het vakantie doorbrengen van een medium van 2h-4h in de telefoon het geven van steun aan anderen, omdat niemand anders het kon doen. (kort verhaal, er is een langer verhaal voor)

Ook, met een team van minstens twee, in middelen in crisissituaties, is er een extra paar ogen om fouten te helpen voorkomen, of zelfs iemand om je werk op te pakken terwijl je rust. Eenmaal in een vergelijkbare situatie en onder een hardnekkige cyberaanval registreerde ik gemakkelijk 100 uur extra tijd…in een enkele maand.

Ook het hebben van hulp, betekent dat dingen beter gepland en gedocumenteerd kunnen worden, en dat er meer ruimte is om proactief werk en nieuwe projecten te doen.

Dus, het is gewoon niet de busfactor die hier op het spel staat. Je kunt veel meer solide argumenten hebben.

Omdat de redenen waarom je CEO dit doet, vermoed ik dat het een kwestie is van het beheersen van de zaken. Ze hebben het liever in de handen van iemand die ze vertrouwen, en hebben niet te veel nieuwsgierige blikken op gevoelige zaken. Dat kan echter om verschillende redenen gemakkelijk averechts werken.

Het is duidelijk dat ze ofwel het concept “busfactor” niet krijgen, ofwel doen alsof ze het niet begrijpen. Ik zou stoppen met het zoeken naar manieren om dit uit te leggen als ze het niet krijgen na de eerste keer dat je het uitlegt.

Veel beter om je zorgen te framen als het nodig is een mechanisme voor tijdelijke ondersteuning voor belangrijke verantwoordelijkheden voorafgaand aan het nemen van een vakantie of wanneer je andere taken op je neemt.

Meestal, wanneer het management raar doet of niet reageert op belangrijke zaken die je probeert aan te kaarten, is het omdat ze je niet iets vertellen of omdat ze het er categorisch niet mee eens zijn. Als je niet het soort werkplek hebt waar je openhartig over dingen kunt praten over de hiërarchie heen, kun je alleen maar raden wat hun redenering is. Het kan van alles zijn, variërend van “als @Ertai87 vertrekt, huren we gewoon een consultant in om het over te nemen” of “@Ertai87’s jobfuncties zijn niet kritisch” of “@Ertai87 zei iets over ‘een bus’, hij gaat weg, laten we stiekem op zoek gaan naar zijn vervanger”.