I find it very useful to be able to do everyone else’s job — it helps you learn how they work and what they need, and it helps even more when you need their job done, but they won’t do it themselves.

If you made something new and those you made it for can’t be bothered to start using it, go ahead and integrate it into their system. It worked for Intel back when they made their first 32-bit CPU and had their people add support for that CPU in Microsoft’s compiler — I’ve met someone from that Intel team. For some reason, many resent the idea of working on someone else’s system, and think of it as charity uncalled for in the workplace. Well, did Intel do Microsoft’s job to help poor struggling Microsoft, or did they do it to benefit from Microsoft’s success?

If a manager doesn’t actually manage anything, this is fine as long as you can go to his people and effectively manage them — without calling it that and without taking credit for it, of course, but you can usually find people in his org who’ll work with you, on the theory that they’re supposed to. 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.

If you need a feature in something you use, it’s often much easier to persuade someone to take your patches adding this feature than to get the work scheduled within their high-velocity Scaled Agile planning process (of course the plan is already finalized for this quarter as well as the next — it’s our well-run planning process to which we owe our velocity — but in a few weeks, we can discuss the priority of this versus the other features relevant for the quarter after the next one.) Sadly, merging changes might have gotten harder recently, with your well thought-out patch looking no different than random LLM output at first glance, but it shouldn’t be a problem once they get to know you.

Like I said, a lot of people think this is twisted, and why would they do that. 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 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.) You’ll also see indirect rewards from being one of the few people actually understanding how the place works and what it takes to get something done there.

(If anything, it’s refusing to get into various areas over the years that I personally regret — areas which I totally could get into, but didn’t, on the theory that it’s too far from what I do, not to mention boring. In hindsight, how very stupid. When you drown in preventable problems as a result of thinking someone else’s job will “just get done” when it obviously wasn’t going to, it’s no longer boring, but it might well be too late.)

There are 2 seemingly related things which look juicy to senior people but could actually play out badly, that people don’t reject as a twisted form of charity but rather love very much, because they get more headcount. In these cases, you aren't doing someone’s job so that they will be done thanks to you, but you do a similar thing in parallel to them, or instead of them.

The first case is doing something in-house instead of buying it, or using a standard free version. Some places do too much buying and prefer external products even when they suck, because “standards are good” or because it’s easier to spend money than to hire people. But other places do too much in-house building, because in those ones, it’s impossible to approve any expense, but reasonably easy to grow your headcount. If we look at it from the perspective of improving expected outcomes as opposed to doing the easiest thing in a given place, buy vs build is a very hard decision specific to each case, where you need to learn a lot of details so as to honestly weigh your own deficiencies vs the deficiencies of prospective vendors and the structural issues of the market.

The second common variant is, instead of centralizing a service so that everyone in the company uses it, every department does it on their own. Department managers like it because it’s one less party not reporting to them to depend on (and nothing scares managers more than needing things from people not reporting to them.) And the people managing the department managers like it because they don’t need to deal with the centralized service department allegedly failing — and having to figure out if that’s really true and how to fix it, or if it’s an excuse made up by the other departments for failing at their own job. Here, too, if outcomes are what concerns you rather than what's easiest for senior leadership, standardizing on something across the company vs having everyone roll their own variant is a hard decision to make.

Thanks to Dan Luu for reviewing a draft of this post. He commented, “from the opening, I thought it was going to be about the thing where founders supposedly do a better job if they know how to do the job of the person they're hiring, which is why it’s useful to scale the company up from nothing. That's what some founders say, anyway. A friend of mine who's a successful second-time founder (who I think has good judgment) said that it's much easier to hire well if you've done the job yourself, which sounds reasonable/plausible. I guess you could get the same value out of having the right trusted people who've done the job but, empirically, people seem more likely to get who they trust wrong than right.”

This makes sense to me, though I am yet to scale a company of my own to be able to confirm this. I feel it does work this way when growing a team, as long as you know how to manage people who do their job better than you would; but by the time the team grows to hundreds of people, it will often have some people on it whose job you can’t do, and if it’s not one team of several but an independent company, this will happen much more quickly. So I would think that lacking the complementary ability — to manage people whose job you couldn’t possibly do, which is not easy — is what will become the limiting factor.