How to deal with a Brent character- any tips?
Posted by DevopsCandidate1337@reddit | ExperiencedDevs | View on Reddit | 38 comments
Wondering if in fact there is anything I can do other than move on to another shop.
I'm at a medium size business where there is one engineer who seems to determine their own job title, job description, tasks etc. despite being nominally attached to a team. They are a 'Brent' type - always 'there', always the one swooping in at any hour of the day or night for any crisis or any initiative, leaving nothing for anyone else. At some point Brent's line manager moved on, as did their skip level, so they wound up reporting to a different director with their own wide remit and large number of direct reports rather than a regular EM as would be normal at 'senior' grade. This is despite Brent being nominally a 'senior' rather than lead/staff/principal/manager etc. Brent is very personable and reasonably capable. They get the job done but without being particularly visionary or producing elegant solutions. Brent doesn't really work in a collaborative way or get their work reviewed.
The problem is that Brent seems to actively ensure that they're the only one with administrative access to this and administrative access to that and that nobody else is. Those things are not meaningfully documented and knowledge of and and access to credentials is not shared. This has already had significant consequences to the business including in house systems going down, sometimes for several days, that everyone has to wait for Brent to fix. Naturally the business's incident post mortem system 'could be improved' - boiling down to whatever the incident commander decides is appropriate and the incident commander being decided by whoever wants to grab the job first at the time... Brent seems to be motivated by the intention to be the last one standing when others get laid off- based on things that they have directly said.
Concerns have previously been raised publicly in a 'jokey' way in larger meetings about how the business intends to ensure cover for Brent but it's not obvious that anything has changed in response. Ditto for post mortems - management seem to think 'well the issue was dealt with' (at the time).
Wondering if anyone else has successfully navigated a situation like this and how?
PianoConcertoNo2@reddit
I’m so confused.
This reads more like only “Brent” is proactive and taking the initiative, while yall aren’t.
“Leaving nothing for anyone else..”
Ok…why aren’t yall responding or asking to shadow and learn? “I want to learn this, can I handle it next?”
Why is it only him with admin rights? It sounds more like you don’t have the trust and confidence built up to be given them..
Start taking the steps to build that trust, and then start documenting…
DevopsCandidate1337@reddit (OP)
Oh wow, let's just say that you are very, very wide of the mark.
Normally some stuff would be managed by IT and some stuff managed by engineering. Brent has been able to convince management that (only) they are 'part of' both groups so they are 'special'- the only IT person with engineering access and the only engineer with IT access.
There isn't a formal incident on call rota. Brent watches for incidents like a hawk.
PianoConcertoNo2@reddit
I'm still confused...
"I want to learn to solve this, please include me next time it happens, here's my phone number...".
What happened when you said that?
Material-Smile7398@reddit
Have you ever worked with a Brent? they have 100 tricks up their sleeves to avoid handing over knowledge. Politely asking won’t get you anywhere.
PianoConcertoNo2@reddit
No, I’ve never even heard of this, and having a name for it is goofy as hell.
Be an adult.
“I want to learn this, text me next time please.”
“It happened again? Can you please text me when you notice it next?”
Variations of that aren’t hard. Stop with this “Brent” stuff and use your words.
Material-Smile7398@reddit
If you don’t like the term then maybe this thread isn’t for you. I hadn’t heard of the term Brent before this thread, but since everyone else is using it and we clearly know what type of person we are dealing with then it’s much easier than writing a whole sentence to describe how they hoard work.
I’m thinking you are maybe a little naive if you think that asking nicely is going to make him just stop. This comes from the personal experience of having worked with several people who follow this pattern.
The OP was asking for input from those who have experienced this type of thing before, clearly that isn’t you, so I’d suggest you could learn from those who do have a bit of experience.
Failing that, I wish you luck with your “please stop with the practice that you have used successfuly so far use to secure power and job security”
PianoConcertoNo2@reddit
Posters are using the term because OP used the term. Many are thinking it's David Brent from the UK The Office...
And no - it doesn't tell us anything about how the person actually is. It just tells us how OP perceives the person to be. OP could also be wildly incompetent and on the way out, and "Brent" feels like they have to carry the work so OP doesn't screw it up while they're still there. Or maybe they're just newer and haven't gained the trust / taken the steps to show they know what they're doing. Or maybe they've shown they have a tendency for carelessness, and "Brent"/whoever else doesn't feel they can safely handle that responsibility. ALL of those are possible...
I mean, you're literally having to mischaracterize what I said by injecting some weird passive/timid characteristic to it, in order to make this claim work. It's weird..
engineered_academic@reddit
several DAYS of outages and nobody cares?
Brent is not the issue here.
serg06@reddit
Several days of "in house" outages. That could mean something like a WYSIWYG marketing email editor going down, having no business impact.
Material-Smile7398@reddit
I've been dealing with a Brent for about 5 years, everyone strongly dislikes him, and knows what his game is, but management let him continue for too long and now the company is held over a barrel, unless they pay for a hugely expensive system to replicate the functionality of my Brent's fiefdom.
To distil this to the very basics, he is stealing opportunities and job security from everyone else. Its likely that everyone knows what is going on, but doesn't know what to do about it, or doesn't have the energy to fight it.
The only way I think you can really win is to come up with a road map to have the codebase and access shared. It can be framed as mitigating the key man risk to management. They will likely support it but again, not really understand the mechanics. The unfortunate thing is that management tend to see fires being put out by Brent, reinforcing his 'invaluable' status, what they don't see is that he lit the fire in the first place by hoarding information. Expect Brent to see this threat a mile off and go on the offensive.
I'm sorry to say but I don't think you can win here, they have let the situation go unchecked for too long.
nfigo@reddit
I found environment variables with the credentials I needed to fix what broke while he was gone.
He thanked me for taking initiative. I don't think he meant it.
Soon, I found another job, and nobody else cared about any of this. Was glad that I didn't have to, either. I doubt much changed.
rodw@reddit
This is tangential but where does using the name "Brent" to describe this kind of person come from? I don't recognize that, and can't even think of a famous Brent right now, so I'm curious where calling someone like that "a Brent character" comes from.
DevopsCandidate1337@reddit (OP)
It comes from 'The Phoenix Project' please let's not get into a side conversation about the use of the name here
engineered_academic@reddit
FYI if you add a link after you create the post automod will remove the post. I have restored it but keep that in mind for next time.
DevopsCandidate1337@reddit (OP)
Thanks. That same link was there initially. Edit removed a second sentence that was less helpful than I'd expected
TrySouthern9542@reddit
ai could never come up with a response like this i'm crine 😭
roodammy44@reddit
This whole post I was thinking of David Brent and wondered what on earth OP was talking about. This Brent doesn't sound like David Brent.
rodw@reddit
Maybe you saw this already but OP pointed me here for a summary of the book "The Phoenix Project".
Dubsteprhino@reddit
It's from a book called the Phoenix project
lphomiej@reddit
It's from the book "The Phoenix Project".
PartemConsilio@reddit
I don’t deal with our Brent. I make my tech lead deal with our Brent by driving him to document his processes.
Also, at some point anybody becomes some form of that guy. You relieve the chance of that happening by learning to prioritize work and also delegate it to lesser experienced people.
Never-Trust-Me@reddit
Look in the mirror :p
Mephiz@reddit
> actively ensure that they're the only one with administrative access to this and administrative access to that and that nobody else is
I would start here. I would ask politely to have access to these and then document the responses if they are anything but positive.
If, for some valid reason, you can't have access: ask point blank for a list of all the alternate administrators.
Bonus points for adding all of this to your issue or bug system.
a2ur3@reddit
Access is pointless if no one knows how to manage or fix these systems. People that don't know what they are doing shouldn't have access to systems just to attempt fixing things during an outage and potentially making things worse.
DevopsCandidate1337@reddit (OP)
With respect - this might apply to a standard or third party system. More difficult to justify in the context of a bespoke system with a single architect, builder and admin
a2ur3@reddit
I think it's the opposite in this case. The bespoke system evidently isn't documented, which is an organizational failure. Brent has the knowledge and experience with these bespoke systems and hasn't been told to document anything. So, everyone expects Brent to handle the issues, which means they don't have to handle them. Another organizational failure. As someone else commented, this isn't a Brent issue - it's a mangement issue. Leadership doesn't care because there hasn't been a big enough issue (yet).
SuaveJava@reddit
THIS needs more upvotes. Admin credentials need to be managed and kept by the company and assigned to roles, not people.
Longjumping_Bug423@reddit
Sounds like you’re at the wrong company, I’ve worked at places like this in the past.
The focus should be on avoiding Brent type problems. If issues like these are constantly recurring, its a leadership problem for enabling someone like Brent to exist
shaileenshah@reddit
You don’t fix a “Brent” by out-Brenting them—you fix the system that allows it.
Focus on risk, not personality. Frame this to management as a single point of failure problem: undocumented systems, exclusive access, and lack of review are operational risks (downtime, security, compliance). Suggest concrete fixes like shared access (e.g. via vaults), mandatory documentation, on-call rotations, and postmortems with enforced follow-ups.
Avoid making it about fairness (“they take all the work”)—keep it about business continuity and resilience. If leadership still shrugs after clear, risk-based escalation, that’s your signal the culture won’t change much.
In parallel, protect yourself: document what you can, ask for access in writing, and avoid becoming dependent on Brent’s knowledge silo.
DevopsCandidate1337@reddit (OP)
Thanks, I have no wish to become an additional Brent. It's more like watching a car crash in slow motion
onceunpopularideas@reddit
I’ve seen worse where the team is essentially controlled by a Brent. Ultimately they find a second gatekeeper and start developing undocumented insider solutions, workarounds and processes. I have no solutions except to say I’ve seen a lot worse than a solo Brent. If possible try to build alliances especially with staff or principal engineers and don’t try to fight this alone. Without some colleagues working together on this one it’s a pretty tough nut to crack.
DevopsCandidate1337@reddit (OP)
Thanks, confirms my fears
CorrectPeanut5@reddit
Ultimately, if you're not on a track to promotion I wouldn't see a reason to put efforts and political capital into the "Brent Problem". At most I'd give him rope to hang himself and make sure any time he's a blocker for your work that you're calling it out in standups.
Keep your head down and resume updated. Concentrate on doing things to make yourself more marketable and let Brent take the heat when things go sideways.
DevopsCandidate1337@reddit (OP)
Sadly this does seem like the most pragmatic approach
aaron_dresden@reddit
A career is a marathon. You’re going to encounter a lot of different types of characters over it. Being pragmatic is one of the best ways to make it manageable.
lphomiej@reddit
Usually "Brents" occur when someone is motivated by solving little fires here and there and isn't motivated or encouraged to share these types of loads because they're usually the fastest option. This happens over a long time and the person is usually rewarded and promoted because of it. As you know from the book, someone has to make the decision to endure a little pain to slow down and let other people learn and share the load. This isn't really something a peer can do unilaterally - but you can have a convo with them and your manager, expressing you want to help break up with bottleneck person and share the load.
DevopsCandidate1337@reddit (OP)
Not so much this one, as written
Miserable_Heron_9007@reddit
Promote him to manager.