On Being Indispensable | Hacker News Reader

On Being Indispensable

sofuckingagile.com

537 pointsasyncscrum283 comments

In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it."

The best advice I got starting out was, "be indispensable."

The best advice I got four years later was, "don't be indispensable."

In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned the meaning of 'working your way out of a job' after the first time this happened to me.

I'm sure there's some min-max game I'm not playing with regards to how easy I am to lay off, but once I learned there are worse fates that being laid off, I stopped looking for them. Being "stuck" with responsibilities is unpleasant when things are going well, but it's miserable when things are going badly. If you aren't the one who got laid off, then someone you used to trade off with doing onerous tasks certainly was, and now you're stuck doing it every single time.

If given the choice between "my company would be just fine without me" and "everything would fall apart if I didn't show up to work," the latter feels very good for a brief period when you're young, until the weight of that responsibility sinks in. "My company would be just fine without me," can mean "my work here is done," and you can ride off into the sunset with a clear conscience.

> "My company would be just fine without me," can mean "my work here is done," and you can ride off into the sunset with a clear conscience

It also makes it way easier to take your vacation time.

If your employer is harmed by you taking vacation, they will find ways to make you miserable for it.

> If your employer is harmed by you taking vacation, they will find ways to make you miserable for it.

Ouch, I know this one well and it almost cost me my marriage.

Your marriage wasn't enhancing shareholder value, citizen.

s/citizen/human resource/

I have been in this situation myself, but my former boss has a conscience, as it turned out. My wife and I were on a vacation that was timed to celebrate an important birthday. I had spend days during the preceeding week training up two people on my team, and maybe one or two others, on various processes and contingencies. Yet still, when push came to shove, I was asked to get online to put out a fire. Luckily it only took an hour or two. A few days later I was surprised to find $1000 bucks deposited into my account from my boss as a thank you.

This system that I had hacked together, built out and maintained, kept on growing in size, complexity, attributable revenue and potential compliance liabilities. Within the year, I had to call the execs into a meeting to drive home the point that this wasn't a tenable way for us to operate. Everyone had known as much but it was still a tough pill to swallow. I let them get too spoiled at a huge cost to my own mental health.

I had to paint a dire picture to make my case that the system had to be rebuilt from scratch in order to be integrated into the main infrastructure. I ended up leaving a few months later as the rebuild was nearing completion. A couple of months down the road I was surprised to learn that they were still using a part of my system alongside the rebuild. Apparently their architecture couldn't support an algorithm that this component had relied on.

What a mess!

Sounds like this story is yet another reason people should regularly be moving to different companies

What's your goal, though? I'd like my company to not absolutely 100% need my constant presence, and I don't want to be in the author's position where he is not doing what he could be most valuable doing. But I do want my company to think "wow, that ivraatiems, we're sure lucky to have him." I would want them to think twice about firing me or laying me off if layoffs were happening. I definitely would not like to have to go look for a new job unexpectedly.

So, I want to be personally valuable to the company - maybe more valuable than the average engineer - but I don't want to have indispensable knowledge that locks me in place. Surely there's a middle ground here?

Presumably the goal is to be nominally replaceable, but just so all-around awesome they’d be sore to lose you.

Easy, right?

I worked at 3 companies between 2014-2020. My goal going in was to solve the set of problems I was hired to solve by the then new manager and “put myself out of job”.

Today working in a consulting department, I refuse to take on any work that may look like “staff augmentation”. I just do project based implementations with a definition of done and set aside time for training the customer.

Be the best at two things, and train someone to do the less rewarding thing while you learn a new thing.

I think the middle ground is to have a huge stash of savings. That way, the original proposition isn't really relevant anymore. (That proposition being, I need to be valuable so I don't get fired).

Being indispensable to a team or a manager in a large company can actually be self-destructive to your career. I realized this the hard way a long time ago when my managers refused to let me move for a promotion because I was "indispensable" and "critical to the project". I've always made it a point to know who my back-ups are and have my supervisors assign them formally.

In short, make it a point to share knowledge anyway. Keep a wiki, well written notes or documents, README.md's, whatever. Make it a point that people who are backing you up acknowledge and understand what you have and most importantly ask them to grow that body of knowledge.

That would be an instant resignation as a matter of principle for me.

Principles are a luxury not afforded the poor masses.

If you are indispensable, then surely you have quite a leverage.

That argument does not solve the problem. You will stay or go from one project that fails to the next like that. Better to have worked on projects that are still good on your CV.

No.

Scenario: There is a project your boss is wholly responsible for. You, from a technical perspective, are absolutely indispensable to the success of said project. Maybe it's a small team, or everyone is overloaded, but you can draw a direct line between you quitting (or doing a bad job) and your boss getting called out or potentially fired.

Your boss, however, is not indispensable to their boss, nor is this project indispensable to the larger department. You ask for your raise because of your leverage. Your boss might be worried and try to get it for you. Their boss, not caring about this project that much in the broader context of their work, laughs and says no.

You can absolutely be critical to the success of a project, and even important to your boss's future, but have no real leverage over your situation. That's absolutely a reason to leave but it doesn't mean you'll be able to squeeze any more money out of the place before you do.

Such a great point to make. Specially since I see myself in similar situation. Maintaining a legacy system on which all the devs except me who worked in past have left. It is critical system or so I heard but as far as promotion/raise go, almost nothing for last 3 years.

However instead of getting angry I get that I may be important to direct boss or one level above. But as far as company goes they are all in cloud, next generation and what not. So my criticality is inconsequential in larger context.

Or even a lot of the middling ones. In the US something like a trillion dollars a year is spent on making people want to buy stuff. Not to mention all the social forces that encourage spending. Relatively few people manage to live far enough beneath their means that they can just quit a job on principle.

I happen to be one of the people who can (and has!) quit a job on principle. But it's very much a luxury good that I work hard to afford. And it's easier for me: no kids, no parents to care for, no mortgage to worry about. I would rather more people quit their jobs on principle (or risked it through efforts like unionization). But I mostly don't blame them if they feel like they can't.

Obviously you find another job first. That will take a few weeks in this market.

I’ll take “people who haven’t bought a house or have kids” for 500, Alex

There’s a thread right now in r/experiencedDevs about a guy who is trying to buy a house while his employer is cratering around him. Stuff like that happens and tends to stick with you forever.

I have a house and a kid and I have quit on principle before.

> refused to let me move for a promotion because I was "indispensable" and "critical to the project".

So would they rather have you quit? If not they should be willing to give you whatever title, pay bump, time off, etc. is necessary to keep you long enough for a replacement solution to be found. Otherwise if you just quit they’re stuck negotiating from a position of weakness to hire you back as a much higher paid contractor, or if you decide to take an extended vacation or work somewhere else they are left high and dry.

If you are truly “indispensable”, that makes you the one with all of the leverage. If they can jerk you around without pushback, then “indispensable” sounds more like a rhetorical device / excuse.

I would argue that exercising such leverage is not only for benefit of the indispensable but also for the organizations which are often inert unless enough initiative is given.

Indispensability (true or perceived) hurts not only person but organization as a whole. It creates tension between them, which might break at any point for any reason (a bus, reaching point of no return, dragging organization down) and create difficult to fill void once that happens.

I think it should, however, be considered from the true indispensability and not the perceived one. Perceived one is bullying employees, accidentally or on purpose. Sometimes it's bullying ourselves by creating overly controlled environment that solidified over years.

In perfect life scenario utilizing leverage would work as following: The Indispensable ask for a minor raise (1-5%) -> Company agrees, because The Indispensable is truly indispensable -> 1 month passes -> Repeat

After couple iterations there would be a break point because company will start to weight options and might decide to compensate instead of waiting for next month and another raise request. In this scenario The Indispensable stops being one, so their quality of work improves (less stress) and they get additional income. Company retains The Indispensable since they signaled and through adequate pressure achieved the goal. Fragile process with single point of failure is resolved with more stable solution.

Unfortunately it doesn't work in real life often. Some companies simply can't afford matching expectations, no matter how warranted they are. Indispensability there is simply a tax imposed on worker. Some people aren't confident and courageous enough to bring issues out and try to act on them (as business can be intimidating). Last and not least - true indispensability isn't black or white. There's a mixture of politics, perceived indispensability, true indispensability and controlling behavior by The Indispensable one.

So would they rather have you quit? If not they should be willing to give you whatever title, pay bump, time off, etc.

For large enough companies the 'company' is not a single unit making unified decisions. I might be "indispensable" to my boss, perhaps his boss, the project, and my department. However they don't have the power to give me a pay rise or extra time off outside the normal bounds set by their bosses. Me, my boss or even my department however aren't indispensable to the whole global multinational company we all work for.

If I quit and the project fails, then my boss and several people on that project might lose their jobs, and the remnants of that department might end up folded into some other department. My bosses boss might not get a nice bonus that year due to the fact that the project he was overseeing was a massive failure. However "The Company" and it's tens of thousands of other employees all around the world will keep on trucking as if nothing had happened.

To add on, it is a lot better story to tell during behavioral interviews:

“I was hired by the Director to solve $x problem. I led the project. I put processes in place. I led training for the team and they went public a year later. I met my former director for lunch a year later and most of my processes are still there in a slightly evolved form.”

About the same as above from my job after that. But change “Director” to “CTO” and change “went public” to “got acquired for 10x revenue”.

(Yes I can draw a direct line from the architectural changes that let them pivot to selling access to micro services to their value proposition when acquired)

> my department however aren't indispensable to the whole global multinational company we all work for.

Some of that is wishful thinking on their part. They can’t acknowledge that the riffraff keep the wheels on and may swing the other way as a form of denial. They probably treat waiters like shit too.

> However they don't have the power to give me a pay rise or extra time off outside the normal bounds set by their bosses.

Maybe. But - maybe they just follow the path of least resistance, which is to lean on you rather than go up to their bosses and say "John Smith is quitting, and when he does, this project will crash and burn. We must stop this or the company will lose $$$."

> So would they rather have you quit? If not they should be willing to [...]

I know that many folks here work in elite organizations, so maybe it's hard to fathom, but THE NORM for big companies is to be dumb as a box of rocks when it comes to organizational stuff and technical operations.

Talented people who are intrinsically cross-functional, curious, and who always to do what it takes to "help the team" often get hammered flat from years of the daily grind-stone and then just quit, like the OP.

In most places no one is even thinking about "retaining talent" until it's far too late.

Retaining talent conversations feel much like people who show up to AA after the liver disease diagnosis. They didn’t think it would happen to them, they didn’t look at it, and their sudden conversion is a rear-guard action, closing the barn door after the horses have gotten out.

If your bosses are saying “retention” out loud you are probably already fucked, even if your division seems to be doing okay.

It is very clear that bosses have had good luck bluffing or calling other people’s bluffs and many just do it as a matter of course. I bet you won’t quit over a 5% discrepancy in pay, and I’ll just ratchet that up every review period, and hope you don’t notice when that climbs to 10% under market.

It’s kind of the same game landlords play. I always find it somewhat amusing when a landlord forces a business out of a storefront and then the storefront sits empty for six months or a year. How long is it going to take you to break even on that?

For storefronts specifically, and depending on the country you're talking about, there's more likely than not an attempt to evade or avoid tax. For example, this is exactly why tourist attractions like Oxford Street in London are full of American Candy stores now. They'll be there for a few months and then be gone: the landlord saves on business rates because they'd found a tenant, and the actual company vanishes without having paid the rates they were responsible for.

In that case, it's beneficial to the landlord to have some scam shop in because even if they're not being paid rent, the money they're saving from an occupied storefront easily outweighs every other alternative.

Lots of commercial buildings are passed down from generations. You don't know how to think like them. They have the building its been generating money and they have lots of money so they don't care. They want toy X that costs $XXXX per month if the tenant leaves they don't get the toy and they lose the rent they don't need to live anyway. If the tenant stays they get the toy. Otherwise they don't care cause they are good financially. You would be amazed how man "business" decisions are made based on the basis of if it buys the owner the toy they want.

Toy is just a euphemism. It could be a service, it could be just showing up their friend jimmy that they made more money this year. IT could be to win a bet. IT could be the tenant scratched their Bently. It could be that somebody they don't like frequents the establishment.

That sounds to me like an invitation to negotiate ;)

Option A) You truly are indispensable and critical to the project, and soon you're going to be their best-paid employee.

Option B) They will now find ways to make you dispensable. And then you'll qualify for that promotion.

It’s not about “I’m indispensable pay me more”. It’s about “I don’t want to have 1 year of experience 10 times”. I always want to have the optionality to change jobs . Things change. Culture changes.

I've heard this "one year of experience 10 times" phrase before. It seems to mean different things in different contexts to different people. Can you explain what it means to you and the implications?

Real world example:

I started my second job in 1999 it was for a bill processing/printing company. Companies would send us data files via ftp, we would merge the files and create files in a format used by industrial printers and mail them out. Later on we were one of the early integrators with CheckFree that was the backend for most online bill payment services.

I wrote mostly processing programs in VB6, Perl and C++. I did some GUI programming with C++/MFC/COM (ask your parents).

Fast forward to 2008, the world had moved on. But I was still using VB6 (discontinued in 2001) and C++/MFC. My compensation was only $7K more in 2008 than it was in 2000. There were other people doing the new shiny while I maintained the old systems.

I learned my lesson. Over the next 10 years, I changed jobs 5 times and doubled my income - nothing to brag about. It was still about what entry level developers get as return offers in BigTech. I was laser focused on keeping my skillset in sync with the market.

By 2017 though, I realized my market value as an enterprise dev was going to plateau in 3 years and my youngest was graduating from college. I started pivoting to “cloud” and got into “application modernization” consulting - basically a fancy term for cloud app development and deployments.

I got my current job in consulting in about two years ago.

Good lessons here on tracking the market, keeping skills up to date, and skating to where the puck is going. I imagine the modernization niche pays pretty well. :)

Ironically, “application modernization” seems to be the worse paying cloud specialty in the industry. At most consulting companies, “implementations” pays the least and is outsourced to cheaper labor and junior consultants.

I work at the one company that pays decently well for AWS + enterprise dev + consulting. It’s not hard to guess which one it is..

There's the risk of heroism too... you're indispensible because you're that one person who goes above and beyond and everyone sees you as the go-to when shit goes wrong.

I've been there a lot, not on purpose but in some organisations it's either that you get your hands dirty or you spend 10x as much time watching the buck being passed. It's definitely one of those things as a developer where you need to learn some management skills or end up burned out of the job.

Starting in a new role, or new company, often means that there is a period when I'm hard to replace, but since I try to automate everything I can and make the rest simple enough for anyone to do, I'm actively trying to make myself useless and out of a job. Funnily enough, it doesn't seem world is running out of undone work anytime soon and there are always more interesting problems to solve.

> If given the choice between "my company would be just fine without me" and "everything would fall apart if I didn't show up to work,

I found the problem. It’s not “your company”, it’s “the purchaser of your time and attention”. Act accordingly.

I remember reading "Anything you want" by Derek Sivers. There he describes, that he actually went towards "my company would just be fine without me" with his own company.

So regardless of being an employee doing bodyleasing towards their employer, being an employee that identifies with "their" company or being a boss/founder/owner/manager these two sides of the axis exist and one needs to find the spot that fits for them within that range.

I don't think there are "one size fits all" easy answers. Or at least if they are given imho and by my experience they are wrong more often than not.

It's a fine line. If you want to stay employed, but not be pigeonholed, you need your company to see a future with you in it, rather than always thinking of you in the present tense, dealing with the latest problems du jour.

I think for me these sorts of pre-emptions have always felt quite jarring, so the feedback loop for me is tighter than for some.

If you bring me a novel problem to solve, I will happily stop what I'm doing and help you figure it out. For some reason I've only rarely had problems getting back into whatever you interrupted. Whereas with fire drills I have trouble spinning back up into what I was doing before. Perhaps to do with finite energy reserves.

Ultimately I credit my early successes getting promoted to Lead to this pattern, because 'novel' problems either explain a wider portion of the overall architecture to me, or end up being all hands on deck when it turns out this issue is bad and is already in production. I cannot emphasize enough how much smarter you sound offering a solution you've had 30 minutes to an hour to think about instead of 10 minutes. The developer who triages an issue is two steps ahead of everyone else who is thinking on the fly. Doubly so if you have to wrangle everyone into a meeting room to discuss things. Unless the other people are vastly smarter or knowledgeable than you, you will hold your own in that conversation, even if you are somewhat junior. And if you're instead on a par, you will excel.

Unless you are a co-founder or otherwise heavily invested.

i think the indispensable idea is from an era where job stability is important and you might be at one company for decades.

The méthode en vogue of the current era is to jump ship every 2 years because that's the best way to get a raise/promotion. With that strategy being indispensable isn't that important because you will self-dispense in 2 years anyway.

I think one of the problems from "being indispensable" is the direction it takes. Being indispensable in regards to people "being left holding the bag while new initiatives are undertaken" means they are/were indispensable in regards to specific tasks/processes/skills or knowledge.

Personally I feel being indispensable can also be seen as being able to be thrown at (nearly) any problem and finding a solution. Catching the ball and creating the basis for a stable project for others to take over/maintain. I am working at an agency and more often than not there is a first small initiative at a client where we just do not know what is expected/needed in terms of skills and in what direction this initiative might go/grow.

So we often throw two people at the "problem". One more senior "jack of all trades" kind of person that can understand a lot of problems and knows how far they themselves can work towards a solution (and when to call in the subject matter experts). And one more junior person to support and learn by swimming in cold water together with said "senior" (can actually - depending on the problem be a junior/intermediate themselves - it depends).

These "jack of all trades" persons, thinking on their feet, being able to improvise and get things done, able to understand and dig into problems ans find solutions - these kinds of persons are indispensable - but they don't get stuck in one specific problem/project.

The processes around them are built in a way so that we free them for the next thing to come our way. And we do everything we can to create new people of that kind.

I'm not really familiar with the military context, but it's almost how I envision an advance/special forces unit operating in front of the actual lines and first creating a beachhead that the regular troops can then build on and bring their strengths to bear.

These types of individuals are indispensable - but ideally not each of the individuals on their own.

TL;DR: Be indispensable for the role you want to be in. This may change over time.

Deming sometimes used bus drivers as an example. Some of them might think it's not their job to smile and be nice to passengers. They're hired to drive the bus, and perhaps help out in emergencies, but not much beyond that.

However, being nice to passengers (performing "caring labour" as Graeber would have put it) increases the chances that people choose the bus over e.g. the metro or something else. Deming concluded that it's always your job to do whatever increases the chances of the company you're working for staying in business.

I still haven't found a good way to phrase it, but I'm starting to think that for knowledge/creative work, this can be specialised to something like, "it's your job to teach others to do what you think your job is."

For knowledge/creative organisations to stay in business over the long term, they need to continuously innovate, and for innnovation you want people to be strong generalists. Not just because it lets them spot opportunities they otherwise might not, but also because it lets the organisation run more efficiently with less paperwork, and because it gives people the autonomy they need to think clearly about things.

If the bus drivers were paid by the number of people who take the bus sure, but when are paid by the travel route distance, they have no obligation to do what they are not paid to do.

What a nihilistic view. Not every aspect that’s part of your job needs to be included in your variable compensation in order to be done, does it?

They’re employed to do a specific job, if they’re not rewarded for bringing the company more money, why should they care?

Because human beings are not coin operated robots?

So they should do unpaid emotional labour for free?

If you equate smiling at someone, or just being generally courteous, with "emotional labor," you need to make an emergency appointment with your therapist.

Being a good human being more often than not (occasional bad moods notwithstanding) should be a non-functional requirement for any job where you interact with other people. I have no problem with anyone, in any role, getting fired simply for being an asshole. The world would be a happier and better place for it.

> If you equate smiling at someone, or just being generally courteous, with "emotional labor," you need to make an emergency appointment with your therapist.

This entire conversation started based on an example that smiling brought economic benefits, not that you should do it because of socializing benefits. Answering in economic terms only makes sense.

Since when is not smiling at people being an arsehole?

I don’t want a bus driver to fake cheerfulness. He’s there to get me from a to b, not to pretend to be my friend.

Smiling is not pretending to be someone's friend. Seriously, if this all sounds like alien talk, you should see a counselor or therapist.

I didn't say not smiling makes you an asshole, I'm making two separate points. The first was that expecting people to be generally courteous to other people, whether they're explicitly paid to or not, is something we should expect from everyone. It's called just being a human being. And again, everyone's allowed to have bad moods now and then. But in general, if you go through life with a scowl on your face and approach things from a standpoint of "I'm not being paid for this so I don't care, I'm not doing 'unpaid emotional labor,'" you're just kind of a jerk. That's the context of the last couple comments in this thread so it's important to keep the "I'm not being paid to smile so I'm not going to smile because that's labor" thing in mind.

The second point, which is related but I think still separate, is that I wish just being an asshole was enough to get fired. I sort of had it in my head but didn't really articulate that I was thinking of being an asshole as a more extreme version of what we're talking about, what I refer to above as just being kind of a jerk. Maybe on a scale of 1-10 being a jerk is a 3 but being an asshole is a 7 or 8.

You keep confusing being polite (something rightfully expected from an employee) with being fake and with real emotional labor.

This are 3 different things.

Many types of emotional interaction are meaningful and true only when they are unpaid. Some big examples: friendship and love.

For employees not to be rude to customers as part of basic work requirements.

But putting on a false smile and feigning warmth to get a tip is a very different thing.

It's quite common and accepted in the US. But also seen as soulless and emotionally manipulative in many other cultures.

The specific job includes customer service. It's what they are being paid for. Employees who do the job poorly are at greater risk for replacement by replacement hires. This is why many companies ask customers to rate individual service providers.

I would never rate a customer service employee poorly because they aren’t cheerful.

What sort of mad world do we live in where that’s even expected of minimum wage employees?

Yes but if the number of people on the bus dropped to zero do you think their employers would keep running the route?

The passenger count is so heavily influenced by factors outside of the bus driver’s influence that this example doesn’t make sense.

Passengers don’t abandon bus routes because the bus driver didn’t smile at them. They abandon routes when the schedule is inconvenient, there are better alternatives to the bus, the fare is too high etc etc. None of these are in the control of the bus driver.

My old bus route to work used to amuse me greatly because on it there were two drivers who were the polar opposite of one another. One guy I assumed had previously been the pilot of a commercial airliner because he used to greet everyone who got onto the bus with that sort of demeanor and make announcements etc. Always brightened my day. The other guy was the grumpiest piece of shit bus driver I've seen anywhere in my life who would frequently berate passengers and oftentimes frighten unsuspecting foreigners. Everyone who needed to get to where they were going showed up and took the bus regardless. It's about the least important variable there is and it averages out to getting a reasonably OK bus driver almost all the time across the different busses you take and the different times of day you take them.

Ah, this must be why bus drivers are commonly paid in company shares. Incentive alignment! Makes sense.

Wait, they're not? So why should they care, when their bosses don't care even enough to set up a direct reward to bus performance and some way for them to have agency over that reward?

Though it would be cool if there was a bus service that had direct, fine-grained association between curteous behavior and reward in the form of immediate payment and future business, possibly mediated via ratings - I was making a joking reference to Uber here, but "Uber for busses" is genuinely something that I want to exist. Ie. not "Uber Bus", but the standard Uber model of engaging a driver directly, only this time applied to longer timespans to allow better schedule coordination. For instance, some way to say "Hey, I need a bus from X to Y some time between 6 and 7 every workday for the next six months, which time and pickup location is cheapest?" would allow for some pretty cool optimizations in routing. Possibly combined with a Kickstarter-like model where a bunch of people can express prospective interest.

If I’m working for a private company. Guess how much I care about “equity” that will statistically be meaningless?

On the other hand, I did implementations as a Senior Develop/de facto “cloud architect” that moved the needle meaningfully at a company with $5 million in revenue. Those same types of implementations happen multiple times daily at a company worth over $1 trillion. Nothing I’m going to ever do will ever have a meaningful affect on the stock price of the company I work at now.

Kind of sounds like the company share price is too coarse-grained. That sort of thing might work better if the company was split into separately traded sub-units, of which the parent company owns some controlling fraction of voting shares. Admittedly the bureaucratic overhead starts being awkward.

There are four companies worth over 1 trillion. How could you split any of them in a way that my small implementations by their standards would make a difference? I purposefully focus on the “nose of the camel in the tent” type work.

I like smaller proof of concept + training type projects.

I agree there is not necessarily a good way to do this in any given company structure. However, if a company can figure out how to do it, other things being equal I would expect it to eat its competitors' lunch. (As with how Uber doesn't need to mandate that drivers should be nice; it just falls naturally out of the incentive structure.)

> "Hey, I need a bus from X to Y some time between 6 and 7 every workday for the next six months, which time and pickup location is cheapest?"

They could even make it so that the people who actually take the bus negotiate the time and place.

This would be great for events outside the city.

This is what Citymapper's Smartbus tried to do in 2017 - regulations don't make it easy, so negotiations with the municipal authority and Transport for London are still ongoing...

“Imagine if you could hire a bus”?

You can; groups of people hire a mini bus or coach and negotiate where and when it travels all the time for social events, work parties, school trips, etc.

BTW, this sort of smugness is why Detroit is a shattered husk of what it used to be.

When Deming still had all of his hair, he had trouble getting traction in the states. Japan, on the other hand, was intrigued by his ideas and wanted some quality time from him. If you look at the history of the Toyota Production System, they usually credit Taiichi Ohno and Toyoda, with the origin story sometime in the 80’s, after Detroit was already in flames, but before that was Deming, and for some reason he is usually not mentioned.

> However, being nice to passengers (performing "caring labour" as Graeber would have put it) increases the chances that people choose the bus over e.g. the metro or something else.

Increases is a relative measure. It may be 10% or it may be 0.0001%. At very small values it becomes basically a zero because humans are non-divisible unit at which point your theory is basically in the rabbit’s hole of magic and wizardry.

This happened in the first company I worked for. It was a big, well known engineering company, and when things started going south they had to negotiate with the state labor department to do large layoffs, which required giving financial cushions to let go employees. I was a star employee - so while everyone else was being laid off with nice, big compensation packages (like 6-12 months of salary), I was stuck in a company on fire that obviously had no future. I was, in effect, punished for being "indispensable".

Ethical issues aside it's easy to see how people in that situation can basically just stop working / start interview prepping while waiting for the layoff.

After about 20 or so years now, one of the main things I've learned is that you aren't as indispensable as you think you are. You might think the company will go under or otherwise degrade when you leave, but that never happens. The company will trudge along without you. That being said though, if you do believe yourself to be "indispensable" to a degree in which the burden of you leaving is large, then by all means, use that to your advantage in obtaining raises/promotions/etc.

Or you are indespensible, and the company could go under, but you can charge them huge afternoon-consulting fees while working a new, better day-job elsewhere.

"My Company would be fine without me" also means you can take vacation, medical appointments, heck even weekend (crazy concept!).

"Being Indispensable" can also mean two years of no physical or mental time off; it was not fun!

I am currently lucky that all my layers of higher management understand that if my team can function effectively without me for a period of time, that means I'm doing my job well . I was able to take 2 months of paternity without things falling completely apart, and it was a proud moment for me and the team (plus great chance to bond with family). Sure there were things to catch up on and new initiatives and some bad habits to work through, but it was overall a success.

(In addition to "be indispensable" vs "don't be indispensable", one of the best pieces of advice I got and share is "The moment you get a new job/role/position, start looking for your replacement". I did not understand the value of that the first few years, but I now 100% do. I know a lot of HN SME/IC's believe "it's my boss's job to replace me / I'm in & out in a year or two", but if you are even remotely looking for a sustainable career in a company or small market/industry, it will speak VOLUMEs to your foresight, care and team&business responsibility if you have a trained, capable backup identified and positioned, for your times off as much as for your eventual ambitions).

> "My Company would be fine without me" also means you can take vacation, medical appointments, heck even weekend (crazy concept!).

This is so worth it! A decade ago, I was the technical cofounder of a still-small startup. For a while, it was just me and my co-founder. But when we got signs of product-market fit, I hired a team of developers. We set it up so the default was pair programming with frequent pair rotation, with a lot of other tweaks to make it very collaborative.

This paid off in a lot of ways, but for me the biggest came when my mom got sick. I had to fly across the country and stay for weeks at a time to help her and coordinate her care. I was worried things might grind to a halt. But because every commit to the code base involved at least two people, it was fine. There were things I understood better than others, but there was nothing that was a scary mystery that nobody had touched.

When I left the company, it was the same deal. We were on good terms, so they were welcome to call. But they rarely if ever did! It was great to pop in now and again and see them just chugging ahead.

"You can't be promoted if you can't be replaced."

> you can ride off into the sunset with a clear conscience

You can always do that.

This was the big lesson I learned recently and I whole heartedly agree. It's can be very dangerous to your mental health to not have this perspective if you wind up emotionally trapped in a bad situation.

There is actually no contradiction there. You want to be indispensable for the position you wish you have, and dispensable for any position you don't wish.

If your interests change, your dispensability should change with it. But this is very hard to achieve, so you get a complex goal of optimizing for many things at the same time.

The first thing to remember is – no one is indispensable. If you get hit by a bus tomorrow the company will go on without you. People may have a bit of trouble at first, but new processes will develop and new people will gain expertise just as you have now. Heck the company might be better off in the long run without knowledge bottlenecks.

Second, being indispensable doesn't do a whole lot for job security. If the company is doing well, you need to perform exactly at average to stay employed, no more. And if the company is down in the dumps and there are mass layoffs, who is going to judge how much knowledge you have in your head? All the people who know how good you are are probably getting fired as well.

Third, you are probably not as important as you think you are. Upper management isn't sitting around singing your praises in their weekly meeting. No, they are focused on the rising star who is executing new ideas and launching new product lines. You are meanwhile being taken for granted.

Now, if you are in this position the author writes about, the time to get out of it is now. Realize that no one can help you but yourself. Start redirecting people, or ignore them altogether. Make noise up the management ladder. Play dumb if you have to. Eventually the rest of the company will find some new punching bag and leave you alone.

"The cemeteries are full of indispensable men."

100% this. A lot of wisdom here.

The indispensable head of QA at my company died of a heart attack after working 100 hour weeks for years, they did not replace him.

A one sentence horror story. How much of his life was missed for things the company could do without?

Probably about ~8% of his life.

> A one sentence horror story.

Too true. My favorite quote on this topic is that "work will never love you back". It's easy to get wrapped up in what we are doing (sometimes the less important it is to the world, the more I need to get wrapped up in it to be motivated), but work pales in comparison to:

* a good conversation with a friend

* time outside, contemplating nature and purpose

* a hug from a family member

But we don't treat it like that, unfortunately.

Of course, we all need to eat and I realize I'm speaking from a position of privilege (not worried about where my next meal is coming from).

Once you get to an income of X (where X varies by location, needs, but is definitely a finite number), time is so much more valuable than money.

> but work pales in comparison to:

I just want to note that this is a poor generalization. Much like how people wonder how I have the discipline to get up early and workout, it's because I enjoy it. I also enjoy my job the vast majority of the time, and I suspect many others do also. My dad always comments "I'm amazed you get paid to play on the computer all day...", "Me too dad, me too".

As a generalization, it's a good one. That there are exceptions doesn't make it a poor generalization.

If you enjoy your work more than other things, that's great. For me, even within the domain of tech, there are much more interesting things I'd like to do with tech than what I do for my job - and most of the things on my list will not be supported by the market - they're confined to hobbies.

What would you say is a good generalization when it comes to work life balance? There's sure a spectrum, from the folks who love to work (or even workaholics) to slackers who don't want to.

If you like what you do who cares? If you don't, find a different job?

> * a good conversation with a friend

* time outside, contemplating nature and purpose

* a hug from a family member

you can do all these while working a lot....

There are people who are indispensable to the point that entire products, teams, or companies rely on them (for better or worse). The company very well may not go on running if they are hit by a bus. At the very least a product (or products) may be cut and teams made vestigial or laid off.

According to my ~15 years of work experience in IT/the tech sector, this ought to be pretty accurate.

This is something I wish I'd understood earlier in my career. Your company doesn't care about you, nor should you expect them to. You might give 110% and be a well-regarded model employee. But I guarantee the day after you leave they'll advertise your position and replace you.

I’ve gotten laid off twice despite department VPs two levels up trying to keep me.

The second time I realized that there is no point in trusting in anything related to my relationship with the company.

It doesn’t matter how good you are when the people making decisions either don’t know or don’t care. Eventually you become inconvenient in some way and you get removed.

reversedly, I was at a company where I kept focusing on 'stuff', trying to respond on time, hit deadlines, etc. Went to lunch with someone and he kept saying "chill out, don't sweat it". We were late back from lunch. It bothered me, but not him. I found out a few months later he was dating the niece of the dept manager. The two of them were friends with another lead on the floor. This is why he was always 'chill' about stuff. He never hit deadlines or delivered great stuff... it didn't matter. He was 'in'.

Maybe he was in because he was pleasant to work with and not stressed all the time? I've seen new busybodies like you (maybe) and no one wants to be around them.

being given deadlines ("get XYZ done by march 1")... i take that as... "this needs to be done by march 1". This was very much more towards 'nepotism' than "oh he's just so pleasant".

Colleague (new, like me) was given task of "build web software feature X for the marketing team, and you have to ensure colleague B is trained". Colleague B ... did not understand browser technology or server vs client stuff (literally - 'how do you upload a file?' and 'how do you submit form data'?). Colleague tells boss "I can work on training B, or get feature done, but can't do both by the deadline in 2 weeks". "That's your problem, get it done". Feature was done, but marketing team didn't want it ("why did you build this?"), and B wasn't 'trained', and this reflected very very negatively on my colleague. The 'chill' guy? Regularly missed deadlines and delivered buggy stuff. But hey... he's chill, so everything must be cool, right?

If you have loose deadlines... just say "this is a loose deadline".

Unsure how doing work you were assigned is being a 'busy body', but hey, you were there, and I wasn't, right?

This is also a place where the tech leads in charge kept pronouncing that HTML tables were "depreciated" and we should build all tabular data in divs only. In 2004. As in "transform these dozens of Excel spreadsheet data in to something that looks like a table, but... hey you can't use tables, because they're depreciated". If you can't even use the word correctly... I'm not sure I can trust you. This effort took 8 people 3.5 weeks to recreate 'table-like' visuals (across Netscape and IE 5 and 6) with discrete CSS for each browser because... 'depreciated')... It should have taken 2 people a day, and initially it DID, because it was done, then... 8 people were roped in to redo it all without tables.

I ended up quitting in less than a year.

I worked for a european investment bank for a number of years, and they had a policy that every year, every employee (without exception) was required to take 2 weeks holiday as a contiguous block, and during that time, their access to the company was removed, so no email access, no remote login, keycard access to the office removed etc. They basically ran the 'suspend this person from the organisation' script and restored you when you returned after your holiday.

This was primarily in place to reduce the risk of fraud in the trading/operations side of the business, but it had the side effect that it made it very obvious if the business depended on someone being in the office, since managers would have to cope with people being off and unavailable for 2 weeks. It of course also covered people leaving, or being hit by a bus etc.

Overall I thought it was a very simple mechanism to avoid the business risk of being exposed to one employee both from a business as usual, and also from a fraud point of view, and also made it much easier for people to free themselves from a particular role.

That is brilliant! In the US it isn't that unusual to find companies that don't even offer 2 weeks vacation in total though.

Come on. Outside of the lowest-level hourly positions, you're not going to find any US company that doesn't offer at least two weeks vacation.

Sadly, there are too many companies that offer zero PTO in the first year.

The federal government gives 0.5 days leave per every 2 weeks worked. Note that that implies 0.5*(52/2) = 13 days possible to accrue in a year.

I think showing the feds do it should sway you pretty far away from your above position. If not, I'm curious what evidence could be provided that would.

The 13 days off (2 weeks and 3 days, you don't spend it on weekends) is just the first 3 years. For years 3-15 you get 4 weeks (20 days) per year. After that you get 26 days/year. They also get 13 days of sick leave per year with no max accrual. Regular leave maxes at 30 days accrued, you have to have 30 days or less at the end of the calendar year, anything beyond that is lost (use it or lose it). And now they get 11 federal holidays, sometimes more depending on who is president and when Christmas Eve and Christmas fall. It's not uncommon for late-career (15+ years) folks to have max accrued leave every year, which means they can potentially take 56 days + 11 holidays off the next year if they want, sums up to 13 weeks depending on how they use the leave. Of course, you can only do that about every 2-4 years. 2 years if you spend one year without using any leave, which would be pretty miserable. If you're smart about that 26 days, it becomes 6 weeks off instead of just 5 by pairing it with holidays.

They can also earn "credit hours", up to 24 hours of accrued time off by working ahead (an extra hour here and there, unpaid but becomes leave) and comp time (same, but no technical limit, becomes overtime pay if unused).

And there's now 12 weeks of paid maternity and paternity leave, which is better than most companies in the US.

Of course, the pay is lower which is why it's harder to keep technical talent. And as you move up the GS ranks it's a lot like moving up the officer ranks in the military, a shift from technical (at the lower levels) to managerial/leadership (at the higher levels). Which means there are effective caps on people who want to remain purely (or more purely) technical and avoid supervisory roles (outside of, perhaps, team or project leadership positions).

Using the federal gov. as an example of the lack of vacation was pretty funny when they tend to have very generous standard days off, and move up accrual rates pretty quickly.

Indeed. Federal employee benefits are actually pretty good, it's the pay that's not so great.

You might get 10 business days of PTO, to be used as vacation, sick time, parental leave, etc.

The thing is there are no laws enforcing any time off in the US.

So what you get isn’t standardized or available across the board. Generally I haven’t found any that offer less than two weeks, but… I have absolutely worked places that give you the time off but penalize you socially or otherwise if you dare to take it.

For 6 years, I've worked for a outsourcing firm which has given me 7 days of vacation, and only FOUR US holidays. It wasn't until this year that they expanded that to 10 days, and STILL won't give us Christmas Eve. (The company I'm placed in gets a week and a half at Christmas, full stop.) I'm a very senior person for the company, and I'm sure I'm one of the largest PO's they have. Please come talk to my management about how "any" company doesn't offer "at least" 2 weeks of vacation.

EDIT: Don't get me wrong. This situation works for me very well, but the average vacation situation in the US is abysmal.

Oh how I envy the luxurious life you must have had to reach this conclusion

Oh boy, are you out of touch, kudos.

The US financial industry has almost the exact same contiguous time off requirement for the same reasons.

Can you provide a source or examples? Asking out of ignorance—I've worked in insurance and currently work for a US-based financial services company, but haven't heard of this practice before.

It happens at most major investment banks, although to my knowledge the mandatory "two weeker" is generally limited to employees who manage risk like traders. It forces another person on the trading desk to be responsible for their carried positions which should help identify any mismarking or other types of fraud.

https://www.wsj.com/articles/SB10000872396390444914904577615...

It is typically referred to as YAR (yearly absence requirement)

https://www.newyorkfed.org/banking/circulars/10923.html

In an age where loyalty between employer and employee is long in rear window (if it wasn't just a useful fable from the get-go), all you are left with are the grim permutations of game theory, all wary glances and knife edges barely concealed. Being indispensable is the closest thing you have to security, and as for "stopping learning," well, most companies want you to do that in your off-time, anyway.

Throwing that away to become just another Pac-man gobbling tickets in a maze for the sake of being Agile or whatever reminds me of "...the struggle was finished. He had won the victory over himself. He loved Big Brother" in its joy at self-abnegation.

Reams could be and have been written about estrangement in society, the reduction of human relationships to mere transactionality, but being The Person Who Is Expert At This Thing in your little Dunbar's Number sized company (give or take) beats being some plastic gear, designed to be replaced as a sacrificial component, if you are interested in stability, continuity, or even something as antiquated as pride in your work.

I sort of get it -- at an early job, we had a lot of clientele. I inadvertently memorized, well, everything about them: faces, names, various ID numbers, and so on, and instead of the handy lookups provided, employees would just call me and ask. This got annoying. But I was also twenty-four and managed to push back enough to say, "You have the ability to look all of this up." Being bothered with dumb questions if you have all of this documentation and a wiki or whatever, yes, that is not acceptable, but I think there's a middle ground at least between being the Turing-complaint helpbot and just bolting out of there so you don't have to be The Guy in the Know.

There is something to be said for being indispensible for novel problems, instead of for known problems.

Some of the worst behavior I've seen in both myself and others has come when you can hold your company hostage by refusing to do something. Even when you are using it for 'the greater good', that's not a good look and not a great feeling. You shouldn't have to go with the nuclear option to get something done, even if 5/8ths of your coworkers all feel it's the right thing to do. And many people use it because they can, through some mix of hubris and/or burnout.

When people say things like, "first, fire all the heroes" it's situations like this that they are thinking of, among others.

Oh, fire all the heroes, I have worked at one of those places. The people in the know were let go, as some kind of pre-emptive strike of just that nature. Heaven forfend that anyone but the organization have leverage. This was managed before I had a chance to get a Chesterson's Fence view of the processes.

The result was not good: deciphering the how of things was bad enough, but the why, the contexts of the decisions was utterly gone. Nobody could say why things were done, and so it was either the old joke about the five monkeys or the Second System Effect. Glorious chaos, the confidence of our clients eroded, terror at making changes that might affect the way things had been, dread of not making changes to cope with extant problems.

Thanks, but I'll take the M.A.D. that results from the threat of the nuclear option over someone getting to yank out my heartplug ala Lynch's Dune.

Yeah I'm not sure that's meant to be taken literally, anymore than I think "If you meet Buddha upon the road, kill him," is an incitement to homicide.

The people who have reverence for the heroes are as much or more of a problem as the actual heroes, and they need to be shaken severely. It's going to be ugly any way you slice it because like so many things in software, you're in a position where someone should have yelled "stop" years before and instead things just kept going, far past unreasonable into a first-rate dystopia.

If you fire one belligerent hero as an example to the others, you might be able to make it work. But if you have one 'database guy' or 'backend person', odds are very good that they're going to go exactly as fast as they want to go and smile and say 'no' when people ask for major changes that would break up a logjam. If they aren't particularly articulate about why things are the way they are it's easy to get the impression they are running things instead of the titular managers.

Color me a little confused, but I think I kind of would lean toward letting the database person make the decisions about database rather than the titular managers. Haven't we all been through enough "management heard X technology is hot so we are gonna use that" fiascos?

Management's job is not to make decisions about databases for the database person, but to communicate about problems and priorities, and so on. Don't get me wrong, the dark hilarity of malicious compliance can be great when someone commands you, like they are some bumpkin who just rubbed a lamp and acquired a genie, to do something that is gonna bring down production at noon, cutting off your about-to-be-voiced objection, but let the managers manage and let the experts be experts.

That assumes the experts are indeed experts and not just saying no to an experienced consultant/contractor that management hired. Though I agree from the perspective that if the system goes down after the consultant leaves, it’s not their problem.

I’ve been around enough to know that these ultimately are political and cultural problems, and you either have to expect change to be slow in these situations or leave to find a different team…

I’ve tried a bit of both, and gotten frustrated, and in the end, the stance I’ve settled on is to be helpful to change people’s minds. It’s hard though. Being persistent and pushy with help will fail. Having the person you’re helping describe a problem or agree something is a problem, that is the first step to helping find a solution.

I guess another way of putting it is management can suggest using technology X but there should be some kind of identifiable problem to solve. There is always the exception though. For example, the problem identified might be that there are too many technologies and X is the new standard. That’s… sometimes the reason and … what can you do? Having been on both sides of the fence here, you never know, X might not be so bad… or you’ll need to fix a ton of bugs.

As long as you stay happy and helpful, you can maybe nudge things in the right direction? For example: X has uptime issues. If X is already adopted, document the known issues for devs or DevOps, or identify consultants for X that can provide training and support. Figure out how to get data into and out of X if you want to refactor later to a different approach and political winds blow that way. Write cheat sheets that can map what you’re using now to Technology X, and what might be unexpected.

Who knows, maybe enough people will have heard or seen your materials on Technology X that they’re not as impressed or share your viewpoint on it. And if you’re really unlucky, you’ll set yourself up to be the cheerleader for technology X. So… there are both risks and benefits to getting too involved in technology shifts/adoption.

How do you handle the case where Technology X is being deployed because the C-suite was gifted Super Bowl tickets to deploy Technology X?

I have been in this exact situation. I left the company as a result; kickbacks and graft aren’t my thing.

Same as any legacy requirement or legal mandate. Deal with it until you get a better job.

You can’t have a dozen middle tier and front end people at the whims of one backend guy why isn’t interested in ramping someone up to load shed. That was a terrible contract, and at the end I’m sure they went back to the status quo. Him holding the reins of the data and his job while the initiative ramped down and they waited for the next time they got the political will to spend a bunch of money.

Maybe companies need some kind of "Chaos Monkey" system [0] in place for regular employees. Not in "terminating" random employee's contracts, but a culture were regular, maybe even some kind of random transferals onto other projects, or onto internal work regularly happens.

Everybody knows this and everybody should be prepared to a situation that tomorrow they are not working on the same problem they work on today. How would they structure work? How would they share knowledge? What can the organization to to ensure there always are fallbacks to everybody? At least fallbacks that if not perform at 100% but still on 80 - 90%.

Sadly in my org this would not work of the get go, as we often have personal access tokens to our clients' systems. This is sometimes even a contractual obligation as for specific clients we need to be vetted. But even in these cases we could be reassigned/reshuffled towards a slightly different proposition or at least be reassigned to an internal topic for a few days - just like we would not be able to work if we fell ill.

[0]: https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey

People who work in finance are often required to take a two-week vacation every year. It's a good "bus" test and also a good way to find fraud.

Genuinely the most weirded out I feel by the US is holiday culture. If a report took just two weeks I’d be asking them if they were sure they didn’t want a proper three week holiday (and I’m legally obliged to OK a four-week stretch over summer if the employee has the days available to take).

Finance is a mandatory continuous 2 week holiday with no access to company facilities or systems every year.

Plus all the other holidays. Sadly for some mostly junior US employees the 10 days for compliance leave left few other holidays - for the rest of the world, you still have 20 more days to use.

Nah, this isn't a great idea. It's not that far off what most companies do anyway. I think most companies have a misunderstanding of what the problem is. The problem isn't that a particular piece of knowledge isn't distributed, it's that all the knowledge isn't distributed (because it resides with one person). You don't want to go crazy with duplicating knowledge amongst the team, you just want to split it up.

One hero is bad. Zero heroes is worse. You want lots of heroes.

Trying to create a structure where anyone can jump into anything at a moment's notice just leads to everyone having a superficial level of expertise in everything and no responsibility (or worse, responsibility that they can't possibly fulfill so they just get thrown under the bus if they don't hit impossible delivery targets).

All that does is move you from one hero to zero without waiting for your one hero to quit. It's resigning yourself to the bad outcome just to get it over and done with.

The tricky part is that the 'one hero' structure tends to form pretty naturally, so you have to actively take steps to prevent it. If you put a standard team in place and let it run wild, unless the devs understand this problem initially, then eventually you'll just end up with everyone deferring up the chain of command for both knowledge and responsibility over time until a few years down the track whoever was the technical lead on the project is now your hero.

I much prefer to have an ad-hoc structure where important work is divided up amongst the team and each team member takes total responsibility for their part. More senior staff shouldn't be trying to own more code and more responsibility, they should be providing more support to others.

EDIT: I don't think I actually explained how distributing responsibility solves the bus factor problem, whoops. The idea is that part of that responsibility is for managing the bus factor of your own work. This only works if the code you're responsible for is small enough that you can realistically bring another dev or two into the fold and get them ramped up properly with real understanding of the code.

N single points of failure is far worse than 1.

Depends what the failure is. If the important stuff is scattered around 20 different devs, one leaving is significantly less of a problem. I'd much rather piece together what someone was doing on one piece of work than have to try and piece together an entire 20 person project because the only one that knew how to drive the project left.

Also, if you own code and are responsible for it, part of that responsibliity should be making sure you have someone with just enough knowledge of the code to take it over should you leave. That's far more feasible if you own a small piece of it than if you own an entire code base.

I think this method talked about by another commenter here achieves a similar goal, but is more reasonable than chaos: https://news.ycombinator.com/item?id=30697309

Yeah. I see what you mean. This banking regulation to reduce and investigate fraud serves a similar purpose. With around 6 weeks of vacation time banks already have a great system in place as vacations tend to work like a force for handovers.

You can get a good slice of this by encouraging people to actually use their vacation time.

This was my exact situation circa a year ago. It wasn't a great look. It was an even worse feeling. It delayed the start of the project I refused by a year and didn't change management's view on how to get it done.

All that being said the writing was on the wall that I was facing either the nuclear option of resigning, or a second round of even more severe burnout by going along with it.

In hindsight my strategy going forward next time I'm presented with a plan that has predictably disastrous consequences is to simply let them have it their way. IDGAF if you wreck this thing further. I'll even help you do it. We'll maintain friendly relations and I'll leave the company near the end of the project but before it becomes apparent just how bad things really are.

If you can't beat em join em. Cynical as that is I have to protect my mental health and I'm willing to allow you to sacrifice the health of your company to do it.

> loyalty between employer and employee is long in rear window

"between"?

Loyalty towards employees almost never existed in some societies.

You do write beautiful prose here, at least comparing to an average HN comment.

The people most common to enter this state are people who don't trust their co-workers to do the right thing and instead get involved so heavily that in the end they are pulling all the strings. You may call them "control freaks". Sometimes branding themselves as "perfectionists".

When reading his story it became apparent that that's likely his problem. Unless literally everybody in his org was completely lazy (which, honestly, is unlikely), he clearly drowned other people's requests for help with "oh just get out of my way, I'll just do it myself" and there you go, next dependency on himself is introduced. Note that I'm not insinuating that it was on purpose. It's just the natural result of somebody not letting others do things, and fail and learn on their own on the way.

Kudos for realizing that it's a problem and for pulling out of the process. But we only see his side of the story here.

> It's just the natural result of somebody not letting others do things, and fail and learn on their own on the way.

How is this supposed to work though? You can do it yourself and succeed, or you can allow others to fail. If others are constantly failing where you (feel like you) could have succeeded, that’s it’s own form of exhausting.

That's right. That's a problem for management to solve though, not for the guy in the center who could have succeeded all over the place where everybody else keeps failing all the time.

If that's really the case. It could also be the case that there are sometimes just different opinions, and one side of the argument is just more persistent and dominant and "just does it themselves", instead of accepting that a different solution would also have brought the org to a good result. Then that lone superstar gets frustrated (because they think they have to do things themselves), their colleagues get frustrated (because there is that guy that just does things on their own and better be quiet than pick a fight) and it's overall not sustainable for the org. Again, a problem for management to solve.

Yes, sometimes helping people learn means letting them make mistakes. Watching someone do something slowly and poorly can test your patience. But they'll be faster and better the next time. Have patience for them to learn, while being available to guide them when needed or when their mistakes would impact the customer.

I would say your assumption here is unkind and itself lazy.

I have often seen this kind of situation and the cause has always been the same: The most senior in the organisation are ridiculously poor at building their org.

They have hired someone who is pretty great at stuff and they got them by accident, for cheap due to some circumstance, and now attempt to grow without realising they got lucky.

They hire net negative contributors and making it more difficult to deliver, not less. They cannot comprehend that there won’t be some magic that turns these people into productive and driven employees without their own growth in skills, attitude, and care in direction. They are likely incapable of such things.

The person or people at the center of this are stuck, yes. They can’t spread their knowledge because others will actively avoid admitting the docs exist, or refuse to ask Google or another employee. They certainly can’t spread their attitude and skills because no-one else cares or has the incentive or ability to skill up.

There is only one eventual route for the capable and driven: leave and go somewhere where there are better people in senior roles.

If everybody around is relatively incompetent, then the superstar at the center can't fix that. The overall result that the org produces is based on everybody and eventually "regresses to the mean" of what everybody contributes. Management and also the superstar need to accept that.

I write "relative" because it's a matter of perspective. Maybe from the superstars perfectionist perspective, the others are incompetent, but from the outside they are "good enough". Or maybe they are not, but the point is that there is a mismatch and the superstar needs to either accept that or leave. The third alternative, trying to lift things to the superstars (real or perceived) standard by "I'll just do it myself" is not sustainable and results in situations as in the discussed article.

Yes, your conclusion that this person / people should leave is the same as mine. I’m also saying, however, that the person / people you’re describing as ‘superstar’ don’t have to be that at all. There doesn’t need to be a 10x contributor and lots of average people. Just a 1x contributor and lots of 0.01x or -10x people.

Too many owners / managers believe that to grow your business you just need to add people, that they are great at hiring people, and everyone will just sort themselves out and work together. They are then surprised that this doesn’t happen, despite their faith in their own competence at making this happen.

I’m not saying there aren’t perfectionists out there with an inability to share or unwillingness to let go. Just that the situation being described could be exactly as described and not just one side of a story.

I think this isn’t justified. There’s people who are control freaks, but it’s not necessarily OPs case.

In a product I delivered (I do hardware design), I helped the “firmware team” (one guy at that point) to get started because I was more experienced, and stuck helping with some small modules to get things ready for demos and things of that nature.

Later the team expanded, so I let go of firmware development and went back to my work, and the code slowly changed to the point that I wasn’t really aware of what the device did in scenario X, much less how it did that.

I still was the go-to guy when it came to questions about the device behavior for months, even if all my replies where “I have no idea, ask this people”.

All it takes is for someone to say “that guy has been working on this since the beginning”, and a lot of questions will find your inbox when others are unsure about the answer.

Early on, I did some infrastructure thing that caused me to become indispensable. My motivation for doing that was not to become indispensable, but to have some infrastructure that allowed me to a. make my own life easier, b. make others lives easier and c. show my new org that I was not entirely useless. After a while, I was moving on, I didn't want to maintain this thing anymore, it clearly did what I set out for it to do, and I grew less accommodating and started pushing back when people wanted more features.

I was able to hand it off to "nobody in particular" and explain that yes, I build the thing to solve X and it does that fine, if it can incidentally be used to also solve Y, it's great but not something I want to know about. By slowly being more resistant to changing the thing FOR people, telling them to try to do it themselves, and less inclined to answer questions, and more inclined to ask them what they tried and suggest what they may investigate next to find an answer, people have stopped asking so often, and I no longer consider myself indispensable. I know they will have a hard time doing some changes if I'm not around, but not impossible, and if one day I leave, enough other people have touched the stuff that, even if it "was mine" it's now "ours".

The strategic minus for me is of course that I'm not indispensable, but on the positive side, I can now actually do my job instead of babysitting my skunk-works projects.

> By slowly being more resistant to changing the thing FOR people, telling them to try to do it themselves, and less inclined to answer questions, and more inclined to ask them what they tried and suggest what they may investigate next to find an answer, people have stopped asking so often

The general principle here is that we teach people how to treat us. If we're always bending over backward to help someone without expecting them to put in the effort themselves then we're teaching them it's OK to behave that way.

Just asking "What have you tried already?" teaches others that they're not allowed to put in zero effort. Saying, "No, I won't implement that feature." teaches others that you're not a pushover.

This is exactly why companies offer sabbaticals. It forces you to train people up on your five years of knowledge before you leave for 10 weeks.

OP could have just taken a long vacation.

Maybe... but not all companies offer sabbaticals / extended leaves of absence with a way to come back.

No but if they don't then OP should have just put in for a long vacation to make themselves dispensable again.

Many American companies only give 2-3 weeks of combined sick + vacation time, which isn't really enough for "a long vacation" - furthermore, many companies have a "use it or lose it" and don't let you roll over PTO.

Long story short, it's impossible to take a long vacation while working for many companies.

In my experience companies offer may offer sabbaticals, HR may promote them, the documentation may be shiny; but it is career suicide for anoyone who hasnt already made it to the top.

Unlike leaving for a competitor and coming back for a 25% higher salary?

That there is a driven go getter (although not featured in the employee handbook).

The worker on sabatical is just a lazy bum who cant be bothered to go to work (or an hard working inspirational visionary C suite executive).

You must have worked for some awful companies. Everywhere I've worked the sabbatical was highly encouraged and the people came back refreshed and often got promoted soon afterwards.

Tech employees really do live in the most hilarious bubble.

Anyway, at my company (F500), if you take over 30 days unpaid, you need to reapply for your job.

I have never worked for a company that offers sabbaticals and I'm fairly certain I don't even know anyone that works for a company that offers them. I've never met anyone who has mentioned taking one either. AFAIC, they aren't even real.

14 Companies Offering Sabbaticals: https://www.glassdoor.com/blog/42136-2/

77 Companies that offer sabbaticals: https://fairygodboss.com/career-topics/sabbaticals-77-compan...

Sure the top 100 countries in the world offer them, and the other 50 million companies don't.

The list I posted is certainly not exhaustive. Many companies offer them for the exact reason I stated above -- so they don't come to rely on a single worker.

10 week sabbatical - dare dream bigger, imagine a 52 week sabbatical </snark>

I actually took 3 months off and completely disconnected. A large portion of my direct team churned while I was off, a long time engineer took his own life, and I came back to the same issues but magnified.

Overall, it's not unreasonable to assume I'm a control freak and couldn't let projects go. However I'm a big proponent of letting fires burn and I delegate to no end. My particular type of stuck was exasperated by a corporate culture that has sales quotas pulled out of the air and implementation that was tracking time down to the minute because 90% had to be billable. In that culture there's no incentive or ability for individuals to learn.

Way too much specific knowledge about code/processes doesn't translate well across firms. If you view being indispensable as a formula for job security, rather than doing that for code/processes, do it for business knowledge. You'll still be considered very valuable, you'll get a lot more exposure/recognition to/from the decision makers, your deep knowledge will translate across firms and you'll be considered more valuable the older you get which, instead of having to deal with ageism, will open up more avenues like switching to being an expert consultant while having the freedom to be choosy about the kind of projects you do.

Of course, this hinges on the requirement that you actually care/like knowing about the business side of things and are willing to spend the time/effort towards learning (which isn't super common among techies). Sometimes, the opportunity simply isn't there or not encouraged.

and this job you describe is the CEO (or CTO, or whatever CxO level people).

It is indeed indispensable - a firm shows a poor signal if they have to switch CEOs, or one gets fired, or resigns without a good replacement.

The problem is that there's usually only 1 CEO to a firm, and not everybody can get to that level.

Where is this company where the C-suite has the only people who Know The Business and everyone else is just a coding monkey?

Maybe at a tiny startup, but outside of that, I wouldn't expect to see it.

Manufacturing. A lot of times the guy invented and built the product himself along with the rest of the business over the years.

How would you go about learning the business side? Coming from a more business oriented team, it’s something I definitely struggle with.

I used to work in sales and I remember one of my coworkers who was a really good salesperson, but they wanted to get off the sales floor. They had enough and just wanted to move on to a managerial position. The pay was about the same, but the hours were better and it was easier to get time off.

He had applied to openings twice and each time one of the "lesser" salespersons got the job. When I was leaving I asked one of the managers why this person wasn't getting the job - they had experience, they had loads of knowledge, they had solid people skills and excellent sales figures. The answer was - "we can't lose him as a salesperson".

It kind of stuck with me - what happens if you're too good for the job you have. What happens if you've "overfitted" yourself to the current role... It's one of the reasons for which every year or so I start getting an itch to try something new. A new company, a whole new role within the same company, just something else. In the last 8 years I had 9 jobs at 7 companies and each time I got a raise, I got more interesting projects, I managed to do more interesting work and met a bunch of new people. I know this isn't for everyone, but I know I'd never want to be indispensable. I want to be replaceable as that's the same rule I apply to my roles. Really good read and I'm afraid I'm seeing another person like that in my current role...

I lived the same life as described - ran with one product for a decade, from initial thought to acquisition, and was the center of knowledge. I had a different tactic to get out of it - documentation. Not just written, but I made a series of videos to take someone from having never heard about the problem space all the way up to how we solved, why we made our choices, how the current system works, and what our long-term vision is both for features as well as lessons learned.

When we finally did get a new acquisition and a new product leader came in, I was told that those videos made the onboarding to the product so easy. No meetings, no schedules, no weeks of questions... just sit down and watch and they were up to speed enough to engage with the product. I still had detailed knowledge they needed to ask about, but I was not "indispensable".

Ugh, videos.

You were probably right to make them though. A lot of people seem to be as bad at reading as I am at listening to meetings.

The neediness of Sales folks is relatable. I worked at a company where Sales thought "@channel" was a person they should ping as often as possible.

And no amount of documentation solves this because documentation is useless if it can't present itself at the time of need. Because rest assured, no once (including me) can find anything using the horrible Confluence search.

I treat the awfulness of Confluence's search as a feature. It forces me to organize and cross-reference documentation.

Interesting take on it. I like it.

But sadly this solves it for the people relying on your documentation. Not for you if you rely on anyone else's documentation if they don't act accordingly.

Confluence search is alright. The problem with Confluence is the undisciplined people who mess up their spaces to the point where the search comes up with too many mostly duplicate results, where you can't be sure which one is the latest valid version.

At my job, we use Confluence extensively, with dozens if not hundreds of spaces, and in some spaces, searching for something is a delight, while in others it is impossible to find anything without already knowing their byzantine structure.

Usually, the "good" spaces are ones with one or three "custodians" who mercilessly impose a sane structure upon the space. The "bad" spaces are always those where dozens of people create articles and sections as they see fit, without any coordination.

> ... knowing their byzantine structure.

If you need to know the structure to search, IMO the search experience is broken. Most searchers want to type topic related words and expect useful results.

Yes, but that's because the space contains so many duplicate or almost duplicate articles that search results have no chance of being good. I see the problem in the searched content, not in the search engine itself.

The internet also contains "so mamy duplicate or almost duplicate" articles, and yet Google can provide a useful search for Internet articles. You're telling me it's somehow impossible to achieve the same thing for a company's intra - even though it has several orders of magnitude fewer articles to index?

One quick and easy way to improve Confluence's search would be to rank often-visited articles higher than rarely-visited articles.

I would hope that going by popularity is something a search engine WILL ABSOLUTELY NOT DO in a corporate setting. This is a completely different scenario than what we have on the public WWW, so unless your corporation has a situation where people maliciously copy articles from others, trying to pass them off as their own content, in which case the search engine quality is the least of your problems. :)

Anyway, as I've already stated, Confluence spaces which are well looked after and are not allowed to get cluttered are a delight to search in, and as a bonus also a delight to just browse through.

P.S. Google Search results are often lousy and full of low quality results anyway, I'm not sure mentioning it makes your point as well as you think it does. As everywhere - crap goes in, crap comes out. :)

Personally I haven't seen "well looked after" Confluence spaces. I have experience with 4 different companies that used Confluence for their infra, and in my experience it has always been a mess. The reason I advocated for ranking by popularity is that those messy Confluence pages are filled to the brim with obsolete outdated articles that nobody intentionally visits. For example, in many firms people post meeting notes to Confluence. So you have 10 000 pages of quality "notes from project abc weekly meeting 5.4.2014". Now, imagine yourself searching a Confluence space like that. You type in a particular phrase, and there is a perfect match in meeting notes from 2017, a perfect match from preliminary design document from 2013, etc. These results constantly drown out the actual pages you are searching for, which are typically more actively-updated, more recent pages. It would be a huge improvement to rank these pages higher purely based on their popularity.

Search is great if you already know the answer (all search does is match answers to pages).

Search is not a substitute for good documentation. Neither is "read the code" or "you should just know", which are the most common answers I get from developers.

> The neediness of Sales folks is relatable.

This is a symptom of bad communication.

I faced some of these issues in a company, and the best solution we found was creating a massive “FAQ” single page where (browser) search could get you what you wanted, and a firm policy that any question asked should end with a modification to the document.

All questions had to include the search terms used to find the answer, and if it was a “failure to find”, those search terms would be included in the “related tags” section of the question for next time.

> I worked at a company where Sales thought "@channel" was a person they should ping as often as possible

I find some people just don't know (or care about) the right way to use Slack. They need to be taught "Hey, don't bother 100 people in this channel for your niche question." Some are oblivious, some don't care about other people. Either way someone needs to pull them aside and say "stop it".

Having management that allows that to continue indicates an unhealthy organization.

Slack actually pops a dialog when you message @channel or @here.

Message says, e.g.:

  Using @here pings everyone in the channel who's currently online.
  It's a bit noisy! Are you sure you want to send this?
  
  [Edit Message]  [Send]

Of course it doesn't always help!

Good point. I use @channel or @here so infrequently that I didn't remember that.

How did they make the Confluence search be so horrible? I once searched a page title without noticing I was already at that page, and it couldn't find it. I literally copied the title in and it still didn't find it. truly an awesome (as in awe and fear inspiring) piece of software.

It might be an effort to make Confluence truly enterprise grade.

It's called the Technical Ghetto.

The basic problem is technical folks who are too good at being technical to be allowed to do any management or less technical stuff.

I've seen it time and time again in my career. I've discussed it at length with colleagues and peers. I've seen very few people escape it. Only once have I seen someone escape it without moving jobs (new company, not in-company). And that one time was due to a succession crisis which meant the person in question had to be promoted into a more senior management role.

The absolute classic was a guy I worked with at a major international telco. He was promoted into country CEO role. 3 months later and he was moved to be CTO in another country because they couldn't find anyone else competent to take the CTO role during a major rollout. He called me a couple of years later - he is now CEO of his own SAAS business, and very successful.

What is his saas business out of curiosity? Seems like it could indeed be very successful with this experience

This is why teams should run people game days to test their resiliency to organizational outages. Unavailability: force team members to completely disconnect for a day. Consistency: if a team member ask a question about a process that should be documented in a runbook/TSG, instruct them to sometimes answer it incorrectly. Latency: delay responses to email/IM questions about live-site processes by 24 hours.

Isnt this called paid time off.

Yes in part. But I like the more random aspect to it as well as the additional dimensions.

It trains people to not rely on @xxxx in slack (or any other tool for comm). It trains people to write better documentation as they will receive unhappy messages from coworkers if it wasn't clear. And it trains people to RTFM first.

At least - there is a chance it can do all of this.

Many banks, and perhaps other organisations, check for indispensability by means of a mandatory vacation policy. If one is indispensable then it should become apparent when they are forced not to work, log-in or reply to emails for this short period. This policy might also pick up other issues such as some types of fraud that might require constant attention (e.g. hiding evidence as it appears).

I had an eye-opener when at one of my previous jobs I was on scehduled vacation, but just dropped by in the office to pick up some things I left there. My boss was sitting at his desk, saw me, and instead of giving me a work related chit-chat immediately proceeded to tell me: "What are you doing here? Go away, you're on vacation so go and have some fun and rest, we can handle this. I don't want you to hang around in the office when you should be vacationing instead. Go!"

After that I've always judged all my superiors to according on how they handle situations like that and I've been trying to act the same, respecting the time off of others.

Hah, I had the same. It’s now my mark of a great boss, but unfortunately I haven’t found anyone similar yet.

I’ve now emigrated, but if I ever move back I’d happily work there again.

He was a great boss indeed. We didn't click on personal level, but he was good leader and I respect him even more because he didn't need to be buddies with people in order to have great work relationship.

"There was no career path. Sure my title changed, pay went up, but my day-to-day never changed."

Sounds like a career to me. At least that's how most of them work.

Agreed. A lot of people seem to think that infinite growth is sustainable, even by a single person.

When I was last interviewing, I kept getting asked, "Where do you want to be in 5/10 years?"

When I answered that I wanted to be programming (the thing I was applying for) they all asked if I had no ambition.

I told them that I've already met my ambition. I've got the job I want, and I intend to keep it. I didn't want to be a manager, and I didn't want to do things other than programming.

Of course, it's impossible to do only that, but over 10 years later I'm still mainly programming as my day job. I'm not at a "dead end" in my career. I'm exactly where I wanted to be from the start.

"A lot of people seem to think that infinite growth is sustainable, even by a single person."

Including my managers/company. Always pushing for personal improvement in the form of the next level. Of course personal improvement can be continuous excluding the levels, like in learning new programming related stuff (designs, tech, algorithms, etc) or business/product related stuff that you're implementing.

"asked if I had no ambition"

I was (still am) a midlevel dev. I was performing the work of a tech lead for a year, followed by a year of filling a senior dev role. I had a skip level with the department head. When they asked me my 5 year plan I said I just wanted to be a midlevel dev. I mean, that's the best I can hope for if they simply won't promote me after years of performing above my level. Huge mistake. They labeled me as having no ambition. I had to switch to a different team/department so they wouldn't fire me.

Early career me thought that being indispensable was a good thing for career safety and leverage for promotions and whatever else, but that turned out to be far from the truth.

In my experience if a company is so incompetent as to allow a single person to genuinely become indispensable, they're also so incompetent as to barely know it, and do nothing about that person leaving.

Only after leaving will the fires really begin (or intensify), which is probably just a variation on business as usual anyway.

Nobody will defend your time if you don't do it yourself. Company's will take-take-take from your time not because they're malicious but just because they need to get stuff done and the monolith of a corporation doesn't pick up on nuance and feelings at a micro scale. I've seen this play out time and again, particularly with people who always want to be responsive or helpful. They burn themselves out.

Fwiw the teammates whom I consider to be the most indispensable are not the ones who know the most details. They're the ones who are the most adaptable and able to take on more responsibility and lead with creativity and urgency. This typically means that they're good at defending their time – they often have the indispensable knowledge that the author writes about, but only pull it out when they really need it, because they know that their real value add is in scaling themselves and their teams.

(Also fwiw, I've had a very similar career trajectory to the author based on the article's first paragraph so I feel like I understand the signals that they're writing about)

In any job; you are not indispensible. You may think so, or others may tell you so. But you are not. You can easily be replaced. It is just a question of cost.

And while it is fun to fantasize about snarky comebacks. Don't do it.

In ten years time, no one will remember what sort of professional contribution you made. But they will remember whether you were nice or not.

Be nice.

Chris Espinosa at Apple gave a talk at MacHack years ago where he gave this sage advice for staying employed there:

> Be indispensable but obscure.

In other words do a necessary job nobody else can, but not the job that is the bottleneck for everyone else.

This advice of being “so good they can’t ignore you” is better applied to the industry as a whole than a particular company. Since employees are dispensable and the average tenure is a short two years, it’s better to have indispensable skills for your industry so that you can easily find a new job at a higher salary or title.

Quite interesting. I have learned to make myself useful by making myself redundant, as in the team won't be on fire if I leave. I think it is good to be valuable because you do good work but not so much that if you want to leave for a different company you would leave your old team in a bad shape or if you want to move to a different team the move would get blocked because you are indispensible.

This post hits so close to home for me it is unsettling.

Every 4-6 months we have this ritual where everyone finally accepts that we can't have one person being the "center of the universe" and we have this almost performative process of trying to spread things around to other staff. This will last at most two weeks and then we're back where we started.

It can get pretty bad at points, like when dev's get so comfortable in relying on me to solve all their problems that they'll encounter an issue and instead of actually trying to do anything about it themselves, the first thing that happens is I get a call/text/email/slack asking me to fix it for them.

And to top it off, outside of the occasional weekend, I can't remember the last time I had a day off, but I do remember it lasted three hours before they called me to come in and fix something for them. Nowadays, I don't even bother with time off, public holidays or weekends, they aren't days off to me anymore, they are just days where I can sleep in a little longer before getting back to work.

This is crazy how much this hits home. I created a slack channel 1.5 years ago with a similar title and purpose - stop DMing me directly, there are many people that know. I got a promotion 1.5 years ago and finally was able to do the job 3 months ago. It took that long to disentangle, as soon as I would start some fire would occur or someone would quit and I'd be dragged back in.

"It depends".

Like so many things there's no hard and fast rule here. Sometimes you are best being dispensable, and sometimes it's best being indispensable.

If you're a contractor and like the work... be indispensable as it will give you more power over your rates.

If you're 12-18 months from an IPO... be indispensable as it will ensure the golden handcuff stock option / RSU shower that touches the top ~10% of engineering is extremely favourable to you.

But otherwise, there's nearly always more value to you in being someone who is dispensable. You get more freedom and support to move roles, try different things, less lock-in to a specific team, role or part of an org. Your skills are likely more transferable to other places, etc.

"It depends" is nearly always the dull answer, and the parameters for that are always specific to your circumstances.

Another risk that I have seen play out more than once at large corporations is that people who are "indispensable" and tied heavily to a particular project will often get laid off rather than moved to new roles when that project is cancelled.

The great swindle that capitalist ideology has pulled is simultaneously convincing workers that 1) they are completely dispensable ('we can replace you'), but 2) that they are also completely indispensable ('we need you'). The former keeps the worker scared that they can be fired at any second, the latter makes the worker feel guilty about quiting (or not answering their phone at 6am on a Sunday).

The amazing thing is that, depending on what the corporation needs, the worker is made to feel either of these things.

The post in the OP is the worker feeling the latter, with a twist: being made to feel indispensable to shove off as much work as possible on the worker.

What successful organizations have you built following your ideology?

I run my own consulting business and have fallen into this trap, even with all the right efforts to document, cross-train and build out expertise.

I've learned billing hourly and gradually nudging up the rate helps incentivize clients to backfill faster.

I think this article resonates with me. I am coming from the perspective of being at the same company at least longer than three years.

I had an opinion that being indispensable was a key to _something_ better, but it isn't. It started to be unsatisfying when I saw that I was being asked the same questions, doing the same set of tasks, getting the same requests (got to be on this call about a project I am not involved in because it touches something I know, "can you go on a call with the client with us?", etc. etc.) This was my burnout. My job description is not "account manager", "consultant", or anything that remotely resembles a customer-facing position, nor did I ever want to be. At least for me, this has mostly ended after taking action on it with my boss, but I still have to push back a little bit on things that take away from the focus I have now.

I came to the opinion though, through this, in comparing multiple jobs, that when someone gets trapped into that position, it is a sign of an immature organization. Leadership needs to be constantly aware that if you are in crunch-mode, the organizational debt collects a lot. There needs to be a level of de-personalization around the tasks and projects involved and if it must be personal, people need to go out of their way, with full transparency, on how others helped them.

One role I play is to work with others to understand, improve and discover what we do while making improvements. While we would grow into the position with knowledge of what to do in certain circumstances, its probably important to continue to emphasize that the end-goal is not to create more walking encyclopedias, but those competent to keep things going while pushing forward on new projects and working on new opportunities. For software development management, this has always been to me one of the harder things to do right (and no matter how much "agile" you dump into it, it is very important to create a motivation for a strong team ethic around knowledge.) Just getting through a queue of bugs is a hard thing to do that something as critical as that can get easily ignored.

Many times, I wanted to walk away from where I work now because of this, but the grass isn't greener on the other side. It will never matter what organization you are in. When you open your mouth answering a question with what sounds like an intelligent answer, the next step has to manage the expectation that you are not working on someone else's project and that you are not owning someone else's problem. Being clear on that has helped my mental health a lot when boundaries are in place.

I can relate to some of this because I like to understand how things work, like the article author said about himself.

At every job I get hit up with questions because I put in the time to figure things out. I often get annoyed if the other person hasn't done their homework before coming to me, and that comes through in my communication. Because of that, I have a reputation as someone who is "prickly" and thus someone to contact as a last resort.

Quite frankly, I like it that way. I'm still helpful to coworkers, but not so helpful that they'll ask me before finding other ways to get their question answered.

This also happened to me.

I was leading the large project, it was a core system for a financial organization.

Because of a fast pace and because of the fast growth and because of the unexperienced management, it was impossible to quickly train and delegate things to the appropriate people.

I was often getting a call from the devs, asking for help, and I was like “it works so and so, check the X file and find the Y method, that’s where you should apply changes. When you do that don’t forget to do Z.”

I was also getting calls from the top or middle level management. They were asking me things about the product specifications, marketing metrics, etc…

Literally everything “that guy” that knew everything.

The pace didn’t slow down, the opposite, company wanted to grow like crazy. I couldn’t keep up with everything. I remember I had a honeymoon in Thailand and I was literally hanging on a phone to dictate people how things worked and what they should have to do.

Things ended up miserably. The new CEO came and we agreed that I needed help with the delegation: I needed suitable people on-board and time to teach them. The process started. But it was going slow. We still had a fast pace of growth and I was trying to hire and delegate along the way.

After some time, I was accused to be a “ corporate parasite”, keeping all the knowledge to myself to be indispensable and irreplaceable. I left the company soon. Did my best to transfer the knowledge before that.

In the end, it’s been one of the best experiences I had. I grew professionally and mentally, nowadays I easily spot the problems while they become big, know who is who in a glance and so on… I learned a lot along the way.

Several advices someone might find useful:

1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.

2) Always under-commit and sometimes try to over-deliver. Depended on the quality of your management or organization you might want to over over-deliver and be respected. If you’re in a situation like this then good for you.

3) If you want to grow your organization and the team, you must learn how to delegate tasks and get deliverables, without micro-managing people.

4) In the end, its more about people and less about technologies. Your job is to understand, manage and delight people and solve all the problems along the way.

>1) If you cant align with the decision makers you either have to get used to it or move on. Mostly you have no control on the other peoples’ thoughts. If it’s broken, it’s broken. Period. Don’t prolong your decision.

This times 1000.

I write at a fairly "advanced" level. My code is well-structured, incredibly well-documented, and a blue-assed bitch to grok. It's not "lowest common denominator" code for junior devs. It's usually a hideous bouillabaisse of techniques, ranging from patterns that were around before I started (over 30 years ago), to ones that the language just began supporting, a few months ago.

It also works pretty well.

I'm putting the finishing touches on a fairly ambitious app, that has been in the works for eighteen months (frontend native app), and an additional seven months (backend server). It also leverages another server that I wrote, that has matured over a decade (and is now in the hands of a pretty capable team of high-functioning engineers). That server is a worldwide infrastructure that Serves thousands.

This means that, if anyone will take over my code, they need to be fairly experienced and capable.

You know, expen$ive. Also, they might be ... old ... Gah!

It's fairly likely that a new dev would toss out the app I've been developing, wholesale, and replace it (and the two backends) with dependency-laden garbage. They would probably do it fairly quickly. It's also likely that their code could be maintained by a staff of fairly low-skilled, inexperienced, coders.

Which is good, because it would probably need a lot of maintenance.

Now, a short-sighted, next-quarter-is-the-end-of-time manager might find the "new way" attractive. "The programmers are cheap, and we can fire them, as soon as they turn thirty!", they might say. But each of those programmers probably makes a decent chunk of change, and a lot of them, is a lot of change.

One cranky old prima donna is quite likely to be a lot cheaper, and you won't suffer brand damage, from shipping crap.

Brand damage/reinforcement is incredibly expensive/valuable, and many short-sighted folks don't appreciate that. It can make or break your company.

Keep your good engineers happy. It's OK, if they are indispensable. If they are happy, paid well, and -now, this is important- treated with respect, they can be more valuable to the corporation, than a whole bullpen full of n00bs. I ran a team like that for 25 years.

If you’re going to practice coding like some master craftsman, employing techniques that took years to hone and where every carefully selected pattern, though inscrutable to an untrained eye, carries the thumbprint of an artist at the height of his power…

Well, number one congratulations to you on finding a patron willing to fund such fine and intricate work. I hope they appreciate their good fortune in having lucked into getting such an artist to work on their project.

But number two, how do you plan on this model being sustained into the future? Have you taken on an apprentice to whom you can pass on the ancient wisdom to which you are privy and which only another equally enlightened ‘cranky old prima donna’ could possibly be expected to grok?

Where are the next generation of ‘experienced and capable’ developers going to come from if you are off working solo in your cave for… twenty-five months at a time on your masterpieces?

And where did you acquire these unique and precious skills that are not available to young developers who are, you surmise as you peer out of the cave at everybody else, only capable of producing dependency-laden garbage? Did you trek to the top of a mountain and study at the feet of the ancient wise ones?

Or did you just write a whole bunch of code, and pick some stuff up along the way?

As you sit in the corner and whittle away at your masterwork, combining thirty year old patterns with the latest language features, I wonder what gives you such supreme certainty that your mastery of your craft is such that you are creating something far above the standard others could achieve?

Because, speaking as someone who works on large team development projects, I can tell you there is nothing in the world of development that scares me more than a developer who says ‘I know this code’s hard to grok but trust me it’s really beautifully engineered’.

Well, I don't really like thinking of myself as some kind of "elite atrteest," or whatever. There's lots of people that are better than I am. I've met them, and worked with them. I spent most of my career, as the dumbest guy in the room, and I'm smarter than the average bear. It just seems that the bar for "average" is pretty damn low, these days, so what used to be considered "average," is now considered "too complicated to understand."

I'm a pretty normal chap, and I work very well, on a team. I spent my entire career, doing just that. If you want to assume that I'm a jerk, I guess that's your prerogative; but I'm not. I'm a really decent person. In another world, we might actually find a lot in common, and have a great relationship, but in InternetWorld™, we have to be enemies. Not sure what that buys you, but it's a free country, I guess.

I don't have a "patron." I'm working for free, for a 501(c)(3), doing an app for a nonprofit. It's pretty much my show. I spent thirty years, working on other people's code, and watching them destroy it, so I like working on my own code, and having it done right.

Oh, and that server that I wrote? It took about ten years, to find a team that was capable of managing it properly. When they did, it became a world standard, and I was happy to step away from it; pretty much completely. It's used by thousands of people; every day. That advanced technique that I used is exactly why it lasted so long, and was able to be localized and extended. The core code is still the ancient code that I wrote in 2008. It works great, and folks haven't found a need to change it. The fact that I can hook it into the modern app that I'm writing now, is testament to its Quality.

Also, it's free code, for altruistic purposes. I donated ten years of my life to it. It is not hyperbole to say that it has saved many lives.

If you feel that's not something to be encouraged, then I don't know what to say.

Well no, please let’s not be enemies.

So let me start by saying I have a ton of admiration for the work you’ve done based on that resume - I agree it’s a worthy contribution and you should be proud.

But please don’t mistake my original reaction as being to your actual body of work, but rather to your initial characterization of a method of delivering software.

In particular you were characterizing a development approach of ‘one hard-to-replace cranky old guy’ versus ‘a team of cheap easily replaced inexperienced devs’ - as being alternatives a manager could choose between in order to get a project done. And casting your vote in favor of, it seems, the solo craftsman.

If you are going to really recommend that people who want software developed should, in general look for a highly skilled individual developer to solo the project and leave it in a state where it will take a lengthy dedicated search to find anyone capable of modifying the resulting code, then I’m sorry if my reaction to that was to (perhaps with more sarcasm than is strictly constructive, but we are all performing for a crowd when we post on the Internet) try to suggest that that might not be a particularly universal or sustainable model.

If that isn’t actually how your project operates - with a business funding the development and having the power to choose between those approaches - then my critique doesn’t even apply to your project, so you have no reason at all to take the criticism personally. I am not my code, and I am also not the examples I use in discussions on the Internet.

Well, I'll admit that "the cranky old man" trope was a bit of a deliberate goad, on my part, but that's mostly because this is pretty much how I am always perceived. It's really sad, because it's very far from the truth, and, if people spend more than thirty seconds, skimming what I write (and I know that I'm prolix), they can figure out that's not me. If you check my LinkedIn, you'll see a ton of testimonials, from folks I've worked with, over the years, saying how rewarding our relationship was.

I will admit, 100%, that I'm a "Quality nut." I consider my work to be a craft, and I take tremendous personal pride in it. If it requires advanced techniques, to achieve the ends, then that is what it takes. I generally don't even bother setting up a bug tracking system for my work, as there are so few issues. GH Issues is generally fine.

I will also admit, 100%, that I'm pretty appalled at what passes for "quality code," these days. I won't go ripping into the works of others; especially if it earns them money, and people are willing to pay for it, but just because everyone else does it, is no reason for me to do it; even if it means that I do it alone.

The project that I'm working on now, I describe as "ambitious." That means that it is "ambitious" for me[0]. To many folks, they wouldn't even dream of a single person, writing something of this magnitude, but I do stuff like that, on a regular. I've been shipping stuff, for my entire adult life. Because it was written by one single person, from napkin sketch, to shrinkwrap, it has great integrity, and extremely high Quality.

There's good people out there. There always have been. They do great work; usually orders of magnitude better than "average" work. It's worth it to track them down, and to hang onto them.

I managed a guy that is "on the spectrum." He could be difficult to manage, but we worked together for almost 27 years; 25 of which, I was his boss. He was better than I will ever be, and still is (just not working for me). It was a privilege and an honor to work with him, and to have him as an employee. He had a high school diploma, and regularly stunned the Ph.Ds in Japan, with his work.

It, too, was pretty inscrutable code, but it was also often 100X faster and more accurate than stuff done the "average" way.

[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...

So much of this rings true and is familiar. When I was first part of an acquisition, being the technical owner of a bespoke sales stack brought a ton of security while I was also told about the opportunity in the larger organization. Fast forward 18 months and the opportunities were not available because I was on the hook to answer the same issues over and over despite documentation and process in place…

My experience has been:

1- redirect to another engineer.

2- keep track of the convo. If it is going off the rails help the engineer get back on the rails

3- if the engineer cannot help, jump on a call and explain to the engineer how to help. Then let them help.

This is how teams grow. This also let's you, the technical leader, inject yourself and assist the team without being the only source of truth. And also you become trusted.

Win. Win. Win.

I used this exact tactic with a developer that refuses to use google recently - there's only so much time you can individually give one person...

Commenting to say that I relate to this so much and finally resigned after 9 years, a few months ago. 4 weeks left to go on my 6 month notice period and I couldn't be happier! When I resigned I felt like such a huge weight had been lifted. I was stuck, lost and like I was worthless. Nearly all the points in this article ring true for me.

This was me, given a variety of factors I ended up being lead on a big project right out of uni. We did end up shipping the product, in a state that could be discussed how well it went, but what do you expect from a fresh graduate.

On one end I learned a ton, and probably the most important, how to deal with responsibility and pressure. But at the same time I can really see myself in this article, I ended up choosing another road, I was bored with the product, but the company didn't want me to switch to a different product or team, and my team itself was treated like dirt, so I ended up leaving.

I really tried knowledge sharing and getting others to be independent on the product, but we didn't have the right people, and the culture of the company simply didn't value that trait in newer hires.

I could have made so much more money if I stayed, but it is still far to early in my career to become an 'ivory tower' architect.

> I could have made so much more money if I stayed

Are you sure that isn't a bit of a "glass is half empty" perspective? There's no upper limit to how much money you can make by choosing your own path. (If, hypothetically speaking, you were inclined to pursue big $€¥£).

Definitely, my prioritized as mentioned in my post; lied with my well-being, and not just getting a pay raise, otherwise I would've stayed. It could be argued that I could get a raise somewhere else, and I also have gotten that, but not the amount I would've gotten if I stayed. I am still quite early in my career, and I am already in the upper bounds of what I can make as an employee given the length of my career (99th percentile). And when finding a new job, even when I've gotten recommendations been difficult for them to even match my old salary, simply because I haven't been out of university that long, but command a much higher salary than normal.

Would you as a product owner / manager hire an engineer that has been out of university for two years with a bachelors, given that person says he wants a senior/lead engineer salary? Honestly, from my experience even when I've gotten recommendations, talked about previous projects, they still don't want to shell out what I cost.

The plan is definitely to keep pursuing new experiences and at some point either begin consulting or start a startup. But for now I want to experience a few different companies. I also want a few projects under my belt before I begin doing that. That said I am already in the 99th percentile in my country given my length of career, so I have nothing to complain about, but I am definitely gonna keep pushing.

And honestly right now my priority is not making the big bucks, I could pursue that, but I'd much rather work on awesome projects than slave away at some legacy code for the maximum amount of money.

Alternate title: How it took OP years to realise their teammates and colleagues deserve agency.

No such thing as "indispensable". Very few companies and projects die to a singular departure, you're just not that special kiddo.

What's actually happened here is a selfish desire to know things without sharing them. If you learn something new, share it somewhere.

"People came to ask the Oracle questions only the Oracle could answer for the Oracle refused to share knowledge by any other means".

Confluence is pretty good if you use it properly. Weekly knowledge share sessions are also handy.

Learning a thing and sitting on it makes you an asshat, not an asset. Seems OP learned the hardway, but they still need to remove their ego from the equation.

You're not good at knowing things (basic human capability that), you're terrible at sharing them.

You can lead a colleague to documentation, but you can't make them think.

It doesn't sound to me like knowledge is being hoarded here; it's all there for the taking, but OP's colleagues have discovered it's more convenient for them to ask OP rather than seeking it out for themselves.

Maybe that's an issue with discoverability, or maybe OP has a history of being too available for questions. Sounds to me like OP might in fact be sharing too freely, thus making documentation/experimentation less attractive.

> You can lead a colleague to documentation, but you can't make them think.

You can point them to the docs that answer their repeat questions rather than spending time to write a unique response every time. Author writes that this worked when the questions and answers were made available to others,

> One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.

You make a pretty grand assumption here - that OP had time/capacity in all the madness to be able to document things and simply opted not to.

You also gloss over the fact that he addressed this in the article (things were documented, people just kept coming to him anyway).

Kinda seems like the author found a working solution- public email, aka a forum:

Very few companies and projects die to a singular departure

While I've never seen a company die due to a single departure, I've seen plenty of projects die due to a single departure.

I don't like how you're blaming the author of the article here. My experience is that people, be it from the business or from the Product team or Sales or wherever, are happy to ignore documentation and come directly to the person they see as the knower. You can document all you like, they will still come to you and you are the bad guy if you don't answer them and point them to the wiki.

Do some people exist who don't share their knowledge? Definitely. In fact they are rewarded in many cases because they get whatever they want (usually outside of a higher salary)

However, author wouldn't be writing an article like this if he was happy in that position.

There is a difference between having power and being indispensable.

Power enables you to delegate whereas if you are indispensable but leadership has no idea what you do, you are powerless and stuck.

It's not fair that power is determined subjectively and largely politically, but it's the reality we live in.

We are not indispensable even to human relationships we assume we would be (forever and ever), how come we consider ourselves indispensable to legal entities like companies?

This was a rhetorical question, i have done that mistake in both occasions. In the case of companies, it isn’t even worth it.

> I was a sentient wiki

Busted up at this point.

But seriously, this is me, though to a lesser degree (this guy sounds much awesomer then me).

10 years ago, I exited a shrinking technology community. I loved it, but the signs were on the wall. I knew I’d be one of the last ones to turn out the lights. I was just past 41. The prospect of looking for work at 50+ with guru expertise in a Cobol like technology terrified me.

There seemed to be two basic paths at the time. Embedded or web. It seemed like web development was getting commoditized, community college grads earning $17/hr to hammer out a web site for the local pet store. Embedded seemed more lucrative, and I had a decent level of C competency.

I made a choice to become a polyglot as well. I would embrace the “best tool for the job” mantra, and avoid being pigeonholed by any single technology.

An opportunity in our small community opened up to be somewhat entrepreneurial for a medium size company and I jumped in. Our number of participants is no where near as large as the article. 10 at most. But 10 years later, I’m indispensable. I own the embedded C code that runs the 3 different node types on a proprietary LoRa network. The protocol that communicates with the edge device that runs embedded Linux, running multiple systemd services, the uboot configuration, the cooperating Python programs, our own BLE driver from said Linux board, the MQTT and BLE communications schemes and binary json like protocol that communicates to apps. The Kotlin code that runs the two apps. The horror that is working with BLE on Android. The objective-C then Swift code that runs the same two iOS apps. The elixir service that transforms MQTT traffic to swaggerified API. The ansible scripts that configure our servers. Etc. I try to document things, write good code, unit tests, but there’s still a huge amount of “how it all fits together” and “we tired that, don’t want to go there” knowledge in my head.

I have enjoyed learning all these things and more. But I regret I never get the time to get really good at any of them. I regularly experience tuple dysphoria (“how do we do tuples in this language again?”) and other similar “why do all of these languages need to do the same thing differently?” And feel like I always probably need to go figure out how docker works or some other new thing so that I can keep pushing our product offering into new and exciting places.

And like the fine article, I am well remunerated, I am indispensable, I don’t know if I can keep this up til retirement, and it’s kinda lonely. I don’t see a way out. People want to pay $120K for a dedicated Elixir developer, not 180 for “does a lot of fricking things kinda.”

A couple years ago, we hired someone to “help Travis” but it didn’t work out so well. I’m still trying to figure out why.

(I should add that there’s still interest in hiring another body to participate in this madness of polyglot indispensable-ness, if such a thing sounded appealing, email’s in the profile)

To me stuff like this sounds lovely. But sadly I am neither proficient enough to be anywhere near the level of what you need as a "help Travis" person.

I am my own kind of JOAT (jack of all trades) thing. I do mostly data work. Mostly web stuff. Nowadays a lot of strategy, architecture but also still implementation, JS work, python, ETL. Currently building an internal system next to client work for our team to have a play ground. So setting up a fake online shop with fake traffic (selenium) so that the web analysts can try out new tools with somewhat realistic levels of traffic and see if these tools might be something that helps clients solve their problems.

I love the fact that I have colleagues who do parts of that stuff and from whom I can still learn a lot. And I like the diversity of it.

But I agree - regarding the technologies I use there is a longing for "the time to get really good at any of them".

That sounds a lot like my current situation (though awesomer in turn than me). I'm doing everything from servers to microcontrollers, Android barcode scanners to power tools, running network cable to restoring antique lamps (really!). Trying to keep syntax, data types and structures straight in Python, PHP/HTML/JS, and Arduino/C++. Maintaining the network of security cameras. Sometimes database stuff too.

This is a dream job for me but I wonder where I can possibly advance from here. I know they don't (can't? won't.) pay enough for me to be able to afford to stay here forever. And I'd really like to work with a team instead of being the only person who can do a bunch of things.

I had a helper too for a while and it was awesome. But they moved away and I've been struggling to keep up. I tried training a few other people to help and they weren't really into it. It did at least force me to come up with some better documentation.

I wonder if this is where most developers end up getting. You can stick to being good at one language/ecosystem, but the more you age the more things you learn and unlearn, the more components and scope the company adds.

> [...] I had to stop understanding [...] This was huge. I could legit say ‘I don’t know’ to all questions, and redirect people to the correct resource. If that resource didn’t exist, it was escalated to someone other than me.

This is called learning how to delegate. It's great that the author discovered it.

An alternative tactic people follow when they still like to know the details is to apply "strategic incompetence": https://www.google.com/search?q=strategic+incompetence

I made myself indispensable because I did not trust the company (a small-ish games company). In the end I was left holding their bag while the rest of the company went off todo other things where the grass was greener.

In the end, I left and the lucrative project I was involved with crashed and burned…they didn’t seem to care. It was very strange. The company has gone on just fine without me, though every project they have started has met a similar fate. It was a good move to leave as the company doesn’t care about making product but rather fund raising. But hey, I got paid.

Desire to be indispensable is a manifestation of imposter syndrome which is a manifestation of anxiety. If it doesn't fade after a few months you've got underlying issues you need to solve.

In the past, I became indispensable for my employers, like the OP I had been there for a long time, had made a significant number of important technical decisions and was the go to person for any questions. On the positive side, it served me well when negotiating since everyone knew that I couldn't just walk away on the other hand, I got severely burned out but couldn't just stop since I felt some responsibility to everyone and it took quite a while to do everything to make myself not indispensable.

If you are indispensable - the most productive thing you can do for wherever your work and for yourself is probably to train others to do your job.

Corporate firewall blocked this for me (thanks, URL! :-D), archiv.org to the rescue: https://web.archive.org/web/20220316044015/https://www.sofuc...

> One of the biggest problems with being indispensable and announcing that you feel stuck, is that the business will take steps to get you even more stuck, through more money, shinier titles and stock options.

This worries me, as I'm experiencing it right at this time. No idea how to get unstuck either.

It feels like if the author was really that indespensable, they could've used that leverage to get pretty much anything they wanted out of the company. Doesn't sound like a bad position to be in to me if you're ready to have some aggressive negotiation

Recently as the only dev there was a bug/outage and I was asleep. I dream of having more than one me so I can one day sleep whenever. We don't have money so yeah... Just me.

I'm working on better back testing (some dep version went out and it broke it our stuff).

I almost see this as a hiring screening problem.

Companies need to stop hiring people that put work off on other people, and should have parts of their interview process that screen out people who are "leeches" who don't want to take initiative.

Does anybody else ever reflect on how, in our modern world, utter servility is assumed? I mean are we all serfs now? Are we discussing the best method for licking master's boot?

That's what offends me about this piece, really.

And on top of it, Agile, which has always had the whiff of "Taylorism, but from the inside" about it. Always sprinting (huff huff huff); attention atomized by checking texts, emails, phones, voicemail, and of course iterating over an ever-increasing number of Slack channels (or Teams); everything in these bitty increments of moving the assembly line along. And this has to be accomplished through a kind of homogenization, which invariably leads to replacement. But sure, let's hot desk on rows of laminate-topped folding tables for the greater glory.

> Agile, which has always had the whiff of "Taylorism, but from the inside" about it.

Isn't 'lean manufacturing" a direct descendant of Taylor and agile a direct descendant from 'lm'?

Agile might work for someone else, but I never saw it work. I saw this trying to be applied, amongst other methodologies, but the real sticking factor is whether a group of people feel like they are solving actual issues in the end. "Agile" or any methodology was a bit make-work, to fill a role that we can report on the specific progress of small things. At least for me, seeing people learning to handle issues, get through real features needed without the minute formalities has made them, and myself, more engaged in what I do. Being practical in the end gets you farther than having faith in a strict process.

> "Agile" or any methodology was a bit make-work, to fill a role that we can report on the specific progress of small things.

Agile isn't a methodology, and most methodologies described as Agile eschew formal minutiae.

The problem is, of course, that methodologies, of whatever origin, are, in practice, subject to top-down, non-Agile modification to suit the taste of managers who thrive of formalized minutiae, and, also, the starting point of methodologies for many shops isn't the original description by Agile practitioners who developed them while delivering superlative value but customized versions crafted by and marketed alongside consultants whose jobs are largely telling command-and-control-oriented managers what they want to hear.

You're right and thank you for bringing this to light. Because my experience has been trying to use that thing to solve non-problems.

I think its always been this way. Our parents told us democracy has won out, but in reality, its the same old story. People get fed ideas, of dreams, of one day, as an excuse, to serve. The lucky few are broadcaste around the clock to reinforce the general monenies stature. And dont give me no bull about "making it" from "nothing".

The only way to truely make it, is to find someone else, and jump on that bandwagon. Whether that some else is a government contract, or seed funding, or an admissions board. You rub someone elses back and hope to get your just deserts in due time.

What’s “monenies stature”?

I assume it’s a typo for something, but I can’t figure out what. If I google it I get results about money laundering, which doesn’t sound right from the context.

Am I the only one wondering what product they worked on for so long? Surely this would be helpful context but it doesn't seem to be mentioned anywhere in the article or site.

> One thing I instituted that helped was a specific Teams channel called Knowledge Transfer.

Oh, that helps explain the predicament. Teams is where Knowledge goes to die.

This is so silly — being useful should be enough, period.

My company's CEO recently called me and told me I am indispensable and gave me a 20% pay rise on the spot! Should I be worried ;)?

That sounds like you either know where the bodies are buried, or you helped bury them. D=

"The Phoenix Project" featured this guy, of course, and called him "Brent"

There is a simple answer to being stuck as indispensable for years. Change jobs.

> Being indispensable is possibly good for job security

But surprisingly little money.

This is too real for me. I worked as a college hire PM for almost 8 years at $BigTech company on a single product that got re-orged around divisions as it evolved to a mature product that would likely never grow nor disappear. I wasn't there for its inception, but a major threshold point that was enough to give me the context to maintain it with raises every two years in perpetuity.

I just got the hell out back in September. I went from the IT/cloud/DevOps automation space to running the backend for a "make everything easy" web dev -> hosting company. I'm not sure that it's better, but it's different. And it's given me enough perspective to know for sure now that I probably should've gotten out two years ago. Pandemic perspective and all that.

Something something this XKCD: https://xkcd.com/1768/

I cited it as I stayed....

I joined a company on a short-term contract, "for a month or two", to help out a friend and solve a few problems. Which became a four year engagement.

I became "the go to guy" for anything and everything related to a particular project, and the DevOps for that project, and eventually the DevOps+CI/CD guy company wide. But I also had to work on an assigned project as Lead Programmer, but never got any other programmer assigned to work with me.

I shipped two company critical products by myself, front-end, iOS & Android mobile app and backend infrastructure. I made significant contributions in the form of code to other teams, I ensured the company wide build-systems kept humming along and was 24/7 on-call DevOps for two years straight with no backup. At one point I literally had five separate managers that I reported directly too that each had their own competing needs.

Every couple of months I had a conversation with a higher up, and every couple of months I was told "there's no budget, it's difficult to hire, you do it so well, and we don't trust anybody else to do it, and nobody else wants to do it."

There was no promotion, no prospect of advancing, didn't receive a single pay increase in four years, "but you're so well paid already, there's just not the budget for that this year, we see you as more of a cost center than a profit center." And every time I was ready to quit, a few "friends" at the company talked me down off the ledge, who I later learned were being prompted to do that by upper management. It was a classic abusive relationship. I realize that now. And I fell for it.

When I started to have issues with shipping a product as both the Lead Programmer (mobile apps, fron-end, admin interface, backend infrastructure and API) and also be project manager and interface directly with a demanding client, including doing on-call 24/7 DevOps with no backup, and wrangling the company-wide CI/CD system, the project I was building, that should have been a five person team in reality, I was assigned a "tough manager" to set me straight and get me back on track. This was literally the conversation I had when the manager sat me down in a conference room, "I'm here to make sure you do what you need. I'm giving you some tough love. And I'm going to ride your arse until I see improvement." Now this manager was not the project manager, he was specifically assigned to manage my output, and after a month he went back to the execs and said "Justin isn't the problem."

This manager put up signs at the end of the cubicle row that said "If you need to speak with Justin, talk to X first." And people would ignore the posted signs, ignore that I had headphones on, and still interrupt me, and then my Manager and whoever was interrupting would get into an argument, right at my desk, over how urgent their request was. I eventually got moved out of that area to a "quieter area" near the IT guy, which unfortunately meant then people would come by his desk and have loud conversations about an IT issue, and when the IT guy wasn't around, would interrupt me to ask if I knew about how to solve problem X on their computer.

When the stress is so bad, and I have an outburst where I am screaming at my tech director to go fuck himself in the middle of the hallway, and they still won't fire me, an outburst I am not proud of and would never ordinarily do (I'm kind of a Mr Rogers & Ted Lasso until you hit the wrong button), you kind of get the idea of how indispensable they viewed my position. The outburst was over five people having a meeting directly at my desk, that didn't actually involve me, that was very loud and racous, and when I repeatedly and politely asked them to move their meeting elsewhere I was informed that I need to be more understanding and empathetic towards people's needs.

Coronavirus came along, everbody gets to WFH, which gives me breathing room to think, I start looking for a new position, the company hits a financial tough spot and decides they can do without me, which is like a great weight that lifted from my shoulders. I took three months off and built a few side-projects and was so much more productive than I had ever been in the past four years. https://www.linkedin.com/pulse/three-months-side-projects-ju...

I was still getting messages and urgent emails from people at the company four to six months later, on an almost daily basis regarding the DevOps and CI/CD pipeline. Everything had been documented, nobody wanted to read, it was easier to send me an email even though I no longer worked at the company.

I used to love being "the go to guy" but I've since learned, "don't ever be indispensable."

Unfortunately, history repeated itself at the following company, and is starting to repeat again. Maybe I'm the problem.

I always try to de dispensable. We have weekly KT. And we take turns in doing Ops. We also do KT for others roles. As a rough example, we have DBAs, but we make sure devs know how to do the basics of their work too. Whenever you do something someone else can't, assign someone else for next time immediately. Never do the same job twice. It seems faster do just do it, but it's not as soon as the third time happens.

But the real trick is test frameworks that give you rapid access to test all areas of the system with new code or inputs. So if the question is "what if?" The worst case answer, if I am not there, is "try it". N.B. You must be able to test performance impact. This is expensive, you need prod support systems you can hack at and put back to the original config quickly. The ability to restore any test system to a know state (even systems you don't know much about) is critical. So you can try stuff out and then leave it how it was.

In emergcies when there is no time to test. Experience matters. If you are answering "what if?" with "try it" people get experience. It seems faster to answer "what if?" with "I am sure that" but long run that results in two problems, knowledge silos, and a delay in answering until you are at work or awake. That can kill you, especially if you are expert in more than one thing.

If you want backup in a multinational company that runs 24/7 you need one person to answer any question in each timezone. If you can answer a question "immediately" but others can test the theory in 12 hours, that's often faster. You need sleep. In a small company you may not have 24 hours resources, but if the questions cost more than a wage in a foreign company, hire people. Even for day to day stuff this enables you to work around the clock. Get managers to do the math and presume answering any question or doing any task is never immediate, on average its >12 hours, because sleep.

It's also good to avoid doing what you know best (that's hard) but it's better to tell people how, than to do it. If you want to avoid questions, don't just tell them how, tell them why, and how you found out.

There is a social problem to deal with too. Often people think something is "not my job" deal with that early with collective ownership of the whole solution.

There is a problem of permission, sometime only DBAs can touch the database, work on that by giving confidence that others can do DBA work in test systems.

There is a real problem that some people try to be indispensable for their own job security. Fire such people early, or move them to new roles in the company early.

People are generally as smart. They will learn given learning opportunities. They will want to learn if the alternative is 12 hours of testing!

wow... this is so familiar.

not surprising really.. I've been with this company for approx 17 years now.

Hotel Dev Inn, a luxury hotel in Somnath with sea view is well known as a great destination for the tourists as well as devotees visiting Somnath and seeking for a comfortable accommodation with a sense of luxuriousness!!

What else would they do if they weren't answering questions? Write some more CRUD code? I don't know what this person wants or what they expect their job to be. That's probably the underlying issue.

In the article they said

> I had a hard time thinking strategically about product. I was too busy supporting the entire organization on all things related to the product.

so that's a pretty clear indication of what was missing. Instead of being able to recognize broad industry trends and come up with broad product evolutions that meet those needs, this person is stuck answering quibbles about particular customers or particular implementations.

How about his managerial duties? Being constantly dragged into unrelated meetings will make you soon burned out and i think most people with management experience can relate to his writing

Reply on news.ycombinator.com