Why do some employees intentionally create dependency instead of documenting and sharing knowledge?
Posted by Ecstatic_Jicama_1482@reddit | ExperiencedDevs | View on Reddit | 141 comments
What are your thoughts on employees who make sure systems and processes run smoothly even when they are on leave — through proper documentation, automation, and knowledge sharing — versus people who intentionally keep critical knowledge to themselves?
Some engineers ensure the team can function independently without them. Others avoid proper documentation, keep key details in their head, and make sure work becomes difficult in their absence.
I’ve especially noticed this in some contractor and service-based company environments where people try to create long-term dependency to secure their position.
Do you think this comes from job insecurity, company culture, survival strategy, or something else?
ben_bliksem@reddit
Job security
UnderstandingDry1256@reddit
poor man's job security
Confident-Alarm-6911@reddit
I used to think that way too, but when I see how companies treat their employees these days - all the layoffs, push to get rid off devs - I’m (unfortunately) starting to change my mind.
CodyEngel@reddit
How so? Unless you're working in COBOL or are an AI researcher you are replaceable. I have worked with people who thought they weren't, turns out they were and often times the team works smoother without their toxic behavior.
Confident-Alarm-6911@reddit
I actually work on AI, and it’s not that I think I’m irreplaceable, everyone is replaceable, but getting rid of me would be costly for the company - both in terms of time and money. This is obviously upsetting, and I feel like it goes against the values I believe in and that have long been the norm in our industry, but I still have a family to support. Unfortunately, corporations are devouring our industry and have poisoned it with their idiotic approach to everything
CodyEngel@reddit
Yeah I mean if you are working on frontier models it seems like a safe spot right now. If there are layoffs they almost always make the decision from inside of excel.
Not that the metrics are exactly the same but:
The people making decisions tend to know what information you are hoarding and you could also be a 4/4 and still get axed if the alternative is laying off one too many people in that protected classes that could open them up to lawsuits.
So my point is essentially: you aren't in control of your future with the company unless you're the one putting in your two weeks. Hoarding knowledge is just an illusion in most situations unless it's going to translate well to that spreadsheet.
jameson71@reddit
So it seems that the best thing I can do for my career is join a protected class you say?
CodyEngel@reddit
No? If you're relying on that then you're not making it to the layoffs. It's not terribly difficult to fire an underperforming person in a protected class, it just requires a competent manager (of which, there are few).
I mention that because even if you do everything you can correctly you could still be added to the layoffs for something outside of your control to protect the company from legal headaches.
worst_protagonist@reddit
Uh. The norms are the same as they've ever been.
jameson71@reddit
While true we also have many, many people in the industry that know nothing except the Covid boom.
Leopatto@reddit
Kinda tough to get rid of a principal eng. Good ones are hard and expensive to find, but juniors or mid? Different ball game.
wxz77@reddit
Idk why ppl are downvoting u, i see nothing but facts
CodyEngel@reddit
Facts and Reddit are water and oil.
FrenchCanadaIsWorst@reddit
And even if you aren’t replaceable, you’re still replaceable. They’ll just let everyone else scramble til it gets better
UnderstandingDry1256@reddit
Lack of documentation will not protect anyone anymore. Either you drive the AI adoption and updating all the pipelines, or you’re replaced by folks who do it.
Crafty_Independence@reddit
Lol people building an overdependence on AI are a dime a dozen. They are far more replaceable than the experienced engineer who keeps their core skills intact
UnderstandingDry1256@reddit
Haha classics. I’m old enough to remember times when experienced devs were saying OOP is shit and makes minds degrade, only pure C is the truth and way to go. Same shit - being incapable to adopt new concepts does not make you more skilled. Just some people are slow and lazy.
Unhappy-Ladder-4594@reddit
While knowledge hording won't always keep you from getting laid off, it can at least give you a small bit of pleasure knowing the company will at least suffer more losses than they would had you been more forthcoming.
Enesce@reddit
Helped me survive 3 lay-offs in 1.5 years, then I jumped ship in my own terms. 10/10 would hoard knowledge again.
Bushwazi@reddit
Yup. And I used to care but now I really don’t. More power to you if you can pull it off
ben_bliksem@reddit
Exactly. I worked with a colleague a decade+ ago where he wouldn't really explain how the CIVD pipelines worked. Literally said as a "joke" that is for job security... and then he immigrated to New Zealand a few months later anyway.
Thought he was a bit of a dick about it.
But since then layoffs became the norm, teary eyed "we appreciate what you did for us" circle-jerk layoff notices... man screw then. The power of job security by not documenting your entire skill set may be over in the age of AI but like you said: if you can find a way, more power to you.
jameson71@reddit
So he was leaving shortly and you believe he was worried about job security?
Says a lot about where you work.
coyote_of_the_month@reddit
Companies don't care how critical your knowledge is. They are ruthlessly amoral, but not stupid. They know critical knowledge is lost when they lay people off, and they budget for the decreased productivity.
The ramping-back-up costs are offset, because they're cutting bonuses and raises after you fail to meet the now-unachievable company goals. And sure, a few people will quit because of that, but that's budgeted in too: they laid off 1 or 2% fewer than they really wanted to cut.
And yes, it's going to be the top talent that leaves, if they weren't targeted in the layoff. That's not just budgeted in, it's intended. Top talent is expensive, and they're a waste of money when the company is trying to pull itself back together after layoffs. By the time it's needed again, it will have re-emerged internally if the company manages the talent vacuum by dangling promos. Or they just hire extremely when business conditions are more favorable.
deathofsentience@reddit
I mean, they very much are stupid.
coyote_of_the_month@reddit
Undoubtedly, companies make stupid decisions all the time.
But we'll never know how many of those decisions are actually stupid, and how many of them are driven by agendas that simply not aligned with with the company's best interests.
elliott_oc@reddit
I would call a decision that is not aligned with the company's best interest a stupid decision. Especially if that runs the company into the ground. Which happens literally all the time.
There is no 5d chess game being played at the top. It's just all fools with too much money.
coyote_of_the_month@reddit
Think about the well-known private equity playbook of acquiring a company, loading it up with debt and troubled assets from the other companies in the portfolio, and then liquidating it. That's an extreme example, but it does happen.
It's not 5d chess by any stretch of the imagination, but it's not stupid either. It's banal, cruel, and destructive, but it's not stupid.
Unhappy-Ladder-4594@reddit
It would be extremely stupid if they cared about the long term good of the company. But they don't. They're basically just buying it to strip it for parts and sell off the pieces that are worth money. More often than not they win, and everyone else loses.
lookmeat@reddit
It's a dumb way to know about it. You don't get job security by becoming a ticking time-bomb for the company.
Put yourself in the boss's shoes, you say "We need to cut out this guy" and then they'll respond "we need him, he's the only one who knows how the system works". Now you know one thing: you're fucked. Because this guy will one day he'll move to another company with an offer you can't match, or have personal issues, or retire, or get run over by the bus, and then you'll be dealing with this issue. Now why not wait until you are able to create a replacement and transition? Because this is an employee who is actively going to hamper and harm any attempt to do so. If you push it to the limit the employee, reading the writing on the wall, will escalate and bring out threats to milk out as much as they can. And this assumes they don't get a chance to really screw you over: suddenly a market correction, or a shift, or new competition, and you are on the losing side and you really can't let this guy go.
So the answer is simple: fire them as soon as possible, the reason being that the quality of the work they do is not good because of the issues described above. It's at will employment most of the time. It'll be painful but it'll be pain on your terms: just consider the cost and risk and amortize it with the other projects.
And yeah you get people like these. Though in my experience I've never met someone who explicitly does it for job security, but rather it comes from impostor syndrome, lack of good habits, or they are engineers who work best on singletons because they struggle to communicate through a myriad of issues (e.g. neurodivergence). The last group do have their place, if you know where to put them, and yeah it's a career dampener, so poor guys will have to live knowing they hit a roof as senior engineers with their 180k-250k salary. Honestly the last group is about placement and knowing how to guide people to where they are most effective. The former is rare, and generally either temporary or you never advance far enough on your career to be a real problem.
But that doesn't fully answer OP's question. Because most engineers who do this aren't doing this with the intent o job security. I'll hijack to give the answer: because they just do what they're paid for, nothing else. It's doing the job and not doing more for free.
There's a clue in OP's question:
Not really. These are people who are billed by the hour. If you want to be cheaper you need to cut hours from somewhere. If you have to choose between tests and docs, it's better to cut docs. The vendor company or contractors just do what the contract specifies, they don't charge extra, they don't work extra. If they did work extra, they'd charge more and the company wouldn't hire them again.
What happens is that contractors/vendors are best for jobs that either are relatively standard (e.g. build an http RESTful CRUD frontend on top of our backend following the specified API) and therefore not hard to understand/maintain (no matter how badly its documented), setting up foundational work that then it's built on top of (e.g. set consultors to help create processes and tools to pass some compliance certification, but afterwards it's just about doing occasional audits to ensure compliance), or something that is isolated enough and you don't really care for too much (e.g. wrap your platform RPCs api in a Ruby library that is well done in the language, even though you aren't a Ruby shop). In all these cases we see the thing: the system is going to be hard to understand either way due to lack of expertise, you mostly get it working and don't need to touch it often, and it's the kind of projects you drop quickly and easily or not so it's better to get a low-commitment contractor on it rather than a more expensive full-time.
Phew. So what is happening? Well sometimes companies will try to hire contractor/vendors/outsourced teams for everything, including jobs where documentation and a locally available team carrying the theory that is the real software in their heads available with little culture shock or challenges.
That document also has another important implication: there's no way to encode everything about software. There'll always be a ramp up time when joining team for other software. There'll always be tribal knowledge, documentation or the lack of it is a problem of transferring and working with that. Which brings me to actually talk about OP's question directly:
I don't have thoughts on individual employees who I don't interact with in any way. I worked on helping teams get away from arcana being lost and critical pieces of the system not having any documentation with no one knowing what to do about it. What I've learned is that instead I have thoughts about teams that do not document systems, so what if you have a guy that doesn't do it, why doesn't anyone else write that doc? Why doesn't it get published? Why are things so bound to a single person that they can harm the productivity of everyone else so badly?
And yeah I have strong opinions about teams that use their employees effectively so that no one is irreplaceable and no one is critical, and those that instead confuse replaceability with fungibility and who mismanage engineers and do not know how to promote sharing and communication.
ProbablyBsPlzIgnore@reddit
You assume there's a plan. I think it's just because writing documentation is a chore and not everyone has the willpower to do the chores.
EkoChamberKryptonite@reddit
Yup.
PsychologicalCell928@reddit
As a manager I found it pretty easy to manage:
Well, since no one else can do your job then you're stuck doing it. That removes you from the promotion list. It means I can't free you up to work on the newer more interesting projects. There's no sense in sending you for training on new technology approaches since you'll never have the opportunity to use them.
True story:
My company took over another company that had some legacy systems. The developers in the acquired company were somewhat unnnerved and did their best to 'remain crucial' by keeping knowledge of their legacy system to themselves.
Two months after I took over I called all the developers into a meeting and asked when we could demise the system or migrate support. They started to give me the standard reasons why it would be difficult. I let them talk for ten minutes and then said, "Ok. You've convinced me. So none of you will be available for any of the jobs listed in these folders." I then excused myself for ten minutes leaving the folders on the table.
When I came back they asked, "Are these jobs real?"
I assured them they were.
The legacy system was demised in one quarter and almost all of the people in that room got promoted.
_______
Long way of saying: people don't share knowledge if they think it provides job protection. However if they see not sharing the knowledge as holding them back then they will change their tune.
So, manager: Ask yourself what will these people do if someone else is able to do their job? How do you make knowledge sharing something that is in their best interest?
HoratioWobble@reddit
Depends on the person.
Megamygdala@reddit
I've probably written the most breadth documentation in my team (mainly because I like referring to my notes when working) and theres probably like just 1 or 2 docs that have more than 3 views. IMO everyone shares their process if you ask but no one cares enough to learn
Gunny2862@reddit
They want to keep their jobs/it's a hassle. There was just a layoff post where all the employees who had completed their projects were laid off and the ones who were still fucking around were kept on.
Brief-Employee-9246@reddit
Just never get around to it
Rusty_Raven_@reddit
Here's the deal - if you're replaceable, you're replaceable. Your job is not to be irreplaceable but to become indeispensable.
If you're the only person who knows certain tribal knowledge, or if you're the only one who knows where all the deployment secrets are, then not only can you never be promoted, you are a risk to the team and will be first on the chopping block when business needs change (which they always do).
Trying to enforce your job security through obscurity is short-sighted, selfish, and toxic. I will try to get rid of you.
Enforce job security by being the person no one wants to see go.
equipoise-young@reddit
I agree with this. I can see some of this behavior if you're working for a high-tech company that doesn't care about you. But if you're doing important work and your knowledge is mission critical for your team to function it just strikes me as selfish.
I take the approach you mention. I share knowledge but I also intentionally accumulate knowledge which makes me indispensable.
Healthy-Dress-7492@reddit
Its usually not malicious or intentional, just people overworked. Production/management needs to ensure there is time and space in the schedule for documentation and knowledge sharing and that it is encouraged and valuable for people to do.
Anconia436@reddit
I had a lead (Principal) like this. He actively discouraged documentation because it was "out of date the second it's finished". He pushed this nonsense to so many people, including management and fresh juniors. He got away with this because he was such a shit hot programmer - but that was it. Needless to say when he (and I) left, previous colleagues told me they were lost on how so many systems worked. Go figure.
Fit_Butterscotch_829@reddit
It is frustrating when you do document but then enough people decide to ask you anyway instead of following the documented process :/
At this point I prefer automation where possible. People need to be willing to read…
Vamosity-Cosmic@reddit
This is a sign that the documentation is not readily available or easy to find.
Fit_Butterscotch_829@reddit
No, it’s as good as it will ever be. You don’t know anything about my organization. Other parts of the company find and use the documentation because my docs are sadly some of the more extensive and discoverable for what I do. Some people just can’t or won’t read. Just like how some people are good at their jobs and others aren’t. The only way it would be better is if there were more staffing but that is not in the cards in the current environment.
Vamosity-Cosmic@reddit
I should've included the intended word "This is usually a sign.."
ShoePillow@reddit
If you already have documentation, then the next step is to keep sharing it.
Don't answer any question directly, point them to the relevant documentation. Ideally you should have a link to a subsection that exactly answers their query.
Once it builds momentum, or you reach some proactive people, others will start using and sharing the documentation on their own
Fit_Butterscotch_829@reddit
Can’t fix people who won’t read.
ShoePillow@reddit
Well, in my experience, we can.
We need to show them that they get faster results by looking it up from the existing documentation compared to asking someone.
It takes some time (in order of months), and the documentation should be helpful to them immediately. So if they need to hunt for what they need to do, then it is better to update the documentation so it is more direct. Direct links to subsections helps a lot with that.
I haven't tried it myself yet, but maybe a chat ai trained on your documents that can answer their questions may be helpful
YetMoreSpaceDust@reddit
Hope you're documenting the automation, though...
Fit_Butterscotch_829@reddit
For sure
Fit-Notice-1248@reddit
I was getting ready to comment this. I have setup so many useful confluence pages with all kinds of graphs/visualizations and all the knick knacks you can think.
I send out the documentation to people and when they mess up or break something, they will honestly say they didn't even read or "missed" the documentation entirely.
If they get stuck they don't even bother looking at the documentation which directly answers their questions in bold lettering on the first page, but they still need me to tell it to them. Mostly shitty coworkers but goddamn.
ricktherobotguy@reddit
I’m guilty of this, and it isn’t malicious.
Typically, it comes down to a combination of these things.
This is combined with most engineers not understanding that not all documentation is equal. Documentation rots if not actively maintained, and building rot-resistant documentation is a skill. Most “comprehensive” documentation is poorly indexed and formatted, internally inconsistent and contradictory, and wildly outdated.
annoying_cyclist@reddit
Yup. I'll write docs when I'm on a team that actually reads them and uses them, and where there's a good communal culture of ownership and maintenance of docs. Write only documentation accomplishes little for the team and takes a lot of my time and energy (as you note, good documentation takes time and skill to build), so I try to avoid writing it. It's not out of malice or a desire to create dependency, I'm just generally opposed to wasting time, and busy enough to have better uses for what time I have.
thezeno@reddit
Yes. Most of the comments focus on the hoarding / job security angle. The company care that a problem is fixed. Done. Move to the next one. Docs are something that are just never gotten around to.
drcforbin@reddit
Exactly. Day to day, people are thinking about what they have to get done today. Unless there's a concerted effort or there's culture of documentation and sufficient slack in the team, it doesn't just happen.
wyldstallionesquire@reddit
I’d add too that if people do maliciously hoard, it’s managements problem not theirs. People need to feel secure and seen. I’ve witnessed places where management is inconcistent with what they pay attention to and celebrate. It creates resentment and people feel unseen, then they feel they need to protect themselves in any way they can.
ProbablyBsPlzIgnore@reddit
I'm also guilty of this.
The thing is that once I've figured out how something works, it feels trivial and obvious and you sometimes forget it's not trivial and obvious for someone who hasn't looked at it before.
YetMoreSpaceDust@reddit
I document everything. Meticulously. I can see from wiki statistics and google doc statistics how many people read my documentation. As of today, the count is: 0.
diablo1128@reddit
This is is the answer I have experienced in my career. I never met any SWE in my 15 YOE that intentionally horded knowledge for malicious purposes. It's usually falls in to bucket 1 and 2 that is talked above above.
#3 is also on point. People only care about knowledge when they need it. I hear a lot of things because I don't mind talking to people and going to meetings. I like hearing what other parts of the project is doing and how it relates to what I do.
One time a co-worker was going to remove some functionality that works fine but nobody used and I said don't do that because Team X has plans to do Y at some point in the future and will need this feature. That co-worker companied about why didn't I tell them earlier and the truth was I didn't know you needed to know that until that second.
So in my performance review that year I got something like needs to share more information. So I started doing that and guess what that same SWE would give me a weird look and ask "Why are you telling me this?". People don't actually care until it affects them somehow.
They think that lack of information could have been prevented earlier so they don't make a decision that makes them look dumb or something. In reality you cannot cover all you bases in every situation possible and you got to learn to roll with the changes.
hiddenhare@reddit
Agreed - I've had large solo projects where I've regretted writing too much documentation for myself. Docs and comments can be a pretty big maintenance burden. Some of that effort would have been better spent keeping my short-term knowledge alive by working on the code, rather than planning for some disaster event where I get lost in the woods for five years and need to reload all of the mental context from scratch.
However, the effort does often pay for itself by forcing me to avoid sloppy architecture; if you can't describe what you're doing in prose, you're probably doing something that makes no sense. There have also been occasions where I couldn't answer questions about six-month-old code on the spot, because I skimped on the documentation and would therefore need a full day of work to put that project back into my head.
I'd recommend tuning the thoroughness of your documentation based on the stability of the information being documented (which determines its cost), and the likelihood that you're going to forget the information being documented before the next time you need it (which determines its benefit).
cobalt-jam88@reddit
The framing of 'job insecurity vs. survival strategy' assumes the person is making a conscious choice. In practice most knowledge hoarding I've seen isn't calculated - it's the natural output of an org that never created incentives for documentation and then promoted the person who 'just knows things.' You get what you measure. If on-call rotation works fine with one person fielding all the escalations, that's not their fault, that's a staffing model that tolerates it.
The contractor angle is real though. Seen it twice where a vendor eng was the only one who understood a critical pipeline config and the contract kept getting renewed because unwinding them was scarier than the renewal cost. That's not personal malice, that's rational behavior inside a broken incentive structure. What does your org's incident ownership model actually look like - is there a rotation, or does it default to whoever built it?
Olli_bear@reddit
Time, rather the lack of it
Qwertycrackers@reddit
People dont read the damn docs even if its a straight forward trimmed down one pager. So why bother? They're just going to "hop on a call" to ask about it anyway
UntestedMethod@reddit
Mixture of several factors in my experience.
In the contractor scenario, job security is a big one for sure. Unless the contract explicitly includes clauses that they must provide specific documentation, it makes sense that contractors would skip it. When it comes to contractors, the clarity and overall quality of the written and signed contract is absolutely crucial.
For the non-contractor scenario...
From the company side - Company culture failing to set a healthy precedent, failing to make clear what the expectations are, failing to provide appropriate templates or wiki/KB to hold the information, failing to allow the time to prepare and maintain the documentation.
From the individual employee side - Poor soft skills (especially written communication), lack of understanding the broader value of documentation, general laziness. I think the "competitive strategy" part definitely does happen but is perhaps not as common as some of the other factors I listed wrt to company and individuals.
randomInterest92@reddit
I try to enable my team as much as I can as that's the easiest way to scale yourself and show leadership principles. Has led me to be promoted almost every year. Year 5 currently and I'm a lead dev. Next year I am probably getting promoted to architect.
If you make systems complex for "job safety", you'll actually become a target
Ok-Region-3997@reddit
I think it is often an incentives problem more than a personality problem.
If documentation is treated like extra unpaid work, people skip it. If being the only person who knows something makes someone feel safer, they may protect that knowledge.
The best teams make sharing knowledge part of the workflow: what changed, why it changed, who it affects, and where future people can find it.
I’m building around this problem with ChangeCrab, so I’m biased, but the broader point is: knowledge should be captured while work is happening, not reconstructed later from Slack, tickets, and someone’s memory.
8lall0@reddit
Java way. Literally.
honestduane@reddit
They have bad leadership that isn't pushing back on this and they are toxic and need to be removed from the team they do it initially because they think they're going to get job security but when I see this I fire them faster.
druidgaymer@reddit
My company likes to put me on these legacy code updates where I'm the only guy updating it and there's barely any documentation to begin with...I try to add some but it's basically impossible to update these entire systems.
Entuaka@reddit
Because they want to keep the knowledge to protect their job. This is not the best way
Unfair_Long_54@reddit
I think they have an illusion of they secured their jobs. Companies are not dependent on individuals. If they don't present at work from tomorrow its not catastrophic. Other employees will just have a little harder time for a short period and things will get back to normal very soon.
6a6566663437@reddit
It’s not guaranteed, but when the manager is told to lay off 3 people, they’re less likely to pick someone with critical knowledge as one of the 3.
It won’t stop higher-level from laying off an entire team, and the manager may be willing to take the knowledge hit if you’re too much of a problem.
Entuaka@reddit
Many times during my career I worked with people that were essential for the team. Then, they left, there was a bit of panic, but it worked without big issue. Yes, back to normal very soon.
Ma1eficent@reddit
Bit of survivors bias here. I've absolutely worked for companies that lost someone vital and went out of business. And it used to be far more common, which is why companies stress the bus principle now.
mikkolukas@reddit
Unless there is a clever (but plausible) time bomb or a "we really cannot figure out what this does" blob.
eyaf1@reddit
Also because it's not my fault nobody else cared for five years and now you are in deep shit because you did not budget neither documentation nor training for other employees.
Entuaka@reddit
Any dev in a team should be able to take any task. Planning should be done to force at least a bit a teamwork for knowledge transfer.
hiddenhare@reddit
That costs a ton of engineering time, it scales
O(n^2)in the team size, it dilutes responsibility, and it trades off depth of knowledge for breadth of knowledge. I usually recommend a Sith model: two engineers share ownership of each bit of code, and one of them is allowed to have weaker knowledge than the other.NewFuturist@reddit
Look at this lucky so and so with management that thinks about these things.
eyaf1@reddit
The second someone takes more than 2 days to finish a ticket I get called lmao. I can refuse to do it but unless I have a more important task I have no excuse to do so.
CymruSober@reddit
What does the word “should” mean to you!?
cosmopoof@reddit
It's not the engineers who are to blame - but the company and the managers who have built an environment in which this type of behaviour is rewarded, either implicitely (nobody complains) or explicitely (hero culture).
Personally, I always follow the principle of treating people who show anti-social or egotistic behaviour as incompetent - so if someone doesn't share their knowledge, they go directly on a PIP.
Nosa2k@reddit
Most times it’s the unskilled people that do this cos their only leverage is Office politics
ShoePillow@reddit
I've also seen some highly competent technical people do this because they just want to work on interesting things
UnStrict_Veggie@reddit
Too much!
sudoku7@reddit
Sometimes it’s not malicious. They just aren’t good at documenting.
With contractors though, it’s almost certainly job security.
Djelimon@reddit
I've been the person assigned to reverse engineer a hostage situation. Management loved it so long as no one asked questions - things just worked, they memorized a couple diagrams, and a cell number. But there was a takeover and the new overlords weren't having with it, so I got roped in.
Personally I prefer being known as the ideas person rather than a keeper of secrets.
DerangedGecko@reddit
I've created well-structured and deep documentation for several applications and modules in my company. My coworkers look at it and go this is too much and later I'm being asked by some higher up to do the work instead.
So, I guess job security could be an answer... But mostly the company wants shit done fast and co-workers can't be arsed to read docs.
crow_thib@reddit
As an ex-engineering manager, employees gatekeeping the knowledge and not writing docs are insecure devs, and most of all non-team players, and I don't want such devs on my team.
For insecure devs, it's my job to make them feel secure and understand that documenting their work is gonna be something securing their spot more than the opposite. But for the non-team players, it's usually just a bad fit and nothing I could do would change them.
Competitive_Ride_567@reddit
Because everything needs to be done by now!!!
Ozymandias0023@reddit
Imo this isn't a failing of the individual engineer as much as the systems around them. Managers should identify and mitigate knowledge silos efficiently enough that this kind of behavior would become immediately obvious.
SocietyWonderful321@reddit
I think this is the core of it. Documentation is cultural and most places I’ve been there has been none - mostly due to lack of long term planning and willingness to prioritize
eibjj@reddit
What if it is the manager who himself who architects this dependency?
Ozymandias0023@reddit
Then the same reasoning applies until you're at the top of the org chart, at which point it would still be stupid to do this because a CEO or CTO doesn't need to hoarde information to keep their job
UnStrict_Veggie@reddit
I am an Indian, and as an Indian, telling you that some of us do this 100% for job security and we have scarcity mindset, not abundance mindset.
cargo_cultist@reddit
It’s hard to have abundance mindset when job’s are scarce
Nosa2k@reddit
You should have integrity and character. Stand for something and be consistent no matter what.
IMO. It makes you look weak and untrustworthy.
Sammolaw1985@reddit
A little sanctimonious when people are losing their jobs to drive up the price of their companies stock while making record breaking profits.
Nosa2k@reddit
I totally understand, we are all facing this in some shape or form but IMO external circumstances should not alter your character that’s the point am making.
ultimagriever@reddit
My family doesn’t eat moral fiber. My mortgage isn’t paid in strength of character. Unfortunately we’re not in 18th century France where the types screwing us would be lined up before a guillotine, so we have to do whatever is necessary to support our families
Sammolaw1985@reddit
The US has turned into a low trust society. What you describe is just not incentivized.
SnugglyCoderGuy@reddit
When those external circumstances are having food and shelter ... or not, you better believe its going to alter your decision making.
There is more than enoughbto go around if the shareholders were disposed of
UnStrict_Veggie@reddit
me? What? did you read my replies lol... I am not the tribal knowledge keeper lol
UnStrict_Veggie@reddit
try having a fixed mindset and a negative attitude in an already bad situation and see how it wrecks your mental health.
Ok_Grape_9236@reddit
European here and I know Europeans do the same 😝
MangoTamer@reddit
I'm really glad you said that last part because I was about to hate you for it.
UnStrict_Veggie@reddit
I’m a realist, and I see what happens around me. Also, FWIW: I also recently lost my job to layoffs, since all my team can function without me, because I gave them information about all the systems so that they become better at delivering tasks(I’m a tech lead) lol womp womp
PM_40@reddit
You will get another job soon.
Nosa2k@reddit
That’s a small minded behavior. One prompt to an LLM agent and it’s figured out.
UnStrict_Veggie@reddit
now! sure! but in my team, there hadn't been much documentation and everything was scattered and all the tribal knowledge was under the control of 1-2 people who'd been in the team since the beginning. We had to slowly figure out things and feed into LLMs to create meaningful information patterns.
Nofanta@reddit
They’re looking out for and prioritizing themselves. The company does the same. Unless you have significant ownership in the company, this is the smart play as an employee.
CarelessPackage1982@reddit
Closest thing to job security that exists in this business.
CharlesV_@reddit
I rely on documentation to help me remember things and why I chose to do something. Luckily a lot of the other engineers around me have done the same thing. But I still run into project Lore from 10+ years ago. Occasionally someone will actually remember the reasoning and sometimes it’s kinda funny.
doradus_novae@reddit
Because documentation is unmaintainable shit and tech moves too fast to document it.
You have to learn to keep up.
It's not my responsibility to make sure you can keep up.
poralexc@reddit
I document extensively and try to automate complex rules as much as possible to buy myself some peace and ability to work on other projects.
Yet even with diagrams, docs, comments, and recorded seminars, there's always a certain amount of bus-factor/job-security from people just refusing to look things up on their own.
fojam@reddit
"What do think of people who are like this?" "My coworker did x!" "How do you deal with a coworker who does y?"
God this sub is just people vagueposting about people they dont like now
Idea-Aggressive@reddit
I had a contract for a very popular company, and they had zero documents in a critical project I came to fix. After I fixed it, introduced documentation, and reusable processes, my contract wasn't extended; this is ok, but it was promised that they'd offer a full-time role. Suddenly, the developers who weren't able to solve the problem had opinions, etc. The project is open source, I can see what they're doing today. Found that they removed some decisions I made (during the period, they have not provided any feedback at all, but I know that they had private conversations pointing out things they didn't like between them, but only surfacing in biweekly calls instead of mentioning it immediately, so I could take their feedback into consideration. Small, pointless things, sometimes related to "descriptions"). Finding work and making money is very difficult and some people really do their best to f* other people's life. I've shared the knowledge regardless because that's the right thing to do, but be aware that others might find that as a treat and burn you down for no reason. I believe it was just one developer that was loud, just to be seen, I never put his name on the fire but I had to clean some of his work a few times, e.g. importing from "node_modules/" in js/ts projects and things like that.
alex88-@reddit
There’s literally no incentive to document well in most cases, while there is some incentive to not document.
kibblerz@reddit
My last job, my manager decided to start creating knowledge silos in a way where none of the other devs touched existing infrastructure in AWS, instead going to kinsta where they didnt even use git. I tried to push back against such decisions, but couldnt get very far, leaving a kubernetes cluster that only I had worked with significantly.
Then he fired me and it backfired massively lol
beattyml1@reddit
I don't intentionally but I am a critical point of knowledge on my team and the top reasons I don't document more are that I don't have time because everyone needs me, people keep asking me questions I already documented so it doesn't always feel worth my time specifically, and that tbh in a team where I'm a critical point and I know so many things that I can sometimes skip details it's usually better for the person I teach something to document instead from both a time and quality perspective.
PineappleLemur@reddit
It's not always intentional, it's often comes down to "no one has ever asked for it and I never really bothered to make documents or had dedicated time for it".
Some are simply too lazy to make any documents for whatever reason.
Some suck at writing documents to a meaningful degree. Nowadays with AI it doesn't hold much anymore.
But again, if their boss asks for it, yet they still refuse or do a half ass job it's a different story.
For example there's a lot of things I would like to make documents for but I know no one will read it or even know where it is when there's a need / It will probably be completely changed in X months from now / No dedicated time to make it because putting out fires is more important.
So you end up with things that are not covered.
It's less common in large companies but it comes at the price of speed. Something that would normally take a few days can easily end up a month long thing from submission to review and approval.
mikkolukas@reddit
Because they are afraid that they are nok qualified enough to get work anywhere else.
That - or SPS
Arcyvilk@reddit
I started out documenting everything extensively, trying to share as much knowledge as I could, automate processes which became too dependant on me. I still had people bombarding me with basic questions every day and refusing to refer to documentation even if I pointed it at them repeatedly. Over time I realised I get annoyed and frustrated much less if I just do everything myself instead of trying to herd cats who refuse to do the bare minimum to understand and retain knowledge.
opinionsOnPears@reddit
I’m really bad at the documentation part but AI has really helped me a lot with that.
03263@reddit
You guys get to take time off?
geon@reddit
Incompetence
ivancea@reddit
IME it's rarely malicious. It's just that we think about documenting late in the process. Late, and with low priority. And those engineers usually have a pile of work to do. So they just continue.
With seniority comes that self-responsibility to document. Eventually. It takes time and requires a mindset or process change
Oriagli@reddit
I don't think hoarding knowledge is always a strategic move for job security. Often, it’s just laziness or a feeling that no one cares enough to reward the effort.
When documentation is a manual chore, "being too busy" is the perfect excuse to ignore it. And it is a mental boost to feel "so important that the team can't manage when I'm on holiday".
The solution is to remove the friction. If you use tools to autogenerate documentation in one minute, you take the "effort" out of the equation. Knowledge sharing should be an enforced standard, not an optional burden.
authentic_developer@reddit
Job security is half of it, but the other half is that most managers reward the firefighter and never reward the person who wrote the doc that prevented the fire. Once that's the incentive, the documenter is the sucker and the hoarder is the hero.
The only fix I've seen actually work is incident retros that explicitly name both the person who saved the day and the missing doc that made the save necessary. Once "the save" stops being free PR for the hoarder, the behavior dries up surprisingly fast.
bphase@reddit
I dunno about intentional, for me it's just that writing documentation is very hard and to keep it up to date. If it's not in the definition of done, it won't get done until you move to the next task.
Often it won't be read or understood anyway, and it may have some old and irrevelant stuff while the important parts are missing. Some things are obvious for you as the builder but not so much for others and you can't really know if nobody asks.
Realistically you need to have someone take interest and ask you questions, in which case I will try my best to be of help.
Secret_Jackfruit256@reddit
Maybe it's not intentional? Some people are overloaded by the team and end up accumulating knowledge. If you sum up technical skill with bad soft skills (quite common in our field), you end up with some over worked guy who is there to patch everything but never had time or even considered documenting and making it easier for other people to help him.
So I don't think it's a single person issue, it can only happen when there's bad leadership and bad working culture around that person.
CanIhazCooKIenOw@reddit
It’s all about control
Ok_Individual_5050@reddit
This isn't something I do, but we are being constantly threatened with "we are going to lay you off and replace you with an AI" and getting Devs to unionise is like pulling teeth so I can't blame someone for wanting job security
ieatdownvotes4food@reddit
cuz theyre insecure fucking asshole cocksuckers. u know who you are.
lawrencek1992@reddit
I think people view it as job security or a hedge against AI.
Personally I feel like making things maintainable and teaching others results in job security cause I’m seen as someone who makes my team more effective. And I’m happy to make it easier for agents to help me do my job. I don’t feel like AI threatens my job, but it does make it easier to automate things.
ugh_my_@reddit
Why should I train my replacement AI?
psysharp@reddit
It comes from fear and it exists in all jobs and it is severely crippling everything, people are traumatized and vulnerable.
AHappySnowman@reddit
I’ve mostly worked in small and mid size companies. It’s not common to see a lot of documentation because there’s little incentive to make it, plus it often gets out of date quickly.
tigerlily7190@reddit
I used to not understand this at all. But after quite a few years in the corporate world, it really is dog eat dog
LowerAd4705@reddit
Some kind of job security and, in my case, I simply have no time or energy to document everything. I went through the phase of documenting a lot of stuff and in the end majority of those docs were barely needed, maybe someone used them once. So I decided not doing that until I get asked about some thing fairly regularly
niko2111@reddit
Because they are laying off x% of the company on a weekly basis so I’ll play some of my cards too while I’m at it
Ok-Hospital-5076@reddit
This is not new, but I think it’s going to happen much more often. When people are constantly told to spend time meticulously documenting every step and filling every knowledge gap so that one day their role can hopefully be replaced by a robot, it’s hard to expect them to feel motivated to close those gaps.