Hacker News Reader

Comment by grogenaut | Hacker News Reader

Amazon has these numbers easily accessible as reports on their code systems runnable at any manager level, and many other ways to inspect what the team is doing and the risks you might have. I find them useful.

Bus factor is one way to think of it. Another is it lets you spot silos, or engineers who aren't working with others, or places where you can't as easily move engineers around (so you can fix that).

Some developers fear fungability, they think that that one system only they know is job security. I see it the other way, I see that as a technical risk, but also a thing that might be keeping a great engineer from working on more important projects. Or the way to work on something else when you get fed up with that one system you hate.

View on HN

> Some developers fear fungability, they think that that one system only they know is job security. I see it the other way, I see that as a technical risk, but also a thing that might be keeping a great engineer from working on more important projects. Or the way to work on something else when you get fed up with that one system you hate.

I don't fear fungibility - if a place doesn't want me there I don't want to be there either.

I dislike idea of fungibility because it creates huge overhead and avoids using talented people to full potential - because they are not fungible.

In some places that's warranted - but in others - the process overhead is far greater risk to your project success than bus factor.

I know a def who was denied a transfer and promotion because he couldn’t easily be backfilled.

Spoiler he left company within 3 months

Each department in my company can designate someone as a "critical man" so they can't change teams. However, those people usually get the highest possible ratings and raises. I've only seen it used maybe one time.

This is the other reason I want people to be somewhat fungible... so management can't shoehorn them. Really the ability to move is a good thing for both the company and the employee. Moving doesn't HAVE to happen, but it's really much better when everyone has options.

> Some developers [...] think that that one system only they know is job security

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

But a promotion also means change, maybe people are happy where they are? After all, you're most productive in a familiar codebase. Then again, if a codebase is "done", productivity is less important and often work dries up. There's plenty of people that are happy with working 10 but getting paid for 40 hours a week.

This. I am not a manager, but I LOVE writing code and solving problems. I would NOT love being a manager.

Some companies have parallel career progressions for individual contributors and managers. For example, Amazon has a distinct career progression for software development engineers (SDE): SDE I, SDE II, Senior SDE, Principal SDE, Senior Principal SDE. Sr Principal is a VP level position, but has no direct reports. It’s an advisory role.

I've noticed that, while these tracks are still technical, you will still find yourself in more and more meetings and writing less code. I think everyone needs to come to terms with whether or not they want a promotion regardless of the track.

Senior Principal engineer here (not at Amazon). Yeah :-(

At Amazon, if you don't get promoted, you get pipped, eventually.

Only if you aren't at a terminal level already, and you are easy to replace. When I was there one could find plenty of SDE IIIs (and a smattering of SDE IIs) who had found nice quiet niches of the codebase to hide out in for 5 years or more...

Who needs promotion? I just want more money

Perhaps another framing of the same idea is that you can’t work on other (bigger and better) things if you can’t hand your work off to someone else.

Article author here: I've always said I want to be able to go on vacation and not get a call.

I like your framing better!

I don’t want to frame it positively. In my experience, people who hoard knowledge and/or relationships (as with other teams or customers) are toxic.

I hate all sorts of gatekeeping behavior but I especially despise having to wheedle information or effort out of someone like that. They almost invariably have an ego that is out of proportion to their contributions.

Side note: Occasionally I have seen people who take on the thankless task of being a maintainer of something no one else wants- those people tend to welcome others and share as much as others are willing to listen to, so being the single person who knows something doesn’t make you a gatekeeper.

It’s the gatekeepers that I hate.

honestly every system I saw someone corner themselves in didn't take very long to have someone else figure out. you just toss some smart motivated folks at it. paging them every time something breaks also seems to help the knowledge transfer. I know it motiviated me to get in there and do a gut rehab.

> Some developers fear fungability, they think that that one system only they know is job security

And this is pragmatical for an employee who's primary goal is not optimizing Amazon's income.

I've spent my entire career trying to make myself and every other cog-head as replaceable as possible. Part of this is because that's the job in large parts of digitalisation, but another big part is because it's annoying to deal with knowledge silos. One of the reason we use Typescript for a lot of our back-end stuff is because it's the one language that our small team has to know. This means our front-end dev can go on a vacation and actually disconnect because other people can cover. It also means it's less of a pain when someone changes jobs.

It has never once been an issue and I think fungability is a part of any healthy system. I spent a few years on the other side of the table, and one of the first lessons you learn in management is that everyone is replaceable and that's solely a matter of cost. Because of this, high levels of knowledge may also work against you as management will likely work on reducing the risk you present. Another thing you'll learn is also how random layoffs can be, especially if they happen for economic reasons.

That being said. I avoid working at places with these silly metrics. The more red tape you put in the way of good work the less likely I'll want to work with you. There are a lot of reasons for this but the primary one is that these sort of things tend to create work cultures which just aren't good for productivity and quality as people "game the metrics" instead of doing good work.

At the end of the day the engineer has a valuable skill and you're the one telling them they need to be more replaceable. You're the enemy. Of course you're going to think the tools that let you dehumanise your employees at scale are good things.

Hard disagree. I think a huge part of our job as engineers is to build systems that can outlive us and comfortably change hands (without the next team cursing the former).

Maybe this is born from spending so many years in Amazon (with it's high turn over and near-quarterly re-org shuffling), but what's getting called "replaceable" here I'd call "writing maintainable software."

The goal is to get knowledge out of your head and into the codebase so everyone can reap the benefits. Knowledge hoarding is lame.

Reply on news.ycombinator.com