This is advocating that you always be a disposable commodity within a labor marker. A repackaging of the “free labour” idea from liberalism - that wage labour frees the worker to engage in any contract as they please. But the reality of being an exchangeable commodity is rather different.
You can still be indispensable through your unique contribution and areas of focus that others would not have pioneered. By making it easy for people to follow in your footsteps and take over from you, you are influential, you change the way things work, and people notice that. When it’s for the organization’s betterment they appreciate it too. :)
I don’t want to be indispensable in the sense of a bus factor. I do want to be indispensable in the sense of “Wow, it’s a good thing /u/kevinc works here.”
That’s perfectly reasonable, but in order for it to work, there has to be a company at the other end that needs, values, and can recognize innovation and unique contribution. All companies claim they do because you don’t want to project a boring software sweatshop image, but realistically, many of them don’t. Only a pretty small fraction of today’s computer industry checks out the “needs” part, and you still got two boxes to go. For many, if not most people in our field, making yourself indispensable in the sense of a bus factor is an unfortunate but perfectly valid – in fact, often the only – career choice that their geography and/or employment allows for.
Well technically we’re all bus-replacable. Some of us have enough experience and/or good-will built up in the company that if you actually do what the article proposes, you actually won’t be easily replacable even if you make yourself “replacable”. It’ll be either too expensive for the company to find and train your replacements, or they’ll lose on the value you’re bringing.
What the article doesn’t mention, though, is that you can’t do any of that stuff if you’re a green junior dev. It’s easy to find a job when you’re good at it and you can prove it, but just getting kicked out on the street while I was still young in the industry would scare me shitless.
I agree you want to find a workplace that does value you, and even if you do find that, you have to watch for the organization changing out from under you. Just, on your way there, you can earn some great referrals by giving what you know instead of hoarding it.
As an engineer, is it valid to make yourself a wrench in the works entrusted to you? I think no. But to your point, you’re a person first and an engineer second. If survival is on the line, it’s another story.
Just, on your way there, you can earn some great referrals by giving what you know instead of hoarding it.
I absolutely agree that it is invalid to make yourself a wrench in the works entrusted to you, but computer stuff is absolutely secondary to many companies out there.
Note: I edited my comment because, in spite of my clever efforts at anonymising things, I’m preeeetty sure they can still be traced to the companies in question. I’ll just leave the gist of it: so far, my thing (documentation) has not earned me any referrals. It has, however, earned me several Very Serious Talks with managers, and HR got involved in one of them, too.
I know, and continue to firmly believe (just like you, I think) that good work trumps everything else, but I did learn a valuable lesson (after several tries, of course): never underestimate good work’s potential to embarrass people, or to make things worse for a company that’s in the business of selling something other than good work.
I think this is a bit unfair. I’ve worked with people who have hidden information and jealously guarded their position in a company and it makes it harder to do your job. You have to dance around all sorts politics and all changes are viewed with suspicion. You have to learn what any given person is protecting in order to get what you need to do your job. You hear stories about people getting bribed to do their jobs. People won’t tell you how to do things, but will do them so they are unreplaceable. People build systems with the eye towards capturing other parts of the organization.
Most of that would go away if people did what was described in the article.
I don’t know if I agree with you in this specific case. It was at a place that never fired anyone. People who were not capable of doing their jobs were kept for years. It seemed to be more predicated on face saving, inter team rivalry and competition for budget.
Yes, I had the same thought as you. It’s true that “if you can’t be replaced, you can’t be promoted”, but since when are people promoted anymore? The outlook of this article is that job security is not something you can always take for granted; indeed, that you can take upward (or at least lateral) mobility for granted. Maybe that’s true for highly-marketable (white, cis-male, young, able-bodied) developers in certain urban areas, but at my age, I wouldn’t want to count on it.
Being a disposable commodity doesn’t necessarily imply low value. You can do something that is highly uniform and fungible, and also well compensated, I think.
you think wrong. Historically “deskilling” (this is the term for when a worker becomes standardized and easily replaceable) corresponds to salaries going down. This happens for a variety of reasons: you cannot complain, you cannot unionize easily, you cannot negotiate your salary. You get the money you get just because your employer has no mean to find somebody that can do exactly the same and get paid less. If that becomes possible and you don’t have rights that protect (minimum wage, collective agreements, industry-wide agreements) or collective organizations that can protect you, the salaries go down. Fighting deskilling is not necessarily the most efficient strategy and doesn’t have to be the only one, but for sure giving up on that is no good.
On top of that, deskilling is coupled with more alienation, less commitment and in general a much worse working experience, because you know you don’t make a difference. You become less human and more machine.
Programming, I believe, naturally fights against deskilling because what can be standardized and therefore automated will eventually be automated. But the industry is capable of generating new (often pointless) jobs on top of these new layers of automation of tasks that before were done manually. Actively pursuing deskilling is unreasonable also from an efficiency point of view, because the same problem of “scale” is already solved by our own discipline. The same is not true for most other professions: a skilled factory worker cannot build the machine he’s using or improve it (with rare exceptions). A programmer can and will if necessary. Deskilling means employing people that will only execute and not be able to control the process or the organization, leaving that privilege and responsibility to managers.
it says explicitely to try to be disposable. Disposability and deskilling are equivalent. The term, in the labor context, is not just used to say “this job should require less skill to be done”. It’s used for any factor that makes you disposable or not, regardless of the level of skill involved. Clearly skill plays a relevant role in the vast majority of the cases. What he’s advocating is to surrender any knowledge of the company, the platform and so on, so that you can be easily replaced by somebody that doesn’t have that knowledge. You’re supposed to put in extra effort deliberately (not on request from your boss and maybe often going against company’s practices) to make this process more frictionless from your employer. That’s what the article is saying
While it does say that, I think that the actual meaning of the article is “make the work you do disposable”, not “make yourself disposable”. That way you can go through life making changes that make it easier for everyone around but also highly profitable for the company so that while the work that you currently are doing can be done by whomever, the potential value you bring at each new thing you do is incalculable. So they’d keep you, of course.
What he’s advocating is to surrender any knowledge of the company, the platform and so on, so that you can be easily replaced by somebody that doesn’t have that knowledge.
Are you suggesting that the replacement will not have that knowledge, or will at the moment of replacement have gained that knowledge?
Disposability and deskilling are equivalent.
This is not the case in my mental vocabulary, and I don’t think it is the case in the article linked. Disposability is about upskilling as a team, becoming more engaged in craft, and having a community of practice, so that the community doesn’t rely on a single member to continue to upskill/self-improve.
While I agree that deskilling is a thing, it might be more something that affects blue collar workers working on an assembly line than IT professionals (to an extent). Replacing someone isn’t just firing the more expensive person and hiring a cheaper one. It involves onboarding and training, which may take several months, which directly translates to lost earnings.
It happened to plenty of cognitive workers throughout the work. Deskilling is also replacing accountants, fraud analysts or many other professions with ML models that live on the work of data labelers somewhere in Pakistan.
It could also have been written by someone who had the experience of being too irreplaceable, i.e. they wanted to move on from a job, but the company was too dependent on them.
and what he’s keeping him there? Giving some notice is professionalism, staying years is probably a symptom of unhealthy employer/employee relationship and should be addressed through other means.
…they wanted to move on from a job, but the company was too dependent on them.
Honest question, so what? At-will employment goes both ways: if you want to leave, then leave. I would never intentionally screw someone over, but I would also never feel I couldn’t leave if I really wanted to. That just seems crazy. A company is not a family and employment is not a lifelong bond.
I think, in most of the cases you’d be right. But there are cases where you wouldn’t want to leave the company in trouble. If you create a situation that the situation breaks down without you, that doesn’t imply that the company was actualy bad.
So now you want to leave to a new job, but you know if you leave, you’ll leave fire and hell on your tails, and all your friends, colleagues, and the company that treated you nicely (most of us here are) and all of them are left to deal with the problems you’ve now created. There are companies where I left where doing that would not make me sorry, but there were also places where I sincerely didn’t want to leave all the people in a mess.
I like most of this advice. This advice is fundamentally collectivist in nature, since the goal is to strengthen the whole by making the parts interchangeable. It’s symbiotic, though: if everyone works in a way that works well with the collective, you’re all better able to assist one another. If you need to take time off for any reason, it’s much easier to do so when your team can operate successfully in your absence. I like knowing that when I go on vacation, I can ignore all work comms for that time period without anxiety.
It wasn’t always that way. Earlier in my career I ran a system where I was the expert, and I had no real peers. I liked being the expert and being needed, it made me feel validated and important. The problem was that I found that it was difficult for me to step away, because any questions that people had with the system had to be addressed to me.
If you’re an even modestly-capable programmer, the vast majority of the time your job will go out of their way to keep you, because hiring is expensive, time consuming, and difficult. Nobody wants to need more programmers. The various comments suggesting that the advice in here is somehow duplicitous seem odd to me; the person described in this post is a person that I think I would want on my team, because they’re actively doing the labor to ensure that the other people on their team are equipped for success.
Identify and train your replacement. In the same vein as training others, to switch roles you’ll need to replace yourself. Identify who that replacement might be and actively and continuously coach them.
I think it’s great to provide training to people around you, and (if they’re interested) then enable people to gain the skills that could be used to replace you, but actively targeting someone as a replacement and treating them that way all the time seems unhealthy.
Do not make yourself the point of contact. Establish mailing lists or other forms of communication that can accommodate other people, and then grow those groups. (The exception is when management needs names for accountability.)
In general I agree that it’s unwise to volunteer as the contact for too many things, and it’s preferable to use open channels of communication. But as a blanket rule I don’t think it’s good advice.
I think it’s great to provide training to people around you, and (if they’re interested) then enable people to gain the skills that could be used to replace you, but actively targeting someone as a replacement and treating them that way all the time seems unhealthy.
I agree.
In general I agree that it’s unwise to volunteer as the contact for too many things, and it’s preferable to use open channels of communication. But as a blanket rule I don’t think it’s good advice.
When I read that my first thought was instead of having people coming to me about the internal lib I’ve made - make a Slack channel for the lib support.
When I read that my first thought was instead of having people coming to me about the internal lib I’ve made - make a Slack channel for the lib support.
Yeah! This seems like a good idea. Keeping communication open and transparent has tons of other benefits: you’re not the single point of failure, other people can find out context around a situation, it fosters a sense of community, people are less likely to become the defacto decision-maker, etc etc.
It’s just that having a rule of “I won’t be point of contact unless management specifically ask me to be” feels like a bad attitude to have.
IMHO, if your management asks you to be the point of contact, they may not be good management. Volunteer to set up the group channels of communication, and have a good attitude about it! The problem with being a point of contact is that you can’t go on vacation, etc, without handing off the baton. The handing of the baton creates overhead for the team. Overhead creates drag, which makes the team less effective. I am in the middle of leaving my current position, and I try to follow most of the rules in the the linked article. The things that are painful, are the places where those rules were not followed. Also, it’s my understanding that if you ever have to do ISO27001, it will help to have responsibilities delegated to roles instead of individual points-of-contact.
This has been my work philosophy since I started and I’ve been at the same job for four years now with no plans of actually leaving (but still leaving my knowledge behind to avoid the pesky silos)
No employer ever really treats an employee as indispensible. The industry usually has the opposite problem (no one stays long and no employer incentivizes them to do so, meaning no system experts and high churn)
no one stays long and no employer incentivizes them to do so
I wouldn’t say that for the whole industry. At least among big tech companies, it’s pretty common for some chunk of your compensation to be paid in stock, which vests over time as long as you remain at the company. At Microsoft, for example, your annual bonus contains a cash and a stock portion. As you go up in seniority, the ratio of stock to cash increases significantly. The stock vests in 3-month intervals over a five-year period. If the stock price keeps going up, this means that the stock from older bonuses is worth more than the stock from newer ones. That gives a pretty strong incentive to stay.
Of course, the flip side of this is that the same companies also offer signing bonuses that provide an equally large incentive to move…
If the stock price keeps going up, this means that the stock from older bonuses is worth more than the stock from newer ones. That gives a pretty strong incentive to stay.
I find the opposite to be true. The old bonuses being worth more gives the perception that my compensation is trending down over time and gives me less reason to stay after my bigger vests have completed.
“The way of the Samurai is cloaked in death. The natural way of a Samurai is to consider himself as already dead. By setting his heart right every morning and every evening his resolve will be firm, if one will do it it, it can be done. With this he gains freedom in the way, his whole life will be without blame and he will succeed in his calling.”
Making yourself irreplaceable by building a system only you know how to service and run might seem like a good short term career strategy but it locks you into a role that you can not be promoted out of. As the system ages it might start to get deprecated and you become obsolete with it
2
By ensuring other people can run the system you become useful to many people. The more people you are useful to the more truly valuable you are. This is good for your own wellbeing, the wellbeing of your teammates, the product and the company. This leads to more prospects for being given more responsibility and career advancement.
3
Good documentation is a key to Pt 2. The reach of your work becomes greater if random people can see and use what you build, add to and expand it.
The title is clickbaity, but the substance sets a good bar for maturity in a software engineer. I have encountered engineers who hoarded information and essential tools, thereby holding their employer hostage and inducing varying degrees of paralysis upon their departure. To work with such people is to suffer. To clean up after them is despair.
This is close to how I think about work in general. Partly because I realize that I am finitie and that many will come after me who will likely have to work on or indirectly use the things I work on. By making it easier to replace me in my role I view it as making it easier for the next generation. The idea of making myself irreplaceable feels very selfish to me, as I’m going to be replaced some day by some one whether I like it or not.
I don’t think this goal is attainable for a programmer, especially one that’s doing a good job working on a non-cookie-cutter project. Over time, a good programmer learns the business domain almost as good as the users they’re serving and they simultaneously learn the ins and outs of the existing code base and how the components map to the business concepts. The longer you work on a project, the more your brain will morph into a machine that’s streamlined to solve problems in your domain by changing the existing system. That kind of domain-brain-system adaptation is impossible to transfer between people, so a company loses a huge chunk of its soul (and competitive advantage) when a dedicated and experienced developer leaves.
This is true! But also not. There’s lots of stuff that isn’t domain knowledge that is nonetheless necessary to work on a project. For example, I’ve seen an undocumented release process used to protect a fiefdom. A mature engineer would at least document the process, or preferably automate it.
This is advocating that you always be a disposable commodity within a labor marker. A repackaging of the “free labour” idea from liberalism - that wage labour frees the worker to engage in any contract as they please. But the reality of being an exchangeable commodity is rather different.
You can still be indispensable through your unique contribution and areas of focus that others would not have pioneered. By making it easy for people to follow in your footsteps and take over from you, you are influential, you change the way things work, and people notice that. When it’s for the organization’s betterment they appreciate it too. :)
I don’t want to be indispensable in the sense of a bus factor. I do want to be indispensable in the sense of “Wow, it’s a good thing /u/kevinc works here.”
That’s perfectly reasonable, but in order for it to work, there has to be a company at the other end that needs, values, and can recognize innovation and unique contribution. All companies claim they do because you don’t want to project a boring software sweatshop image, but realistically, many of them don’t. Only a pretty small fraction of today’s computer industry checks out the “needs” part, and you still got two boxes to go. For many, if not most people in our field, making yourself indispensable in the sense of a bus factor is an unfortunate but perfectly valid – in fact, often the only – career choice that their geography and/or employment allows for.
Well technically we’re all bus-replacable. Some of us have enough experience and/or good-will built up in the company that if you actually do what the article proposes, you actually won’t be easily replacable even if you make yourself “replacable”. It’ll be either too expensive for the company to find and train your replacements, or they’ll lose on the value you’re bringing.
What the article doesn’t mention, though, is that you can’t do any of that stuff if you’re a green junior dev. It’s easy to find a job when you’re good at it and you can prove it, but just getting kicked out on the street while I was still young in the industry would scare me shitless.
I agree you want to find a workplace that does value you, and even if you do find that, you have to watch for the organization changing out from under you. Just, on your way there, you can earn some great referrals by giving what you know instead of hoarding it.
As an engineer, is it valid to make yourself a wrench in the works entrusted to you? I think no. But to your point, you’re a person first and an engineer second. If survival is on the line, it’s another story.
I absolutely agree that it is invalid to make yourself a wrench in the works entrusted to you, but computer stuff is absolutely secondary to many companies out there.
Note: I edited my comment because, in spite of my clever efforts at anonymising things, I’m preeeetty sure they can still be traced to the companies in question. I’ll just leave the gist of it: so far, my thing (documentation) has not earned me any referrals. It has, however, earned me several Very Serious Talks with managers, and HR got involved in one of them, too.
I know, and continue to firmly believe (just like you, I think) that good work trumps everything else, but I did learn a valuable lesson (after several tries, of course): never underestimate good work’s potential to embarrass people, or to make things worse for a company that’s in the business of selling something other than good work.
I think this is a bit unfair. I’ve worked with people who have hidden information and jealously guarded their position in a company and it makes it harder to do your job. You have to dance around all sorts politics and all changes are viewed with suspicion. You have to learn what any given person is protecting in order to get what you need to do your job. You hear stories about people getting bribed to do their jobs. People won’t tell you how to do things, but will do them so they are unreplaceable. People build systems with the eye towards capturing other parts of the organization.
Most of that would go away if people did what was described in the article.
Maybe if IT workers had a better way of protecting their job security – such as a union – there wouldn’t be the motivation to do this kind of thing.
(Note: I don’t do this kind of thing, but I totally understand why someone would, and worker solidarity prevents me from criticizing them for it.)
I don’t know if I agree with you in this specific case. It was at a place that never fired anyone. People who were not capable of doing their jobs were kept for years. It seemed to be more predicated on face saving, inter team rivalry and competition for budget.
Yes, I had the same thought as you. It’s true that “if you can’t be replaced, you can’t be promoted”, but since when are people promoted anymore? The outlook of this article is that job security is not something you can always take for granted; indeed, that you can take upward (or at least lateral) mobility for granted. Maybe that’s true for highly-marketable (white, cis-male, young, able-bodied) developers in certain urban areas, but at my age, I wouldn’t want to count on it.
Being a disposable commodity doesn’t necessarily imply low value. You can do something that is highly uniform and fungible, and also well compensated, I think.
you think wrong. Historically “deskilling” (this is the term for when a worker becomes standardized and easily replaceable) corresponds to salaries going down. This happens for a variety of reasons: you cannot complain, you cannot unionize easily, you cannot negotiate your salary. You get the money you get just because your employer has no mean to find somebody that can do exactly the same and get paid less. If that becomes possible and you don’t have rights that protect (minimum wage, collective agreements, industry-wide agreements) or collective organizations that can protect you, the salaries go down. Fighting deskilling is not necessarily the most efficient strategy and doesn’t have to be the only one, but for sure giving up on that is no good.
On top of that, deskilling is coupled with more alienation, less commitment and in general a much worse working experience, because you know you don’t make a difference. You become less human and more machine.
Programming, I believe, naturally fights against deskilling because what can be standardized and therefore automated will eventually be automated. But the industry is capable of generating new (often pointless) jobs on top of these new layers of automation of tasks that before were done manually. Actively pursuing deskilling is unreasonable also from an efficiency point of view, because the same problem of “scale” is already solved by our own discipline. The same is not true for most other professions: a skilled factory worker cannot build the machine he’s using or improve it (with rare exceptions). A programmer can and will if necessary. Deskilling means employing people that will only execute and not be able to control the process or the organization, leaving that privilege and responsibility to managers.
the article is not about deskilling, it’s about communicating your work with your peers. Those are very different things.
it says explicitely to try to be disposable. Disposability and deskilling are equivalent. The term, in the labor context, is not just used to say “this job should require less skill to be done”. It’s used for any factor that makes you disposable or not, regardless of the level of skill involved. Clearly skill plays a relevant role in the vast majority of the cases. What he’s advocating is to surrender any knowledge of the company, the platform and so on, so that you can be easily replaced by somebody that doesn’t have that knowledge. You’re supposed to put in extra effort deliberately (not on request from your boss and maybe often going against company’s practices) to make this process more frictionless from your employer. That’s what the article is saying
While it does say that, I think that the actual meaning of the article is “make the work you do disposable”, not “make yourself disposable”. That way you can go through life making changes that make it easier for everyone around but also highly profitable for the company so that while the work that you currently are doing can be done by whomever, the potential value you bring at each new thing you do is incalculable. So they’d keep you, of course.
Are you suggesting that the replacement will not have that knowledge, or will at the moment of replacement have gained that knowledge?
This is not the case in my mental vocabulary, and I don’t think it is the case in the article linked. Disposability is about upskilling as a team, becoming more engaged in craft, and having a community of practice, so that the community doesn’t rely on a single member to continue to upskill/self-improve.
While I agree that deskilling is a thing, it might be more something that affects blue collar workers working on an assembly line than IT professionals (to an extent). Replacing someone isn’t just firing the more expensive person and hiring a cheaper one. It involves onboarding and training, which may take several months, which directly translates to lost earnings.
It happened to plenty of cognitive workers throughout the work. Deskilling is also replacing accountants, fraud analysts or many other professions with ML models that live on the work of data labelers somewhere in Pakistan.
Tbh this reads as if its written by a company owner who wants their employees to be very disposable.
You wish. More likely it’s written by an employee that internalized his disposability so much that he thinks it’s efficiency
It could also have been written by someone who had the experience of being too irreplaceable, i.e. they wanted to move on from a job, but the company was too dependent on them.
and what he’s keeping him there? Giving some notice is professionalism, staying years is probably a symptom of unhealthy employer/employee relationship and should be addressed through other means.
Honest question, so what? At-will employment goes both ways: if you want to leave, then leave. I would never intentionally screw someone over, but I would also never feel I couldn’t leave if I really wanted to. That just seems crazy. A company is not a family and employment is not a lifelong bond.
I think, in most of the cases you’d be right. But there are cases where you wouldn’t want to leave the company in trouble. If you create a situation that the situation breaks down without you, that doesn’t imply that the company was actualy bad.
So now you want to leave to a new job, but you know if you leave, you’ll leave fire and hell on your tails, and all your friends, colleagues, and the company that treated you nicely (most of us here are) and all of them are left to deal with the problems you’ve now created. There are companies where I left where doing that would not make me sorry, but there were also places where I sincerely didn’t want to leave all the people in a mess.
I like most of this advice. This advice is fundamentally collectivist in nature, since the goal is to strengthen the whole by making the parts interchangeable. It’s symbiotic, though: if everyone works in a way that works well with the collective, you’re all better able to assist one another. If you need to take time off for any reason, it’s much easier to do so when your team can operate successfully in your absence. I like knowing that when I go on vacation, I can ignore all work comms for that time period without anxiety.
It wasn’t always that way. Earlier in my career I ran a system where I was the expert, and I had no real peers. I liked being the expert and being needed, it made me feel validated and important. The problem was that I found that it was difficult for me to step away, because any questions that people had with the system had to be addressed to me.
If you’re an even modestly-capable programmer, the vast majority of the time your job will go out of their way to keep you, because hiring is expensive, time consuming, and difficult. Nobody wants to need more programmers. The various comments suggesting that the advice in here is somehow duplicitous seem odd to me; the person described in this post is a person that I think I would want on my team, because they’re actively doing the labor to ensure that the other people on their team are equipped for success.
Can’t we just do all those good things, without getting into the mindset that we might quit or be fired at any time?
(I don’t think they’re all good things actually, but, in general most points are sensible.)
“this will make you a better engineer” - maybe, but I don’t think it’s very healthy.
Which ones are not sitting right with you?
I think it’s great to provide training to people around you, and (if they’re interested) then enable people to gain the skills that could be used to replace you, but actively targeting someone as a replacement and treating them that way all the time seems unhealthy.
In general I agree that it’s unwise to volunteer as the contact for too many things, and it’s preferable to use open channels of communication. But as a blanket rule I don’t think it’s good advice.
I agree.
When I read that my first thought was instead of having people coming to me about the internal lib I’ve made - make a Slack channel for the lib support.
Yeah! This seems like a good idea. Keeping communication open and transparent has tons of other benefits: you’re not the single point of failure, other people can find out context around a situation, it fosters a sense of community, people are less likely to become the defacto decision-maker, etc etc.
It’s just that having a rule of “I won’t be point of contact unless management specifically ask me to be” feels like a bad attitude to have.
IMHO, if your management asks you to be the point of contact, they may not be good management. Volunteer to set up the group channels of communication, and have a good attitude about it! The problem with being a point of contact is that you can’t go on vacation, etc, without handing off the baton. The handing of the baton creates overhead for the team. Overhead creates drag, which makes the team less effective. I am in the middle of leaving my current position, and I try to follow most of the rules in the the linked article. The things that are painful, are the places where those rules were not followed. Also, it’s my understanding that if you ever have to do ISO27001, it will help to have responsibilities delegated to roles instead of individual points-of-contact.
This has been my work philosophy since I started and I’ve been at the same job for four years now with no plans of actually leaving (but still leaving my knowledge behind to avoid the pesky silos)
No employer ever really treats an employee as indispensible. The industry usually has the opposite problem (no one stays long and no employer incentivizes them to do so, meaning no system experts and high churn)
I wouldn’t say that for the whole industry. At least among big tech companies, it’s pretty common for some chunk of your compensation to be paid in stock, which vests over time as long as you remain at the company. At Microsoft, for example, your annual bonus contains a cash and a stock portion. As you go up in seniority, the ratio of stock to cash increases significantly. The stock vests in 3-month intervals over a five-year period. If the stock price keeps going up, this means that the stock from older bonuses is worth more than the stock from newer ones. That gives a pretty strong incentive to stay.
Of course, the flip side of this is that the same companies also offer signing bonuses that provide an equally large incentive to move…
I find the opposite to be true. The old bonuses being worth more gives the perception that my compensation is trending down over time and gives me less reason to stay after my bigger vests have completed.
[Comment removed by author]
“The way of the Samurai is cloaked in death. The natural way of a Samurai is to consider himself as already dead. By setting his heart right every morning and every evening his resolve will be firm, if one will do it it, it can be done. With this he gains freedom in the way, his whole life will be without blame and he will succeed in his calling.”
– Yamamoto Tsunetomo
There are many good points in this essay.
1Making yourself irreplaceable by building a system only you know how to service and run might seem like a good short term career strategy but it locks you into a role that you can not be promoted out of. As the system ages it might start to get deprecated and you become obsolete with it
2By ensuring other people can run the system you become useful to many people. The more people you are useful to the more truly valuable you are. This is good for your own wellbeing, the wellbeing of your teammates, the product and the company. This leads to more prospects for being given more responsibility and career advancement.
3Good documentation is a key to Pt 2. The reach of your work becomes greater if random people can see and use what you build, add to and expand it.
The title is clickbaity, but the substance sets a good bar for maturity in a software engineer. I have encountered engineers who hoarded information and essential tools, thereby holding their employer hostage and inducing varying degrees of paralysis upon their departure. To work with such people is to suffer. To clean up after them is despair.
This is close to how I think about work in general. Partly because I realize that I am finitie and that many will come after me who will likely have to work on or indirectly use the things I work on. By making it easier to replace me in my role I view it as making it easier for the next generation. The idea of making myself irreplaceable feels very selfish to me, as I’m going to be replaced some day by some one whether I like it or not.
I don’t think this goal is attainable for a programmer, especially one that’s doing a good job working on a non-cookie-cutter project. Over time, a good programmer learns the business domain almost as good as the users they’re serving and they simultaneously learn the ins and outs of the existing code base and how the components map to the business concepts. The longer you work on a project, the more your brain will morph into a machine that’s streamlined to solve problems in your domain by changing the existing system. That kind of domain-brain-system adaptation is impossible to transfer between people, so a company loses a huge chunk of its soul (and competitive advantage) when a dedicated and experienced developer leaves.
This is true! But also not. There’s lots of stuff that isn’t domain knowledge that is nonetheless necessary to work on a project. For example, I’ve seen an undocumented release process used to protect a fiefdom. A mature engineer would at least document the process, or preferably automate it.
[Comment removed by author]