They would couple this with things like standardized coding and documentation styles, common tools, etc. Training on these standards was a regular thing for all staff.

The idea was that they could rapidly move experienced staff around. It also helped staff to understand how their work was applied in an integrated system (having “blinders” on, is a fairly typical issue, with dedicated employees).

It generally worked, but relied on their particular culture, and introduced a fairly significant amount of overhead and rigidity to the system. It would also mean that it takes a long time to cultivate experts.

Personally, I’ve always enjoyed learning new stuff (still do). I actually enjoy taking on projects that I don’t know how to do. I wrote about it here: https://littlegreenviper.com/miscellany/thats-not-what-ships...

and most managers fail to punish at least some of these slow learners of theirs

False, they punish by not crediting that work as work.

Glue work, keeping things tidy, dealing with that annoyance that everyone else has been able to get away with suffering through (and ignoring), all of this will be worth approximately 0 at performance review time because your time is a zerosum game that is traded off with highly visible, political, and otherwise rewardable work.

It's been my experience that in larger companies you generally have to play in the framework.(I'd roughly draw the line at 1000+ employees), at quite small companies (or as a self employed / entrepreneur, roughly <200 employees) you should follow the path of highest EROI on your efforts regardless of who's job it is. In the gap you have to read the culture and management.

The problem with one is the same with any other single source: you are stuck with whatever they offer on whatever timelines they provide. You are sharing this with a hundred thousand other people, so it's not tailored to your use case, but either made as generic as possible, or full of irrelevant features. Both of these cases make it worse for you.

I have often made in house libraries either based on or completely replacing a free equivalent because the free one doesn't meet our needs and has extra complications we don't need. Yes, it comes with its costs, but sometimes it's worth it for something that genuinely meets your needs.

By forcing everybody to use the same common platform, you are either forcing them to work around the mismatch between the platform and their needs, or your are forcing the platform to provide for everyone's needs. Neither is efficient and it harms every other user.

If you are going to make your own, you had better have a good reason for it, but you shouldn't be forced into a single solution for everything - it can end up being more expensive than making a few special purpose applications.

Everything is locked behind multiple layers of permissions. It takes weeks to get the correct permissions set up even for my actual job (which I see any time changing roles here, or when onboarding new hires). Getting the permissions to jump in and improve some other part of the system that I don't officially own - even though I might get granted them if I ask nicely, because nobody knows who is actually meant to have what permissions - is so much higher friction than asking the "right" person.

If a manager doesn’t actually manage anything, this is fine as long as you can go to his people and effectively manage them

but you can usually find people in his org who’ll work with you, on the theory that they’re supposed to.

In 100% of the cases where someone has tried this on me, both as the manager and the naive employee, the real reason was that they didn’t care about what the manager/employee was supposed to be doing. They were looking for easy targets who could be abused to do their team’s work. Most of the “manager doesn’t manage anything” accusations came from other teams who weren’t even trying to understand what other managers or teams did. If the other manager or team wasn’t actively working for them in some capacity, they thought the manager wasn’t doing anything.

It’s true that many of them have long figured out that they’re really supposed to follow orders passed down the hierarchy and do nothing else, even if everything around them is on fire. But some never figure this out, and most managers fail to punish at least some of these slow learners of theirs, so they’re yours to work with.

The most generous interpretation is that this is taken idle employees and putting them to use for the greater good, but most of the cases I’ve seen in real companies are from one arrogant manager spreading their work across any workers gullible enough to do anything you ask of them.

I’ve worked with and hired a lot of really nice people who always want to lend a helping hand. They’re great, but many of them have a real problem handling workplace sharks like this who will saunter over to their desk (or DMs) and persuade them to work on something else, which puts them behind on their own work. When it happens chronically it gets so bad that you have to start checking in almost daily to make sure they haven’t been pulled into yet another team’s workload from a Slack DM or email.

Helping other teams when time is available is a good thing generally. You need to make your manager aware of the incoming requests and time spent, though. Don’t become the person who is working themself to the bone for everyone who comes over with a request but is holding their own team back because they can’t focus on their actual work.

It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.

It's useful.

And then there's times like getting to charge your client $300/hour to drop stuff off at FedEx. Because you can do that and you're here and you'll get it done right -- no one needs to explain the idiosyncracies of this particular deadline or package contents; you've got it.

Even if that's not normally a senior consultant's job.

I believe that not only do 20% of the people do 80% of the work, but that all this work only achieves its ultimate goals thanks to the <5% of the people who do stuff that someone else is supposed to do, but won't, for reasons which are perfectly legitimate in the organization's view of reality, even though the cumulative effect of such legitimate reasons is the certain death of the whole place.

I don't know that I've ever felt so validated by a HN submission.

I am definitely one of those suckers that does extra work others will not do. It isn't altruistic, I just can't motivate myself to work at all if my tasks are stupid. The problem is that at any sufficiently large organization many of the tasks are stupid because hardly anyone is on the same page.

That said, I’d add one more point: in China, where I’m from, it is getting harder for individuals to even survive inside organizations these days, let alone succeed. In that environment, the rational strategy is often to do less, take fewer risks, and make fewer mistakes.

Hard not to miss the golden days.

I also believe that you will be well-rewarded for doing everyone else’s job in the many cases where the organization is in a shape bad enough to need this (which is most of them) but is still healthy enough to eventually appreciate it (and if it can’t, it’s on its last breath.)

Tread carefully. At fairly large companies, you'll find plenty of people who'll take your reward. I also know people like those described in the article who get hit by layoffs - people didn't realize how significant the unofficial work they did was.

Whenever I get a new job, I always research and test the waters. If it's clear I won't get rewarded, I don't do it (and start searching for another job).

I really wish this was more common in the industry, now as a Product Manager, while I do a lot to engage with field teams (Support, Sales) and work across every group in the company (Legal, Finance, Eng, Ops, Support, Sales, et al), I still only get interactions and snippets, it'd be great to go walk a mile in their shoes.

It all depends on stock options allocation, no?

Usually, if I dig into something that's not being done by others it's because it is no one's job. And by the rule of "he who touched it last owns it" (a stupid and destructive default rule that exists even in otherwise excellent organizations), I end up owning a bunch of old crap no one wants to touch.

The comma count is a hint ;)

(I had to parse a few paragraphs several times to get the idea.)

In my experience, rarely an individual contributor ends up being promoted to a manager (because the latter retired/layoff/etc).

At the higher levels, they are filled with executives in acquired companies or hired from the outside. (CEO of LittleCo becomes VP of BiggerCo)

Although I have seen 2-3 unicorn cases where someone goes from janitor to director in 3 years - far faster than a high performing junior engineer with demonstrated accomplishments can become a senior engineer… Always assumed the former was flat out nepotism.

The reviewer says "based on the opening paragraph I thought this was going to be about topic X. Here are my thoughts on topic X".

That's great, but the article isn't about topic X. What are your thoughts about the actual topic of the article? Did you read it, or just the opening paragraph?