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.
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'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.
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.
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.
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.
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?
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.
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.
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]
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 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.
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.
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
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.
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.
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.
OP could have just taken a long vacation.
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.
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.
Isn't 'lean manufacturing" a direct descendant of Taylor and agile a direct descendant from 'lm'?
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.
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.
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.
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.
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".
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.
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.
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.
> 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.
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.
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.
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.
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 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.
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.
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...
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.
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.
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.
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
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.
This worries me, as I'm experiencing it right at this time. No idea how to get unstuck either.
I'm working on better back testing (some dep version went out and it broke it our stuff).
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.
Oh, that helps explain the predicament. Teams is where Knowledge goes to die.
But surprisingly little money.
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 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.
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!
not surprising really.. I've been with this company for approx 17 years now.