Doing Everyone Else's Job Is the Secret to Getting Things Done
Yosef K. argues that the most effective employees are those who step in to do work that others are supposed to do but won't. Drawing on Intel's early support for its 32-bit CPU in Microsoft's compiler, he shows how doing someone else's job can benefit both parties. He also warns against two tempting but harmful variants: building in-house instead of buying, and letting every department roll its own solution instead of centralizing.
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.
- maerF0x0
> 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.
- ChrisMarshallNY
I worked for a Japanese corporation, and a big part of their HR policy, was to move staff around the company. It was usually in 1- or 2-year stints (people would spend their entire careers at the company, so they could do this). Eventually, they would end up doing longer stints, where they would specialize.
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...
- Aurornis
> 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 h […]
- RevEng
I disagree with the centralization thought. I'm working on a project to create a central AI platform for a very large corporation. As you can imagine, such a large company already has several different platforms made by different branches within it. Each branch has something they are relatively happy with. But corporate sees this redundancy as waste, so they want to consolidate it into one.
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 spec […]
- dmurray
One of the things I hate about my current job is that it's impossible to do this.
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.
- cik
I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan of touring the organization. Whether I join as a dev, or an exec, I always make it a point to spend some time with product, with support, and with marketing. It ends up providing me a unique vantage point. I encourage others to do the same, and when I 'control' onboarding, make it part of the process.
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.
- exmadscientist
The other powerful thing about being able to do everyone else's job is that you, personally, gain a lot of leverage, and in a lot of different ways. Someone else needs a favor? You probably know how to deliver. Something's on fire? You probably know what to do next, or at least who to call, no matter what's on fire today. Someone isn't budging on something? You might not have any bigger of a lever than anyone else, but you probably know exactly where to position yours, and exactly what it'll do when you apply a bit of force.
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.
- randusername
> 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.