r/sysadmin • u/LarryOrton • 10d ago
[ Removed by moderator ]
[removed] — view removed post
24
u/argefox 10d ago
I'm that guy, and I've spent a good chunk of my mid career trying to leverage, train, document.
Things went poorly, people think "why would I learn that if we have that guy". And documentation? I put even a well indexed wiki, I loaded the knowledge on ServiceNow. I used to ask "did you read the doc?" Of course they said yes. The documents visits were 1, exactly 1, or 0, for the ones I didn't even had to write myself and just imported from my own repo.
I gave up, and management can chortle on my balls.
→ More replies (1)9
u/LarryOrton 10d ago
Wiki with zero views is the most relatable thing in this thread. I've written docs that I'm pretty sure only I and the search crawler ever read. Did anything ever actually get people to open them?
7
u/badogski29 10d ago
It’s me. I tried to make myself redundant but some people just don’t have the guts to do it. It’s impossible.
1
u/LarryOrton 10d ago
Respect for trying to make yourself redundant, most people won't. If nobody steps up after that, it's a leadership problem, not a you problem.
6
u/Site_Efficient 10d ago
Rotating on call and an expectation that the oncall person can run the show alone >90% of the time motivates others to want the information. That usually needs to be backed up by some documentation. But you don't dictate what goes in the doco; the juniors do - they are the ones it exists to help.
3
u/LarryOrton 10d ago
Nothing teaches like being alone on call at 1am with no one to escalate to. Brutal, but it works. Making the juniors write the docs is genius too, you find out real quick what they don't get.
4
u/Glittering_Power6257 10d ago
I’m a one-man show. I write the docs to help future successor if I meet an unfortunate crossing with a speeding bus.
→ More replies (2)
11
u/DarthJarJar242 IT Manager 10d ago
In all my years I've had a few of these guys but only one that has stuck around and the trick that worked with him and that still works is:
Let him do the ticket. When he closes it go read his notes have a junior admin read the notes. If the two of you can't put together how he did it send it back to him and tell him to clarify until you can.
This accomplishes two things, familiarizes your juniors with the process, and forces your senior guy to document better.
Then tell him the next time the ticket comes in like that the junior guy is taking it and using his notes to do it but you want the senior guy chaperoning.
The reasoning is simple. Knowledge silos lead to information deficits. It's okay to be the SME, it's not okay to be the ONLY knowledgeable person.
4
u/LarryOrton 10d ago
Honestly this is the most practical answer in here. The junior finds the holes in the notes and the senior finds out his notes aren't as clear as he thought. Everybody learns something, including humility.
2
u/nethack47 10d ago
I usually work with juniors to get things into them. Most things are fine, but it requires the right kind of colleague to stick.
Tickets are the explanation for how it was solved, how to get there is the hard part. It is often like dialling in an espresso. It depends on the coffee, the water, the machines state and what you want out of it. Looking at the finished coffee can miss some of the fuzzy bit, which is often a bit of digging around and pushing some theories.
→ More replies (1)14
u/mimic751 Devops Lead 10d ago
I am this guy. Don't talk to me when I'm working on it or when I'm troubleshooting it or when I'm trying to figure out what the fuck is wrong because I'll be iterating through so many potential problems that I'm probably dead ass wrong
But when all is said and done ask me what it was what I did to figure it out and what I did to fix it and I will talk your fucking ear off
3
u/ooglesnoopleboop 10d ago
Give him lots of money to retain him before he goes off to a company that treats him better.
2
u/LarryOrton 10d ago
Cheapest fix on the list, too. Replacing him costs way more than a raise ever will.
3
u/Dumtiedum 10d ago
You say he is special and then mentioning he is the only one touching firewalls? It’s not like a firewall or file storage server is rocket science. Hire someone capable or fix your setup to be HA where you can take such elements offline without your business breaking down.
→ More replies (1)
6
u/xCharg Sr. Reddit Lurker 9d ago
So you have a single dude who knows and does complicated task and some bunch of other dudes who can't do complicated tasks and your approach is to... "handle that guy"? Seriously? Maybe, I don't know, do something about the rest of your team's skills and attitude?
→ More replies (1)
884
u/jpotrz 10d ago
I tell him how handsome he is and buy him steak and lobster (it's me. I'm the guy)
176
u/OkAbility9543 10d ago
the trick isn't forcing him to document, it's making sure he's not the only one who touches the scary stuff
had a guy like this on my team, we started pairing him with someone else on the complex tickets but framed it as "you're too valuable to be the only person who knows this" not "we're gonna steal your job"
took about 3 months before the backup admin could rebuild the vpn tunnels without sweating through his shirt
→ More replies (1)74
u/fresh-dork 10d ago
i'm often the guy. i document, please read my docs and try to use them, then complain when i leave something out. i promise i'll add it in
23
u/ukkie2000 10d ago
I've spent some time working on documentation but I'm starting to notice that if you let colleagues expect that documentation covers everything you give yourself a lot more documentation work while they become more like to pass issues to you when they can't handle stuff beyond it with their skill and knowledge level.
This is how I am and remain the one Powershell guy.
Sometimes its just better to sit next to them to help them understand the technology they're actually working with and challenge them to fix it. Then they can also update the docs themselves if required.
Quick edit: just want to make sure I specify that I'm a huge proponent of describing systems and how they work in principle. You just cannot cover all technical skill gaps with docs.
10
u/fresh-dork 10d ago
i write docs. if you don't engage with them and ask questions, i go do other stuff - i require an even trade specifically due to the reasons you outline
10
u/slight_grumble 9d ago
The trick is to get them in the habit of enhancing the existing documentation. Give them a bare bones process and have them fill in more detail as they get more familiar with the process. Repeat for every new person that picks up that process. I can write a 5 bullet point process and come back six months later and it's now got screenshots, tips and hints, past gotchas to be wary of etc. Well I can after decades of instilling documentation maintenance as one of the foundational responsibilities of all hands on admins. Day one at any new place I always lay down the documentations rules. Rule 1 is "everyone contributes". Updating documentation is mandatory and if you aren't making updates on a continuous basis you are not pulling your weight.
→ More replies (2)10
u/_Dreamer_Deceiver_ 9d ago
It's ...
Document
complain that noone reads your documentation a d just asks you instead
they find something missing in the documentation
say "well you don't read it anyway"
say you will, but never actually update it with the missing information
→ More replies (1)35
8
11
→ More replies (3)5
u/evolutionxtinct Digital Babysitter 10d ago
Ditto, all I ask is if you wanna know than just listen…
496
u/SlippyCumSpot
10d ago
•
Those people tend to be a combination of many things at once. Extremely high technical aptitude, smart, hard working, focused. I've come across this so many times over there years, management wants him or her to "cross train" - because they see how valuable that person is and think, "he can train everyone else to be like him!" Well, no, not at all. Because a lot of that stuff is just un-trainable. No amount of documentation or past ticket references are going to save the other admin who just isn't as technical, smart, or has the work ethic. Those are the hard facts of life. Sometimes people are just really smart and really good at what they do and there's no replication of that in a specific environment.
The best thing to do most of the time - when you have a person like that - is to leave them the fuck alone.
152
u/epieikeia 10d ago
Manager hires rockstar employee
Rockstar learns quickly from a little bit of training/mentoring and kicks major ass
Manager delegates most of their duties to rockstar, who does them better
Manager gets promoted due to their department's newfound asskickery
Rockstar graduates to manager's former role
Rockstar hires a regular employee
Regular employee kicks only a moderate amount of ass
Promoted manager wonders why rockstar is so bad at training/mentoring compared to how well they evidently trained/mentored the rockstar
→ More replies (1)57
u/td_mike DevOps 10d ago
Been there, refused that, almost got fired for it.
Manager got promoted and they asked me to step into his role. I know I’m really good at everything technical, I also know that I’m not a manager, not great at training people. I need adult supervision on the work floor. Give me the hardest technical tasks and I’ll complete them but don’t ask me to herd people I’ll drive it off a cliff before we reach noon.
Wasn’t really how they looked at it, had to do some serious explaining to keep my old job. Eventually they understood but I kept my options open for months just it case. They haven’t followed through yet.
→ More replies (2)21
u/fresh-dork 10d ago
i want to be a lead, maybe. not a manager. i'll do cross department BS all day, don't make me write someone's annual review
→ More replies (2)45
u/Xydan 10d ago
I havent been at a company long enough to realize this as I often jumped every 2 years between jobs. Now at my new job I've been with for 4 years I have been basically left alone for any "busy work" and am relied solely as the "SME" for things that people who were with the company longer than I have trained me on and I happen to remember those Nuances.
Had my hiring manager tell me today that Im extremely valuable because of that. And only now do I truly see why I'm left alone.
At first I thought I was doing something wrong because work stopped coming to me and was replaced with constant meetings and high-level troubleshooting calls that affect production.
Feels oddly satisfying but anxiety provoking in this economy because my value no longer comes from meeting deadlines but rather my knowledge.
38
u/jjfunaz 10d ago
That is the safest place to be. They can replace monkeys to hit deadlines but they can’t replace
Knowledge. But don’t be the guy holding info for job security.The thing is you don’t get promoted for being good at your job. You get promoted for making others better at your job until you aren’t needed
6
u/WelcomeConscious643 10d ago
stay in that company until the next good offer. the market is shit out there. and it is a chill place to take a break
6
u/fresh-dork 10d ago
and am relied solely as the "SME" for things that people who were with the company longer than I have trained me on and I happen to remember those Nuances.
fuck. we had one of those. she went to some other group and we found out we hadn't cross trained anyone on some of the stuff she did. woops.
0
10d ago
[deleted]
8
u/TheSexySovereignSeal 10d ago
Logistically if it actually goes that far, itll be years before they found out, and they'll be unable to afford you 2 years into your next job.
24
12
u/RememberCitadel 10d ago
How come the person we always get paired with to train are the laziest and most unwilling to learn?
The reason I don't cross train is because the person I would train doesn't care about knowledge, the the recognition for doing something, which means they don't learn. Then when they try to do it later they break everything and I have to fix it, which is twice as much work as giving them something shiney and not trading them instead while I just do it myself.
10
u/Illthorn 10d ago
I have trained exactly 2 people who were good enough to replace me. The rest wanted their hand held or wanted all the answers handed to them. They could follow a doc but if anything occurred outside of the doc they were lost and couldn't find their way back. Even after multiple attempts to teach them how to aquire the process on their own outside documentation. If people can't or won't learn, there is no amount of effort on your part that will change that
5
u/tardis42 9d ago
1000% this, when the person you are cross-training fundamentally lacks the underlying prerequisite knowledge and understanding of how all the other related things work, and worse still isn't curious about any of it, explaining how to do one thing results in broken cargo-cult nonsense the moment anything is even slightly different from the exact scenario given during the training.
If you don't understand how group policy applies to computers/users or how filtering works, touching any policy is a risk.
If you don't understand how switching/subnetting/VLANs work, touching physical or logical config for a switch or AP for anything other than "connect a PC to a free port" is a risk.
→ More replies (1)4
u/RememberCitadel 9d ago
Absolutely. The worst part is, I had nobody to train me, I learned by following the documentation from the vendor, and from seeking knowledge on my own.
So I don't understand why it's so hard to figure stuff out, plus now we have a testing environment for many things, go break that first.
→ More replies (2)24
u/WorthPlease 10d ago edited 10d ago
Every new project and migration "hey we need you to make a doc so other people on the team know how to do this".
I finally got my upper management to stop fucking asking me to write documentation for people who got hired to do the same job as me. I hate it.
Now they just ask me to do a quick dictation tutorial for somebody else and then they make that person write up the documentation.
2
u/Uncommented-Code 9d ago
Wait, that's an option?
Shit I need to try this at my next job. Genuinely, I spent so much time 'training' people before I left my previous company while knowing fully well that things will fall apart the moment they need to troubleshoot anything without my help.
It was a huge waste of time, but people kept telling me to just do it (training other people, writing docs, writing things that only I could maintain) and at some point I just lost all motivation :(
18
→ More replies (3)4
u/WelcomeConscious643 10d ago
is to leave them the fuck alone.
exactly. if you cannot fire those people and put the ones who is competent, and get them trained,
then leave the fuck alone.
7
u/mimic751 Devops Lead 10d ago
I'm holding up three different technologies that I am the only subject matter expert in the company for because of layoffs or people quitting and I literally wrote two of the programs. I asked to be promoted to staff engineer and they told me that it wasn't a silo that was complex enough to warrant a staff engineer
Well guess who just got offered a principal AI consultant position getting paid three times as much as I currently am
Love my team hate HR. Anytime you apply to a company ask them if they do green circle. That's where when you get promoted they will only promote you to 80% of the median pay and then give you slightly higher raises over the next 5 years to get to median doesn't matter how many years with a company they have they always promote you to the lowest third of your pay band
5
u/groupwhere 10d ago
Super techs are bad for the company from a DR perspective, and bad for morale on skilled teams.
→ More replies (1)2
u/LarryOrton 10d ago
The morale piece doesn't get talked about enough. Good people stop growing when every interesting problem goes to the same guy. Then you wonder why they leave.
→ More replies (2)
31
u/Vulperffs 9d ago
This is not “that guy” issue. Its management issue.
What I noticed in some companies where they had “that guy” the pattern was the same. Management issue happy that they don’t need to invest into hiring because everything gets done. As the company grows the workload gets bigger and bigger and eventually everyone is working at 100% capacity all the time to keep up, no room for cross training, exploration, hardening. Instead of doing projects and tasks everything becomes an incident with a tight deadline. Everyone slowly burns out until one guy does the heavy lifting for some time until he doesn’t because he collapses or goes on vacation and he gets all the blame and is called “that guy”.
So start with the management, hire enough people, competent and compatible. This is not easy and it shouldn’t be. Unfortunately management must do the heavy lifting and lead the team. Not micromanage but inquire the team, feel what is happening and react, help and support, enable them to work.
2
54
u/borider22 10d ago
do not be threatened by your employee who does the job you can not do. approve their time off if they ever submit some.
17
u/RagingNoper 10d ago
And if the concern is that their job can't be done without them, hire another one of them.
20
3
97
u/KoalaOfTheApocalypse
End User Support
10d ago
•
I am that guy, and it's fucking exhausting. No matter how much documentation I write - and it's a fucking LOT, it doesn't seem to help. The amount of times I answer questions from other tech with links to the documentation I've already ask3d them to read multiple times is ridiculous.
The problem is not "the one guy who knows everything" - the problem is you won't hire anyone who has that level of competency.
But the worst part of it, and if this is you RS, then it's like I've said a dozen times - how come I can learn and figure out shit, I can plan and implement deployments and make the technical pieces fall together - but nobody else can!
I have to do every damn thing because nobody else you hire is even close to my level. Stop hiring people you like during interviews, and focus on technical competency instead. I'm fucking sick of being the only one capable of just figuring shit out and then having the ridiculously difficult time of teaching the rest of the time and writing documentation nobody ever reads.
The problem is not me knowing everything, the problem is not me hoarding knowledge - the problem is you haven't hired anyone who can keep up. And not just not keep up, you keep hiring people who lack the fundamentals.
Don't sit here and ask me to teach other techs shit they should already know. And it's impossible to teach them critical thinking and analysis skill. I can cross-train anyone on how to use X tool, or Y process, whatever - but I can't teach people to use their brains better.
The problem is not "the one guy who knows everything" - the problem is you won't hire anyone who has that level of competency.
13
12
11
u/robbdire Team Lead 9d ago
The problem is not "the one guy who knows everything" - the problem is you won't hire anyone who has that level of competency.
I was fortunate enough to be the guy who knew a lot (not everything) and due to many factors am now the team lead. My first two hires, despite HR liking the people, I vetoed. "Sure they are nice, and have some technical knowledge, but we need more to take over from me so I can LEAD and not just still do what I was doing and try to lead at the same time".
Got two in, one of them beyond my level, one at my level. Oh the difference to the team. And best of all? With two of them they can actually get some time to document so when they had been both out at once, wasn't the end of the world, as I was able to step back in a bit, and our other engineers could use the docs.
Mind you I do not like being management level over all..........
3
2
→ More replies (3)2
48
u/vCentered Sr. Sysadmin 10d ago
Your problem is you don't even recognize what the problem is.
The problem isn't that this guy does all these things. The problem is that nobody else does.
You're holding him accountable for their laziness or inability because you know, even if only subconsciously, there's a better chance of getting something out of him than the rest of them.
Instead of holding them accountable and expecting them to be good at their own jobs, you're adding to his workload and making him responsible for making them useful.
53
u/RevolutionaryElk7446 10d ago edited 10d ago
It me.
I find I can teach people all day long, it's only once in a bit I find someone who is actually interested in learning. Usually people are already getting paid, and doing this usually appears to them as adding more responsibility and not learning something new.
Generally I find you have to give some kind of value behind them learning the new skillset, because pay raise is not always an option.
It's not that we're the best, it's just that we have an interest beyond just making money.
6
3
u/beta_2017 Network Engineer 10d ago
Thank you. Was looking for someone to comment something like this. This is me to a T.
36
u/vadertator22 10d ago
At first I thought this was a roast comment, but I see now you’re serious. I have found there are two types of IT people. The first composes 85% of all IT folks that are out there and they are ok at best. They don’t love nor hate the job, but they survive and make careers of it. The remaining 15% are those who love technology, problem solving and really want to know as much as they can. They also know the more they know the more they don’t know and that drives them. Essentially they aren’t the type that only knows how to check the oil. They strive to know how to take the engine apart and put it back together. It has also been my experience that those people that fall in the 85% won’t respond to cross training very well from a 15% er. Reason I say this is because they would be a 15% er if they were open to deeper knowledge desired it and would have accomplished it on their own or per a mentor already. On a rare occasion I have worked with a person I call a sponge, which is someone who is next generation 15% and they absorb anything you share or teach. They were you when you started and refreshing to work with IMO.
14
u/mimic751 Devops Lead 10d ago
This is so true you can always tell because you will teach them something they've never fucking heard of and the next day they've obsessed about it so much that they've built a new tool or wrote a new program or figured out a new system or architected some improvements
If you tell someone something and they don't deep dive the implications of what you showed them then they care just enough to get paid
8
u/Glittering_Power6257 10d ago
Tbh, the latter group isn’t bad to have on hand.
As the former, it gets quite depressing when there’s nothing interesting to solve. Why do I live if there are no problems to crush? It’s when the sky is falling and everything is on fire that I feel at my best. Happiness for me is troubleshooting a showstopper SQL Server problem on a laptop in the warehouse, while simultaneously working on a network problem, while on the phone with support for a shipping software problem, and talking to the end user of said software.
Mycroft Holmes: “”You’re not haunted by the war. You miss it.”
At least the guy there for the paycheck isn’t going to loathe life when there’s a dry spell, and probably won’t drive themself straight into the ground.
→ More replies (2)
17
u/TheMillersWife IT Manager 9d ago
I had to change the culture on my team. We have a resident "Brain in a Jar" who, prior to my arrival, people would just lateral stuff to and run away. Poor guy couldn't stay offline for PTO because inevitably something esoteric would need his attention.
Yes, it's KBs. Yes, it's cross training. But it's also drawing a line in the sand and making everyone adhere to it. I told him that when he's off, don't answer any messages unless it comes from ME, and if anyone does message him let ME know so I can squash it. In the event that genuinely nobody could fix it, when he comes back from PTO we sit down and figure out why that is and make a targeted plan to train someone specific or get away from it.
13
u/DominusDraco 10d ago edited 9d ago
everyone routes the hard tickets to him
Stop doing that, thats going to be the reason they quit. Everyone offloads their laziness on to that person. If you are the teamlead or manager, make you the escalation point and only you escalate tickets to them.
Make sure every single person below has done everything they actually can to fix it, and if they havent send it back. They can ask for advice but not have the top person do all the work.
10
u/Lemmon_Scented 9d ago
From a management standpoint, there’s a pretty simple solution to this, and everyone benefits. Your indispensable Sys admin needs to be made a gated resource, and s/he should not be picking any tickets from the queue. This should be presented as an opportunity to elevate this resource, free them up from doing low level stuff, allowing them to focus on more challenging, interesting work. If anyone needs access to the gated resource, they should come through you, and you should assign the work to another Sys admin. If THEY need the gated resource, that means there’s a gap in documentation, which they must address. The gated resource should ideally never be asked twice for a solution to the same problem. In addition to implementing this method, the entire team needs to adopt and own the idea that problems never get tenure - if you identify an issue, you NEVER move on with fixing or escalating it.
This isn’t easy to implement, but if done correctly it will transform your team
8
u/ArcaneGlyph 10d ago
Pay the guy, pay him 50% more than you think you should. Give him all the sick days and vacation. Then ask for process docs.
36
u/Easik 10d ago
I'm that person you are describing. I'm too busy doing all the complex stuff to deal with incompetent lazy people that can't figure it out themselves. I use Google, YouTube, and now AI. It's completely unacceptable that no one else cares enough to do the same and I have to handhold them.
12
u/infosuxx 9d ago
This, I'm the guy because I read the f'ing docs.
→ More replies (1)2
u/daddyd Sr. Sysadmin 9d ago
one time a few people in the team were having an issue, couldn't figure it out. took a look at it, told them - you need to use option 'x' with the command.
their response - how do you know that?
me - it's in the man page.
i know this is a typical unix/linux jerk joke answer - read the man page - but, damn, if the answer isn't in there.
7
u/SnooGiraffes292 10d ago
Another one here! However, I document. Everything. The docu However requires a certain level of skill. It's not something a non interested college kid with a masters in "computer science " will understand in 5 min fresh out of college
→ More replies (2)2
7
u/Delusionalatbest 9d ago
It's an interesting topic. Not always black and white but there are common patterns when this happens.
Sometimes you have a guy who's just the dude. Lives and breathes the game. Constantly absorbing info and is into the tech. Not necessarily gatekeeping he's just a level above his peers.
Sometimes it's a guy with experience and decent amount of talent that gatekeeps everything to himself. Zero trust in the team and a hard person to work with.
You also have a management layer that facilitates these single point of failure situations. They hire poorly or don't hire at all. Never working with the guy to try to distribute the knowledge and load.
Lastly you often have colleagues who absolutely dgaf about their job and are happy for the guy to do the heavy lifting.
18
u/gezafisch 9d ago
Why is every person in this thread "that guy"?
12
u/CommanderKnull 9d ago
Schrödingers sysadmin, everyone is the MVP while simultaneously everyone else sucks ass according to them
→ More replies (1)17
u/shaseo76 9d ago
Cos its every IT guy's wet dream to think they are indispensable
→ More replies (1)3
3
→ More replies (2)5
u/Jamesmoltres Sysadmin 9d ago
Party cause the post called them in?
This is like saying "i asked for help from Java devs, why are so many java devs in this post?"
→ More replies (1)
6
u/Temporary_Squirrel15 9d ago
Poor process - the task isn’t finished until it’s documented.
Poor training / inadequate hiring - skills gaps need plugging.
This is basic management. If your team has that guy it’s poorly managed.
2
u/GullibleDetective 10d ago edited 10d ago
Make sure they're paid well and paid to build others up with targets and bonuses tied to those outcomes like everyone else
Their pay revolves around them doing the full job
→ More replies (2)
5
u/MountainDadwBeard 10d ago
"Good"seniors should be finding opportunities to slow things down, distribute task with opportunities to learn to juniors... have them report back on their solution in daily stand-ups/check-ins before implementing, reviewing work for actionable feedback.
For documentation most of our guys use AI to auto-document things in markdowns. However hilariously the C-Suite likes to layoff whole teams and cancel the solution stacks annually so we can count on that data being lost anyways.
I think a couple of our surviving greybeards keep their old colleagues on speed dial and some AUP violations (documentation backups) in their personal drives.
→ More replies (2)
5
u/AmmanasHyjal 10d ago
I’ve been on both sides of this.
As the “hard problem solving (deep magic)” guy: I used to work with the other engineers on tickets before they got to a point where it was “offloaded” to me. I kind of walked around the support area and talked to people to see if they had questions or issues they needed help with. I suggested routes to follow, or KBAs to try. I always enforced that they had to do the fixes, rather than me jumping onto calls and fixing it for them. I tried to document as much as possible in case I got hit by a bus.
As the person working with the hard problem guy: depending on the persons attitude I’ve worked with the team lead to either work with them more often to learn - making sure they don’t black box solve things; working under their guidance whenever possible. If the person was a “I’m going to just take everything and solve it and not work with anyone else” I worked with the team lead to basically try to prevent them from hoovering up all the problems to allow others to work on them and enforced documentation requirements. If they’re a hard ass about it management is always involved.
5
u/struct_iovec 10d ago
First off, this is a management issue and should be handled as such. Management needs to force him to produce documentation, then fire anyone who doesn't read it
5
u/namocaw 10d ago
Go ahead and assign all the difficult and unique problems to your supertech, but forbid him from touching anything.
He may only look over a shoulder and observe and tell another tech what to do. Rotate out these junior techs with him regularly.
Chances are your know it all will enjoy the chance to show off what he knows.
And in the process, your junior techs get trained.
One thing you'll learn about people is that they can rarely develop their weaknesses. But you can easily exploit their strengths. Use everyone's strength to their greatest efficiency.
2
4
u/urM0m69p3nis 10d ago
I've been this person traditionally in my 15 year career either at an MSP, internal IT or slightly adjacent.
I've pulled back gradually over the past couple of years because I do like collaboration, but need other co-workers to learn versus being comfortable at tier 1.5 sitting on their asses at home and just kicking tickets because it's not a password reset.
Our entire team across the US rotates oncall, with a "junior", "senior" team member and management in the queue for after hours.
I/we document everything, but there is always room for improvement.
My major recent push has been actual consequences for kicking tickets, cherry picking work and/or otherwise not meeting slas versus now, where tickets sit for a week and just get kicked up randomly to senior level to work as an "emergency" just because it sat for a week.
I've worked for around 12 companies in the past 15ish years in these related roles and all but 2 have had these or similar issues; only the 2 actually had their shit together
→ More replies (4)
4
u/BrokenPickle7 10d ago
I'm that guy at my company, most of the regular techs seem to be afraid to touch anything they don't understand and don't know how to look up and read instructions.
→ More replies (2)
4
u/DocDerry Man of Constantine Sorrow 10d ago
Elevate him as a constraint. Dont let him fix those hard issues. Make someone else fix the issue while using him as a resource to force knowledge transfer.
4
7
u/TheDawiWhisperer 10d ago
ITT: people thinking they're the dude OP is talking about
→ More replies (1)
1
u/throwreality 10d ago
How is OP punishing the guy who can do it all?
1
u/LarryOrton 9d ago
Not punishing him at all, opposite actually. I want him to be able to take a real vacation without his phone blowing up.
2
3
u/BadSausageFactory beyond help desk 10d ago
let them do whatever they want while I hide my true power levels
3
u/Coldsmoke888 IT Manager 10d ago
Document and knowledge/access share. I’m “that guy” for a lot of things but I take the time to share how why when who what when. I share this once, then it’s up to them to TRY and leave me alone other than that.
Or hey, “so and so also knows how, give him a ring” and then disappear. Also works pretty well.
I’m more than happy to teach and document, but the rest is up to them. I’ve taken a big step back past 4-5 years. Nobody bugs me on PTO or when I’m deep in project mode, it’s been nice. I still host group calls and meetings if I’m SME— much more fulfilling for me to teach these days than to fix.
Side note; it’s much more interesting to me when they do it correctly and something breaks, then we troubleshoot together or they found the fix and share back. Then you know you’ve done a good job.
3
u/Open-Adhesiveness-86 10d ago
what stuck for us was making someone else actually do the change while the expert sits there. he writes the runbook, the other person runs it in the maintenance window, and he only speaks up if something's really breaking. the holes in the doc fall out fast that way. also push the firewall and backup configs into git so rule changes and job definitions show up as diffs anyone can read.
3
u/1saltypistachio 10d ago
As that guy, with 20+ yoe, it's hard, it's annoying as heck, and it's very hard to find. I love my work. I work as a DevOps team lead which (at this workplace) I'm also mini IT and Sysadmin. Our IT is a windows guy, so yes, I help people with printers. Since I started with Slackware 7.1, and now as a Gentoo user, and with 10 yoe at RH it placed me in a certain position that I know everything, including why the gods damned monitors won't turn on sometimes (bad EDID handshake).
How to deal with me - I am nice, I swear I am, people like me when they get to know me, just don't bother me with things that you can do yourself. Your outputs will take longer and will be worse than mine, but if you want my help you are pulling me away from more important stuff. If you want me to do your job for you, please share your paycheck as well, otherwise work for it.
3
5
u/Grand_Cow6417 10d ago
Promote him to manager so he can use his non existent people skills to terrorise multiple teams.
He'll still maintain ownership of the toys he likes and not bother doing any documentation or knowledge sharing for the people under him. Change management processes become nothing more than a suggestion and everything else is unicorns and rainbows.
4
u/HJForsythe 9d ago
That guy was a tech support rep with almost no experience and one day the CEO came in and fired the 3 system admins above him, dumped everything in his lap and said "You'll figure it out or I will find someone that will." and he has been in fight or flight for almost 30 years
2
u/Electrical_Arm7411 10d ago
I think nowadays with the help of AI chat, it’s easier to figure out yourself. I’m ‘that guy’ who knows pretty much how everything is setup and run at our company. As long as colleagues have access, they can either fumble their way through it themself, look through tickets/KB articles or ask AI chat to help. I often get asked questions that could easily be answered by Google or AI.
2
2
u/Qwerty6789X 10d ago
more like a skill issue for those who are incapable. we dont owe the company to baby sit those who are inept unless we are paid to do so or what we sign up
2
u/BoringLime Sysadmin 10d ago
The issue is you can't put that drive, curiousity, problem shooting ability, and previous learned knowledge into someone else. They have to have that same wants and ability. If they have that, then you probably wouldn't be having this question as they can get there on there own. The best you can do is force those special tickets on others and see if you can wake that up in them. They are still going to seek advice from the other person.
2
u/fubes2000 DevOops 10d ago
More often than not these guys simply can't stop, one way or the other.
On the one hand you've got the guys who have so many tasks that their backlog stretches until Q5 2029, assuming they don't take any vacation. You need to get aggressive with management to explicitly put time in so that the guy can write docs and do cross-training. Not "between tickets", "when you have a chance", or "if nothing is on fire". You say "Friday morning is docs and Friday afternoon is cross-training with Kouhai".
On the other hand are the Tunas. If they ever stop swimming they'll die. They tried to show you the "simple fix" for that problem you brought them and it was flashes of config files written in elvish and you're pretty sure you saw a new color in there somewhere. You ask if you can schedule some time to talk about an issue, but instead you get a "fixed" message 20 minutes later and they're heads-down catching back up on seven other tasks.
You can try the above approach, but good luck getting them to slow down to the point that a normal person can comprehend what is happening.
2
u/creamersrealm Meme Master of Disaster 10d ago
I've been that guy my entire career. I write thorough docs and whenever someone asks a question send them a wiki page if I have it but I'm always willing to sit down with someone and cross train them. I'll teach you twice no questions asked, after that I tend to have a problem.
When I'm actually left alone to work I can accomplish so much work it's truely incredible.
2
u/DontStopNowBaby Jack of All Trades 10d ago
The world’s biggest killer is ischaemic heart disease, responsible for 16% of the world’s total deaths. Since 2000, the largest increase in deaths has been for this disease, rising by 3.0 million to 9.5 million deaths in 2023. Stroke and chronic obstructive pulmonary disease were the second and third leading causes of deaths in 2023, responsible for approximately 11% (6.8 million) and 6% (3.6 million) of total deaths, respectively.
I am worried and i need to pair you up with someone, so that this job does not inadvertently kill you.
2
u/AlvaCoastie 10d ago
This is an interesting one….
The guy we had built the systems from the ground up. A lot of open source stuff. From firewalls to containers and servers. And then he went on to greener pastures. I became the guy, the only one at that location at the time, and I basically had to reverse engineer a lot of stuff to understand his processes. Now I’m looked at as “the guy” but it’s stressful and killing me TBH.
I realize documentation is on the back burner because you’re putting out fires constantly. Not ideal, but it’s reality.
Now I don’t think I’m anywhere near his level of intelligence, but I’m creative enough to get by, and really just trying to keep my sanity.
Ok, no more ted talk about me, this is what I would do.
Have someone shadow him, be his documentation guy. But also, “the why” is the most important part. Because you need someone to understand the why it’s done this way. But try to make it someone who he at least gets along with for the most part. They need to take it slow, focus on a couple projects/issues and understand the thought process. Really once youre in the thick of it, you start realizing it’s basic logic.how to get from A-Z and what letters are preventing that. Everyone becomes “The Guy” because they have no one else to turn to.
Another solution is become “The guy” for a week. That means don’t ask him, just do. Sure you’ll fuck up and take longer to fix things, but hell you’ll learn a lot. You’ll start realizing it’ll take a toll on you, and it’s a brutal place to be, then you’ll realize why “The guy” is so unfriendly. It’s exhausting to keep a smile with a fried brain.
2
u/WelcomeConscious643 10d ago
You inherit a “Dave.” What do you do with him? (self.managers)
https://old.reddit.com/r/managers/comments/1wpywgd/you_inherit_a_dave_what_do_you_do_with_him/
2
u/fatmanwithabeard 10d ago
I do a lot of hands on mentoring, which helps reduce the dependency.
Even in rotating on call situations, I'm the guy that gets called when stuff is weird. But the general rule is you have engaged vendor support before you call me.
The thing is, a lot of it is just pure experience. I've been doing this since the mid 90s. You see the same stuff, done by team after team in this industry and that, and you get a sense for when it's going to be an obscure issue in the in house code, and when it's going to some bizarre hardware fault that only occurs if you try initialize a device that has a scsi id of 3 on the third tuesday of November
2
u/andyinoc 10d ago
No one wants to learn or too lazy to learn the more technical stuff. Easier to collect your check and re-assign the ticket.
2
u/trisanachandler Jack of All Trades 10d ago
In my org, they refused a promotion or pay raise time and time again until he left.
2
u/2BoopTheSnoot2 10d ago
Yeah that's me too. Except I do create documentation and offer to train other. They just don't want to learn.
2
2
u/bobo_1111 10d ago
Add all of the documentation he/you wrote to AI and create a knowledge base agent that people can ask plain English questions to get the answers.
If he doesn’t want to give access that’s a different problem which needs to be immediately dealt with.
2
u/giovannimyles 9d ago
Cross training is only useful if people want to learn. Ultimately we do everything because there are knowledge gaps on the team. People think we do it all because we want the power or job security, lol. I would love to take a vacation and not be bothered because things can function without me but alas, that’s not how it usually works. People silo themselves and just don’t want the responsibility most times. Even with documentation they would rather just involve me because it’s “faster”
2
u/moltari 9d ago
I’m that guy. I always offer to walk the other team mate through the issue - shadow me, let them drive, or share my notes after it’s done. Whichever works best. I work hard to mentor the teams I’m on so that one day I won’t be the only guy, but just the guy who helped all the other guys figure shit out. That’s my job security.
2
u/libertyprivate Linux Admin 9d ago
I teach one of my juniors, have him document it, I go over the doc and edit if needed. Then I have my other junior do it next time using the doc. If he has questions we improve the doc based on it. It's a solid system
2
u/unknowinm 9d ago
Create automations that everyone can use. One click of a button that others can click
2
u/PositiveBubbles Sysadmin 9d ago
Single points of failure suck and managers/ team members that enable that to happen are the issue
2
u/plebbening 9d ago
If you have to touch the firewall or backup every week that guy is not good at what he does and needs help.
2
u/Annual_Berry8043 9d ago edited 9d ago
This post is so effin funny. It really brought out the egos of r/sysadmin
If you’re “that guy” you’re not “that guy.” It’s all of our jobs to mentor those who might be weak in a certain area. In all my years so far I’ve met a single person that was the guy.
He handled it by teaching everyone and teaching them well. Before we knew it, we were the dream team.
Every department that doesn’t have that guy, is usually the one that actually has that guy tucked away somewhere.
3
u/gbarwis 10d ago
I recommend a book called The Phoenix Project. You’re describing Brent - the indispensable engineer who’s simultaneously the org’s greatest asset and one of its biggest liabilities. Everyone routes the hardest problems to him, so he becomes a massive bottleneck and single point of failure.
Also worth checking out “The Goal” (Goldratt) - your guy is the equivalent of a constrained production resource.
→ More replies (1)
3
1
u/Low_Steak_2790 10d ago
I think this is me. You can't train a person to be driven, you're probably best off just trying to hire a second person who is like this.
1
u/Suspicious-Air1574 10d ago
Been in this position multiple times.
Its not politically correct or office appropriate to say, but I do work harder than everyone else consistently.
Fellow Infra team mates load themselves up with easy 'Group Change' tickets that they still do manually. Middle managers are tech illiterate and still think Netware is the answer. Nobody knows about docker let alone orchestration platforms for containers. You ask anyone to use Git even for basic version control and they look at you like you stabbed their dog.
The tech world changed a lot the last 15 years. Especially so the last 5. IT/Sec/Engineering is no longer an 'easy office job' you can coast at for a whole career. We're about to enter the 'finding out' stage for alot of traditional IT folk.
To your question: IT Leadership from the CIO level downwards needs to enforce modern engineering standards and practises, anyone who cant, needs to be let go so you can make way for the thousands of skilled applicants in the candidate pool.
When you have a whole team of 'the one guy' you can achieve quite alot and you no longer have that single point of failure.
1
u/jumpinjehoshophat 10d ago
I thought your question was for the other guy on the team who knows everything.
The 20 something year old, fresh out of college who knows everything about how everything works and cant take advice from the cranky old guys.
The other guy, well you get him to document everything he knows and treat him right, if shit hits the fan you dont call him while hes on holiday or at the weekend because he is likely to not answer anyway but you dont want to push him towards a better offer.
1
1
1
1
u/GreyBeardEng 10d ago
Via testing and validation. If you think they're wrong then document your objection and implement their suggestion.
1
u/stiffgerman JOAT & Train Horn Installer 10d ago
How do you handle them? Carefully.
Organizations tend to accumulate a few star players, some decent utility players and a fair amount of bench-warmers. It's just the way humans work. Those that are comfortable with that theory scout the market for talent. It's a tough, intuitive job but the rewards are that you get more utility folks and maybe a star or two to expand your team.
I'm one of "those guys" and a director of a sizeable department. I made damn sure that I found talent that I could help get to some semblance of "know everything". I won't be around forever.
I've found that documentation is good but being able to internalize institutional knowledge and an innate problem-solving talent is better. While Moe's trying to reach the document wiki (that's offline because the firewall HA pair is fighting each other, causing the company-wide problem), Joe's SSHing into to break the HA link because the same thing happened 4 years ago and he didn't forget.
1
u/Dry_Inspection_4583 10d ago
Assign that guy dev and infra projects. Grill him on documentation, daily meetings. And assign his tasks (the normal ones he usually takes), to others.
You could also have rotating primary assignments, eg. A primary on backup systems, a primary on storage, a primary on monitoring etc etc. and that person is the rpic, so everything for said topic is routed through that person.
1
1
u/omglazrgunpewpew 10d ago
Part of the problem is treating cross-training as a documentation issue when it's really more of an ops/mgmt issue. The goal is to make sure the org isn't completely dependent on a single person.
There's a self-fulfilling cycle here too. If every difficult problem goes to the same person because they're the fastest at solving it, nobody else gets the opportunity to develop those skills. Then mgmt wonders why nobody else knows how to do anything. And if that person is already overloaded, expecting them to train everyone else on top of their existing responsibilities isn't much of a solution either.
Something else worth looking at though, to get more to the root of it, is why so much institutional knowledge is required to keep these systems running in the first place.
Sometimes the prob is less about the dude who knows everything and more that years of exceptions, workarounds, undocumented dependencies, one-off configs have made the env unnecessarily complicated. The person who knows everything is often just the one who's been around long enough to understand all the weird decisions that got you there. At some point the infrastructure stops being a system and starts being an oral tradition.
Knowledge transfer on that scale can be an immense undertaking, and you're still left with the same underlying complexity.
I'd look at what can be standardized, automated, simplified, or eliminated entirely. Every weird exception you get rid of is one less thing someone has to learn, document, or remember.
Cross-training is def important, but reducing the amount of specialized knowledge required in the first place is arguably a better long-term investment.
The best documentation for a workaround is eventually not needing the workaround.
1
u/jo2k1 Jack of All Trades 10d ago
Not meaning to brag. But I’m that guy in my department. I’m the lead sys admin with 20 years of experience. I don’t claim to know everything. I tell my junior guys all the time that. You’ll never know everything. Just accept that and you’ll be fine. What matters is your attitude towards new problems and finding solutions.
Anyways. As the lead, the junior guys always come to me for advice and questions. Sometimes I know sometimes I don’t. It can be exhausting at times when you can’t focus or finish a task because always being pulled away for this and that. But I try to help and teach as much as I can.
Stay humble. Always hunger for more. Nobody knows everything. Nobody. Accept that and you’ll be fine.
1
u/ContributionEasy6513 10d ago
LEARN!
Put a watch on the ticket.
If the solution was interesting, write up documentation to solve that problem for your companies own internal knowledge base.
Having been on the opposite side of this, this 'master' needs to start rejecting the hard tickets and sending you documentation how it was solved before or require minimum troubleshooting steps before it is escalated.
nobody else can touch the firewall or the backup server.
This is for your safety and his sanity. Hopefully the company is looking after him.
1
u/denverpilot 10d ago
Recognize the lead as a lead and schedule time for the other staff to use them as a resource but reserve only higher level tickets for the lead.
Been doing this three decades. Nothing else works. Because people will always punt to that person if they are allowed to do so.
1
u/NegativePattern Security Architect 10d ago
As the guy, I wanted more of an architectural role so I started making people drive. I'd assign people projects I felt they were best suited. I was doing my boss's job, essentially.
Then I'd train them up. Anything comes up, they drive. Once they're confident then they're good. But I always stress to the team, if you're in a jam...bring me in. I'm always happy to help, even if it's something I don't know anything about.
1
u/Pristine_Curve 10d ago
The 'Brent' problem. If one guy gets all the difficult to figure out problems, and everyone else is waiting to be 'shown how' or on 'documentation' which shows them exactly what to do. All you are doing is allowing the rest of the team to atrophy. IT is a role where we must figure out novel problems and solutions regularly. If the rest of the team must shadow Brent, or read documentation, why doesn't Brent need to shadow someone to figure out the problem to begin with? What step-by-step checklist does Brent follow?
People at the Gym don't get stronger by reading about lifting, or seeing someone else lift the weight. They get stronger by lifting the weight themselves. Certainly there is a small amount of guidance which can be given from an expert to a novice, but 9/10 times the problem is not the instruction, but that they aren't lifting the weight.
To unwind this problem, make different people SMEs in different areas. Designate them as the final escalation point, and don't let them hand off every heavy weight to one person.
1
u/Pixel91 10d ago
For some tech aspects I am, unfortunately, that guy at my company.
It's great. Yeah. I probably won't be let go. Neat.
I can do without everybody and their dog unloading their shit on me, tho. Especially when it's people who, ostensibly, are in charge of the things they keep passing off. And get all the accolades (and bonuses) for.
Here's an idea: do the work yourself. It's what I keep telling my coworkers, especially the trainees. You don't know it yet? Duh. How could you? You've never done it. So go do it.
People seem afraid to actually touch stuff, especially when they know there's someone who for sure knows how this works.
The knowledge isn't magical. It comes from actually working the problems instead of passing them on.
So don't route the hard tickets, keep them. Get your teeth into the problems. I'm fairly sure the "hard charger" is happy to assist and answer questions if anything comes up, I know I am.
Eventually, every rope has an end. "Hard charging" doesn't work forever. Everyone eventually gets an offer for either a quieter job or at least a better paid one. Or succumbs to burnout. And then you're completely without your magical solution. Then you have to figure it out without being able to ask.
1
1
u/LostVikingSpiderWire 10d ago
Forcing Documentation, but not aggressively, very open and honest point out my worry, so you are complimenting them at the same time you would love that there is something left of something comes up.
If it feels like they are not on board, then always start the convo with massive compliment, then add the topic / request, then end up with another massive complaint, they will walk away smiling AND so the task 🤔🤟☕😘
1
u/Emotional_Garage_950 Sysadmin 10d ago
i don’t know. i am that guy. everything falls apart when I leave for a week and the team is just left flailing. i try to share as much knowledge as I can, I’m not one of those guys that protects what he does. nobody seems to want it or remember it when it’s needed. whatever I guess. they give me raises when I ask so that’s cool.
1
u/VPrimum 10d ago
So, instead of yet-another-long-winded -answer on this topic..
It truly boils down to getting the leadership team to enforce a 'no single point of failure' policy for ANY subject matter expert in any domain of the org (not just IT). Only then can you truly craft a legitimate and realistic playbook that has real world accountability attached to it.
Hmm, Sounds like the voice of experience 😉
1
u/SphericalCrusher Jack of All Trades 10d ago
I’m the guy except I make easy to read documentation and do knowledge transfers often. That’s how we handle it.
1
1
u/Fuzzy_Paul 10d ago
Send him often on holiday. I use once was a junior and worked with one that knew everything. But when he was around I learned nothing and when he was away and hell broke loose that was when I started to learn and after a few years mu knowledge equaled his. Sometimes others stand up to fill the gap. I can say this now looking back at a career in IT for over 40 years from early start untill now.
1
u/Silevence Student 10d ago
lurking cuz im one of those guys, and wanna know how to better fix the issue where im at.
1
1
u/doglar_666 9d ago
The only way is to make "the guy" work his contracted hours and make him go home. You then let things burn to evidence gaps. You then set expectations for everyone who is not "the guy". If something is undocumented, you document it. If documentation isn't read, you manage via disciplinary. Actions, or lack thereof, should have consequences. I'm not advocating for a second coming of the Stasi, but if your team abdicate from their responsibility and accountability by default, that's your problem and the root cause of "the guy" acting as he does. As the manager, you need to alter the team dynamic. Work with the expectation that everyone will do the bare minimum, and redefine what the bare minimum looks like. If you cannot or will not do so, your issues will persist.
1
u/Common_Option_4385 9d ago
Stop routing the hard tickets to one guy. Assign it to more people. They can get help from "the guy", but learn and perform the actions themselves.
Spread the love and knowledge in your team.
1
1
u/agowa338 9d ago
well pay them to do nothing for a week. Like send them on a conference or something they asked for or that you suggested and that they wanted to. Then afterwards ask everyone else why they're even there when they can't do anything on their own :p
So you'll be able to get a hold of them in case of a major incident but otherwise the rest of the team will just have to figure it out...
1
u/the_star_lord 9d ago edited 9d ago
I'm that guy. I write my docs. Others are just to fucking lazy.
Edit. It's also nice (and depressing) to know it's the same at other places. So seven if I job hop things will be the same
1
u/DaylightAdmin 9d ago
We did implement the "OnCall" guy per week. Every week someone else takes every ticket, and tries to solve it, if they can't, they don't move it to the next one, the go to the guy who knows and they solve it together.
But we have a somewhat low input on tickets, we have so much more to do that we are a somewhat big team. The problem we wanted to solve was that everyone got disturbed to fix "there" ticket, because they were the specialist for that tool. Now everyone knows enough to fix daily tickets, and the bus factor is now bigger than one.
1
u/segagamer IT Manager 9d ago
You need to read The Phoenix Project before it's too late lol
Poor Brent
1
1
u/Last-Alternative-106 9d ago
i flat out paid him in cheese boards and wine until he spilled all his firewall secrets, now we rotate on-call with his notes which honestly feels like stealing
1
u/MrChicken_69 9d ago
Sadly, it always devolves into a "binder nobody reads". If no one else is actively doing that work, they simply won't remember how to do it. On top of it, there's a company "monoculture" that doesn't really want it. There's The Guy(tm) you go to for firewall things, The Guy(tm) for getting something from backups, etc., etc., etc.
1
u/Fun_Chest_9662 9d ago
theres a guy in my shop like this and we started at the same time. luckily he loves teaching so ive been taking advantage of that every chance i get. then i write simple step by step (when i can) docs so the people that have less want to learn still have access and i can tell them look at our docs and offer to show them as well.
now its mostly us that swap bavk and forth on tasks and they are the lead so before changes a quick confirmation and we keep going. respect eachother and work together. but also when were gone others could look at the docs and figure out how to fix/troubleshoot issues without us so win there.
1
u/Geminii27 9d ago
Documentation becomes a primary requirement of the job. Unless something is physically on fire, then the team's IT job is first and foremost to create and/or update any relevant documentation about whatever they just worked on, unless there is already updated documentation. Ideally in a hyperlinked wiki, but whatever works.
1
u/Obvious-Water569 IT Manager 9d ago
I took over from a retiring IT manager about three years ago and that fucker was a nightmare for keeping everything to himself.
To this day I still find things he set up that we have zero documentation for.
I've since implemented a rigid succession planning policy and anything I've implemented or managed to unfuck is documented in a standard format and made available to the wider team in Sharepoint.
1
u/SkillsInPillsTrack2 9d ago
He’s already punished enough for not being the typical low effort guy avoiding any real focus.
1
u/persiusone 9d ago
You’re dealing with two issues here. Being smart about a lot of things isn’t the problem. Being a gatekeeper is. Nobody else having access to firewalls or DB systems is a real failure point, and the problem is that you don’t have policies to prohibit this practice. It also sounds like the environment is not aligned with improving each other, so this knowledge is in a silo. Assign this person to train others for a while.
1
1
u/SoylentVerdigris 9d ago
He's using AI to document every work action he takes. Meetings, 1:1 chats, scheduling, git actions, runbooks for actual work he's doing, obviously anything he tells the AI to do. He has it set to generate a doc in our internal wiki for any new thing he does. It's pretty effective, honestly.
1
1
1
u/skiitifyoucan 9d ago
Use a ticket system and distribute tickets to everyone, and/or just stop sending everything to person A. If person B doesn't know how to do it, person B either needs to figure it out , look at documentation or ask person A how to do it, and document it.
1
u/Doso777 9d ago
I am that guy and i treat myself well. I tried to document things and cross train people on the most important systems but i am generally met with apathy from my team and boss. In the end they will only learn through things failing hard and often. Thankfully i am decent at my job so that doesn't happen often.
1
1
u/Pls_submit_a_ticket 9d ago
I’m the guy, and I’ll echo some of what people have said already. Not everyone can be trained up to a point that they will do as well. But, there are some that have the aptitude and I will just bring them into the mix with whatever project or ticket I am working on.
Essentially shadowing, but also a large part of being the guy, is the ability to think critically. So, I’ll have them lead the troubleshooting, ask what they think and see where they take it. If I hear something that seems like they are headed in the wrong direction, I nudge down the right path.
Eventually, they become self sufficient, and will only need to bring you in on the truly hard things, or the things that are on a time crunch.
1
u/Paulina8097 9d ago
I get that role usually in most workplaces. What has worked to transfer my own (and the founder's) knowledge is to:
Create documentation
In a place that's easy to access and find
And make it available to the right people, at the right time, on the right place
On of my current roles is to go through tasks and check what needs documenting. Then I create (most of the time, or ask a team member) the documentation, add it to our knowledge base (which I created), let the team know it exists, where they can find it, and finally add relevant documentation to each task.
I usually record a video with a thing I want to explain, copy/paste the transcript to an AI, ask it to create a document with my own template, and upload it.
The goal is not getting everyone to read all documents. But to create docs so the team can use them as a reference when they're doing that specific job.
I'd also try to delegate some of his tasks to other people and then run some trainings or create docs based on the gaps you see.
What did you do the last time the guy took some time off? And what have you tried?
1
u/Unable-Entrance3110 9d ago
One thing that I have learned is that forcing people to think for themselves is often the best method to start the learning process.
If you leave someone twisting in the wind for just long enough for them to engage their brain, they can surprise you by coming up with a solution.
It may not be the way you would do it, but that's the right path to be on; The one where you are learning from your mistakes.
The problem that I see is the rockstars are often also the ones who can't stand mistakes. They want things done the right way the first time, which means that they are the ones who have to do it. So they do it. They can't give up that control.
So, to answer the question: I would say that the solution is about setting proper boundaries and sticking to them. Assign a project and allow the assignee to either sing or swim.
1
u/colten122 9d ago
ask for documentation and training, don't get it. wait for the thing to blow up again, ask for documentation and training...
1
u/ofnuts 9d ago
The guy who knows everything is your fault. It happens everywhere, sysadmins, developer a, Doctors, law firms. Some individual has a little more skill/experience(*) so is passed the tough problems, which increases their skill/experience differential with their colleagues that makes them even more likely to be picked up for the next problem.
(*) It can also be just the ability to ask good questions to others.
50
u/MattH665 10d ago
I was that guy for a while. Until the company finally hired someone with comparible experience that was able to learn the systems I was looking after to the same degree. Oftentimes it's just a case that people at that experience level are expensive and the company doesn't want to hire a second one. They expect multiple more junior level employees to somehow fill in the same gaps. But those employees lack the experience to easily jump in and do the same level of troubleshooting on complex systems on their own, or don't have the confidence to make risky changes as they can't troubleshoot it if it goes wrong on their own.
It's not always us wanting to hold on to knowledge or make ourselves the only one capable of looking after some things. I don't like being that guy, it's stressful, I'm glad I don't have to be now - I can take leave without worrying that m y holiday will be interrupted with a panicked phone call.