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.

"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).

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.

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.

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 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.

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

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.

“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)

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 $$$."

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.

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?

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.

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.

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.

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.

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.

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..

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.

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.

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.

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.

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.

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.

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.

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.

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.

I like smaller proof of concept + training type projects.

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.

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.

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.

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

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.

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.

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.

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.

This are 3 different things.

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.

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.

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.

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.

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

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!

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

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.

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.

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?

Easy, right?

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.

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 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.

You can always do that.

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.

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.

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".

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.

* time outside, contemplating nature and purpose

* a hug from a family member

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

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.

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.

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.

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

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.

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.

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).

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

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

"between"?

Loyalty towards employees almost never existed in some societies.

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.

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.

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.

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.

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.

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.

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.

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.

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.

OP could have just taken a long vacation.

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).

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

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

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

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.

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.

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.

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

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...

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".

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.

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.

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.

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.

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.

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.

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.

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

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. :)

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.

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]

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.

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.

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.

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

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

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.

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.

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.

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)

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.

> 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.

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.

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.

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.

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

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.

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.

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.

This times 1000.

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.

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’.

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.

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.

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...

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.

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.

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 $€¥£).

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.

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.

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 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.

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.

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.

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

> 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.

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.

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

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)

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 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".

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