Live data from Hacker News

On Being Indispensable

sofuckingagile.com

141–150 of 296 posts

Re: On Being Indispensable

#141

Earlier quoted context omitted.

Agile might work for someone else, but I never saw it work. I saw this trying to be applied, amongst other methodologies, but the real sticking factor is whether a group of people feel like they are solving actual issues in the end. "Agile" or any methodology was a bit make-work, to fill a role that we can report on the specific progress of small things. At least for me, seeing people learning to handle issues, get t…

> "Agile" or any methodology was a bit make-work, to fill a role that we can report on the specific progress of small things. Agile isn't a methodology, and most methodologies described as Agile eschew formal minutiae. The problem is, of course, that methodologies, of whatever origin, are, in practice, subject to top-down, non-Agile modification to suit the taste of managers who thrive of formalized minutiae, and, al…

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

Re: On Being Indispensable

#142

Earlier quoted context omitted.

I would say your assumption here is unkind and itself lazy. I have often seen this kind of situation and the cause has always been the same: The most senior in the organisation are ridiculously poor at building their org. They have hired someone who is pretty great at stuff and they got them by accident, for cheap due to some circumstance, and now attempt to grow without realising they got lucky. They hire net negati…

If everybody around is relatively incompetent, then the superstar at the center can't fix that. The overall result that the org produces is based on everybody and eventually "regresses to the mean" of what everybody contributes. Management and also the superstar need to accept that. I write "relative" because it's a matter of perspective. Maybe from the superstars perfectionist perspective, the others are incompetent…

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

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

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

Re: On Being Indispensable

#143

My experience has been: 1- redirect to another engineer. 2- keep track of the convo. If it is going off the rails help the engineer get back on the rails 3- if the engineer cannot help, jump on a call and explain to the engineer how to help. Then let them help. This is how teams grow. This also let's you, the technical leader, inject yourself and assist the team without being the only source of truth. And also you be…

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

Re: On Being Indispensable

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

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

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

Re: On Being Indispensable

#145
post #130
post #114

Earlier quoted context omitted.

Confluence search is alright. The problem with Confluence is the undisciplined people who mess up their spaces to the point where the search comes up with too many mostly duplicate results, where you can't be sure which one is the latest valid version. At my job, we use Confluence extensively, with dozens if not hundreds of spaces, and in some spaces, searching for something is a delight, while in others it is imposs…

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

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

Re: On Being Indispensable

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

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

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

Re: On Being Indispensable

#147

Earlier quoted context omitted.

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

> refused to let me move for a promotion because I was "indispensable" and "critical to the project". So would they rather have you quit? If not they should be willing to give you whatever title, pay bump, time off, etc. is necessary to keep you long enough for a replacement solution to be found. Otherwise if you just quit they’re stuck negotiating from a position of weakness to hire you back as a much higher paid co…

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

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

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

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

Re: On Being Indispensable

#148

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 c…

Very few companies and projects die to a singular departure

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

Re: On Being Indispensable

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

It also works pretty well.

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

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

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

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

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

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

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

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

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

Re: On Being Indispensable

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