This reminds me of advice I got from the VP of Eng at my first real full time tech job. This was back around late 1999 / early 2000. Peak of the dot com era.
He told me what most people think of as job security is totally wrong. If you're the only person who knows something, you become a liability. But if you're constantly teaching and sharing that knowledge you become incredibly valuable to the organization. That's when you have job security.
Since internalizing that advice, I always try to work myself out of job by ensuring I share anything I know. And I always pass this advice along to others. As you get more seniority in the organization, the way to have more impact and scale is to work through others by sharing your knowledge and helping them get better.
At one of my old gigs, I asked my then-colleague a bunch of questions about the codebase for a task I was assigned. He was always like "you are a senior resource, you should not ask such questions; if you want to find answers, look into the code itself." This is how he keeps his status and job at that company, and he is still there now. When I enquired around about how he got that tribal knowledge of that codebase, I got a fascinating answer: he asked his ex-colleagues at the same company, the same kind of questions I asked.
Unless one joins as an intern at some company, there are gatekeepers in most of the companies, who don't want to train you at all. Instead, they criticize any attempt to find answers as "hand-holding, fake, inexperienced, etc."
>you are a senior resource, you should not ask such questions; if you want to find answers, look into the code itself.
You should never tell anyone they 'should not ask such questions', but I will absolutely tell you 'hey, go read this code / documentation and it will help you understand'. Mainly, I just want you to show me that you've at least attempted to solve or research the problem yourself. If you've done that I'm happy to help. Unfortunately a lot of Jrs straight out of school seem to expect to be spoon fed answers, and it makes me wonder if college has changed since I graduated.
Most work knowledge now is google deep, but even back to the 80’s I encountered a lot of college grads who did not want to read the code.
A lot of it is intimidation, they’d never seen a printout stack of 50 or 100K eslocs. Kids today never start with monolithics like that but they do get swamped by the fifty layers/packages that change every year.
Learning “on the job” is an anachronism from the days when companies invested in their employees and employees stayed in the same organization for their entire career. We’re moving towards the gig model, even calling programmers “rock stars” to sell it.
This is profoundly true. It's also one of the reasons I want to get out of IT after 20 years. I'm past the point where I'm tired of the meetings, false niceties, and desire from management to submit to the hive mind. Nothing worse than stand-ups, Teams or Google Meet meetings. No one wants to be in them. It takes time away from my job where I could actually be productive. This is why I really like the videos from Patrick Shyu on YouTube (Tech Lead). He gives the skinny on working for companies like FAANG and in general. I don't always agree with everything he says, but I've seen much of what he says.
Surprisingly a lot of folks on my past and current teams haven't figured this out yet. They still think the manager who promises them a promotion next year is going to be around by then.
> there are gatekeepers in most of the companies, who don't want to train you at all.
This is fear mongering for the juniors. Most people don't help because they don't get asked. Juniors, reach out and I will help. I'm the kind of person that is sociable and helpful anyway though.
There are plenty of people who have "closed the drawbridge behind them once inside." They don't want to help, or think that you should figure it out yourself or should already know the answer etc.... They forget that they were newbs once too.
It goes both ways,I suppose. I'm more than willing to teach anyone who is willing to listed what I know, but some mutual respect is needed. I remember a meeting, where I got asked to get someone up to speed with some core concepts. I thought,OK, that's fantastic.I prepped the plan, go to him and tell it'd take him about 20h of his own time to go through the stuff.. 'Oh no, I thought we'd be done in 2 hours'.. Sure, I can teach you in 2 hours what took me 5 years to learn..
It depends. Sometimes the answer is obscure because of our setup - like you'd need to know to look in the other repo. I'll always tell you that, and point you to the doc and the problem-list to update in case the doc is wrong.
But, if you ask me a question where the answer is in the code, the proper answer you seek, in the detail you need, then I'm going to ask you to read the code first and only ask me what's left.
Perhaps the story is true as retold, or maybe the original guy asked about the right things and read the code for the rest, but people watching from the outside couldn't tell and conflated it all, turning it into a story of ladder-pulling bitterness.
That doesn't really ring true for me because I want coworkers taking responsibility for these odd systems (that they have to find me to ask about). But I don't want to be stuck in the role of their System-X guy who they get to do their changes. This guy's incentive would be to walk the line, educate and hand-off.
>He told me what most people think of as job security is totally wrong. If you're the only person who knows something, you become a liability. But if you're constantly teaching and sharing that knowledge you become incredibly valuable to the organization. That's when you have job security.
Sounds like the VP of engineering was doing his job quite well. Set up new hires to share everything so when their salary becomes a burden you can "sadly let them go" when "necessary downsizing" occurs because they've given away the farm.
Don't get me wrong, I spend a ton of time mentoring those around me, but there's no planet on which I would give a document dump of my personal notes, ever.
Aviation engineers guard their shit and embed themselves like ticks. Access databases, spreadsheets, Fortran (like old ass fortran spaghetti code), servers under the desk. All this was common at GE.
They know what happens when you don't hold the company hostage. Nearly all of them retire and then "consult."
Any personal notes are, by their very nature, shorn of the full context you have. They are always data, sometimes information, but never knowledge.
I once left a job where I had taken pains to document everything, to regularly teach what I'd worked on, and to help everyone, even beyond strict software functions, familiarize themselves with the systems in play as needed.
Were they glad I was relieving them of the cost of my salary? No, they were mournful. I would not be there to continue to draw connections between disparate items and serve as a voice of organizational experience. No amount of notes would replace my ability to, mid-meeting, say "That won't work" and explain why. Someone who had invested real time in internalizing those notes might -- might -- get there, but it would be difficult.
> If you're the only person who knows something, you become a liability.
Sorry, this is just wrong. You are a liability if someone thinks about you that way. Fortunately, not that many people are like that. In Contrary, if you are the only one to know something then you are regarded very highly and almost untouchable.
If you know something no one else does... sometimes the management is kinda aware that it's a problem, but they are too busy doing something else, so you can keep your job for decades with minimum work.
And sometimes you know something no one else does, and you want to share the knowledge, but management says no, because having you talk to someone else feels like a loss of time when both of you could be developing a new functionality instead... and then one day you leave, no one reads the documentation you wrote, and your successor ends up reimplementing from scratch everything you already did.
Sometimes it seems to me that the perception of your importance is proportional to the number of bugs in your code. If things keep breaking and you keep fixing them, you are a hero, and the company wants to keep you. If things work flawlessly, company assumes that it is easy and that you could be replaced at any moment by a random person who walks in.
It depends quite a bit on what it is you know, and what it pertains to, and how problematic it is.
If you guard the knowledge to the core application for how the company makes it's money, you're not going anywhere.
If you guard the knowledge to a component used in that core application, which while it's problematic to replace could be swapped out with a lot of effort, you are going to be walking a tightrope. As soon as it becomes more beneficial to replace that component than keep dealing with the problem of it being hard to deal with (because if it wasn't your knowledge would have little value), you're faced with the fact that a large chunk of your value to the company has just been obsoleted with it.
So when taking the hoarding info approach, just how irreplaceable is the thing you're guarding knowledge of? Often it's far more replaceable than people think, and often becomes more so as people hoard knowledge of how to deal with it. Unless you're that guy that's on call 24/7 to immediately deal with a problem, the fact that it all relies on you which is unsustainable will eventually come to light.
If you're the only person who knows something it can also mean you end up in a rut. You can't tackle interesting new stuff because you're stuck looking after the old stuff that no-one else understands.
When I assumed my current position,the first thing I told the owners of the business is that the biggest risk in the business is me and that the company should work towards getting someone in, who could partially cover some aspects of my job. They understood it well,but probably not too well, however some attempts were made to address the issue.
Can I ask why did you do that? Was it so you could divide & delegate your work to underlings? Or was it so you could be totally free from the position one day?
The position I assumed is pretty senior- I report directly to the CEO. As part of the change,I still retained some of my previous responsibilities+ gained a whole lot more.
I did it for two reasons:
1) it was the right thing to do,considering the situation. My approach is always to be open about issues within the business, even if it's my own department. This isn't university liked by my colleagues but appreciated by the CEO, as he knows I'll tell the real situation rather than that with a pink filter.
2) I will move on, sooner or later, and I'd rather have someone in place before that happens. I want the company to be successful in the same way as they've given me tons of opportunities that I successfully used.
3) There's a considerable backlog of things I need to do at any given time,so having more resources would free up my day+ speedup certain developments in the business.
I'm in this boat right now-ish. I don't want to be the person who only knows somemthing. I'd rather delegate it and then if I get sick I know someone else can cover the work needed to get the job done.
I just recently had my first junior developer assigned to me. Learning how to mentor, teach, as opposed to just getting a task done is harder than I imagined
> Learning how to mentor, teach, as opposed to just getting a task done is harder than I imagined
I've had the good fortune to inhabit a mentoring position twice in my professional career. Both have afforded me opportunities to teach new people as each business expands.
I find mentoring incredibly rewarding. But I also naturally enjoy spreading knowledge (I considered a career change to teach history at the university level, but didn't want to pursue the academic credentials). It's not just teaching the tech that's rewarding. I also enjoy sharing time management techniques, tips for writing solid documentation, and pointing out how to avoid gotchas that I've run into in my personal experience.
What I absolutely don't want is to join the ranks of management. A buddy recently moved up and he now spends almost all of his time in meetings. When he isn't in meetings, he's responding to the many people who need his attention for one thing or another. I wouldn't find that the least bit fulfilling.
This is what strikes me as tone-deaf about the grandparent comment with regard to "loving your job." I love my job because it pays well enough, I like the people I work with, and it doesn't intrude into my "real life." I hated my former employment, where ambition was a thing, because it dominated my life. It paid far better, but I was unhappy overall. What I have strikes the right balance, and that's rare enough that I treasure it.
Yeah, and it's particularly hard when you're still ultimately responsible for the result, but others are doing the work. That certainly brings some amount of stress. But also the money gets bigger and bigger.
> Sharing knowledge in the business world, never. That's a great way to lose a job.
If you're working at a functional organization that rewards growth, never sharing knowledge will ensure you put quite a low ceiling on your advancement.
I've written countless promotion justifications. Been on countless promotion review boards at several very successful tech companies. Being the best programmer, or what ever, is only going to get you so far. Advancement comes from teaching and leading others. You do that by sharing knowledge.
There was a broad HN discussion about this here on HN late last year [1].
And the top comment [2] is worth repeating here
Here's some of my learnings about getting promoted for those that really want to play that game:
- Only the perception of your work matters
- Attend the social events and get in good with the bosses
- The countability of your major achievements is important. Make the list long, too long to hold in the mind
- At the same time the gravitas of your best achievement is also important since that will be the soundbite that is shared about you behind your back
- Get allies who can proselytize about you behind your back
- Be the best. The difference between one and two is bigger than that between two and three, as far as promotions go
- Take credit for your work (use pronouns I and Me when talking about your work, not We) and do not allow others to take credit for your work
- If it's a teamwork situation with other people on your level, don't do most of the work, because the credit will end up being split 50/50 in the eyes of the bosses even if you did most of it
- Make a very good first impression
- Shape the narrative around the role you played in the success of the mission/team/company
- Get the bosses to make a soft public commitment regarding your competence
- Even if you have a really good boss, all of the above is still important, because they are fallible humans and aren't omniscient
- Actually do good work, it'll make the above easier
I can attest to that 100%. I work at a medium-sized startup, but we've got leadership from Youtube, Facebook, Amazon, and MSFT so I think it's pretty universal.
You can progress to a pretty decent level and pay as "the best programmer" up until a high senior role, which most talented folks hit after about 8 yrs of experience. After that, promotions start to depend on the extent to which you influence the direction of your group or even company, which is all about teaching and leading others.
I think of it as three stages:
* Learning: you may be good at completing well-defined work, but you generally need a mentor to guide and help you. in other words, the company at this point is investing in your growth.
* Building: you are now self-directed and able to work independently, capable of being assigned a possibly ambiguous product requirement and being able to solve it yourself.
* Leading: you are now at the point where you can be given a large, complex project with possibly ambiguous requirements and trusted to deliver. you can work with management to form a team, and can design the technical / architectural approach and break it down into smaller pieces which you can delegate to the rest of the team.
And once you hit "leading", it will grow in scope.
"Sharing knowledge in the business world, never. That's a great way to lose a job."
I think that depends on the role and the organization.
Generally organizations do not like to loose valued individual contributors unless the organization is somehow pathological (I know those exists).
A programmer that delivers value is always worth more than his or her paycheck. If you can dump his load to a more junior dev then that's great, there are other, more important things always that need doing. That is, if the business is growing.
The delta comes from my incredible work experiences / organization management in the Marines and then working for selfish and incompetent bosses in the civilian side. (I have had bad luck on the civilian side in the past.)
I agree if an employee needs to fight for leverage over their manager then hiding your notes is as good way to do that as any. But if you need to use this tactic it's a clear sign the workplace is not healthy.
So, instead of as general advice "never show your notes" - I would rise to a level above - first in good faith, but in a defensive posture observe if your employer rewards co-operation or selfishness - and then choose your tactic accordingly.
Falling under incompetent management is a double injury - the incompetence is both professionally reprehensive and being managed incompetently just hurts.
I'm sorry you've had this experience on the corporate side.
I see in one of your other comments that you work for yourself now, so this unsolicited advice probably doesn't apply to you. But I'll leave it here anyway.
I've had plenty of candidates ask me how I or the company help employees grow, and what it takes to advance.
I typically see this as a good sign and I explain the career ladder, explain how promotions work. Explain how I would help in their growth.
If they don't have good answers for this, it's quite a red flag.
You can also ask about collaboration and what kind of work is rewarded.
If you're a leader at an organization, it's important to make people feel like it's a positive thing to make the company need you less for a particular task.
At our company, we've had situations where employees automated themselves away or found somebody else to replace themselves. In response, gave them raises and helped fill their extra time with more interesting higher impact work.
I've encountered a totally different school of thought on job security in the early 2000s after the fall of the dot com era. Many jobs were cut. "Outsourcing" became a dirty word.
My good friend got a year-long internship in banking industry in early 2000s. When I asked him how the real world worked, he was taught to hoard as much knowledge as he possibly could and not share it. Sharing knowledge means someone could do his exact job. He had no desire to learn new skills. He worked with folks who had been with the organization for 20+ years and that's how the workplace worked. He and his colleagues were so afraid that their job would be outsourced.
We are not friends anymore. I bet he still works for the same organization. He may not be wrong about hoarding the knowledge and working in a slower pace industry: Doing so could be an easy ticket to gain job security for life.
Agree! Bringing up those around you is the real way to be seen as a 10Xer. The alternative story of one hacker solving all of the business's problems on their own is a fairy tale.
The very words "job security" are a lie and have been for decades. Unless you have a contract that grantees you pay for a number of years. Which 99.99999999999999% of W-2 do not have.
He told me what most people think of as job security is totally wrong. If you're the only person who knows something, you become a liability. But if you're constantly teaching and sharing that knowledge you become incredibly valuable to the organization. That's when you have job security.
Since internalizing that advice, I always try to work myself out of job by ensuring I share anything I know. And I always pass this advice along to others. As you get more seniority in the organization, the way to have more impact and scale is to work through others by sharing your knowledge and helping them get better.