Live data from Hacker News

On Being Indispensable

sofuckingagile.com

31–40 of 296 posts

Re: On Being Indispensable

#31
post #27

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

100% this. A lot of wisdom here.

Re: On Being Indispensable

#33
> I was a sentient wiki

Busted up at this point.

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

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

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

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

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

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

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

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

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

Re: On Being Indispensable

#34
post #10

In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it." The best advice I got starting out was, "be indispensable." The best advice I got four years later was, "don't be indispensable." In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned…

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

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

Re: On Being Indispensable

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

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

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

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

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

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

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

Re: On Being Indispensable

#37
post #10

In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it." The best advice I got starting out was, "be indispensable." The best advice I got four years later was, "don't be indispensable." In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned…

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

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

Re: On Being Indispensable

#38
post #24

Earlier quoted context omitted.

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

Yeah I'm not sure that's meant to be taken literally, anymore than I think "If you meet Buddha upon the road, kill him," is an incitement to homicide. The people who have reverence for the heroes are as much or more of a problem as the actual heroes, and they need to be shaken severely. It's going to be ugly any way you slice it because like so many things in software, you're in a position where someone should have y…

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

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

Re: On Being Indispensable

#39
post #21

The neediness of Sales folks is relatable. I worked at a company where Sales thought "@channel" was a person they should ping as often as possible. And no amount of documentation solves this because documentation is useless if it can't present itself at the time of need. Because rest assured, no once (including me) can find anything using the horrible Confluence search.

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

Re: On Being Indispensable

#40
post #10

In the spirit of the old saying, "the two happiest days of a boat owner's life are the day they buy a boat, and the day they sell it." The best advice I got starting out was, "be indispensable." The best advice I got four years later was, "don't be indispensable." In a growing company, the indispensable people may find themselves being left holding the bag while new initiatives are undertaken. I very quickly learned…

> If given the choice between "my company would be just fine without me" and "everything would fall apart if I didn't show up to work, I found the problem. It’s not “your company”, it’s “the purchaser of your time and attention”. Act accordingly.

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

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

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

Post reply on HN