Doing everyone else's job
Blog<br>Site<br>đť•Ź<br>Feed
Doing everyone else's job
June 14th, 2026
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<br>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<br>system. It worked for Intel back when they made their first 32-bit CPU and had their people add support for that CPU in<br>Microsoft’s compiler — I’ve met someone from that Intel team. For some reason, many resent the idea of working on<br>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<br>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 —<br>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<br>you, on the theory that they’re supposed to. It’s true that many of them have long figured out that they’re really<br>supposed to follow orders passed down the hierarchy and do nothing else, even if everything around them is on fire. But<br>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<br>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<br>feature than to get the work scheduled within their high-velocity Scaled Agile planning process (of course the plan is already<br>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<br>weeks, we can discuss the priority of this versus the other features relevant for the quarter after the next one.) Sadly,<br>merging changes might have gotten harder recently, with your well thought-out patch looking no different than random LLM output<br>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<br>do 80% of the work, but that all this work only achieves its ultimate goals thanks to the 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<br>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,<br>it’s on its last breath.) You’ll also see indirect rewards from being one of the few people actually understanding how the place<br>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<br>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<br>you drown in preventable problems as a result of thinking someone else’s job will “just get done” when it obviously wasn’t going<br>to, it’s no longer boring, but it might well be too late.)
But not like this
There are 2 seemingly related things which look juicy to senior people but could actually play out badly, that people<br>don’t reject as a twisted form of charity but rather love very much, because they get more headcount. In these cases,<br>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<br>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<br>buying and prefer external products even when they suck, because “standards are<br>good” or because it’s easier to spend money than to hire people. But other places do too much in-house building, because in<br>those ones, it’s impossible to approve any expense, but reasonably easy to grow your headcount. If we look at it from the<br>perspective of improving expected outcomes as opposed to doing the easiest thing in a given place, buy vs build is a very hard<br>decision specific to each case, where you need to learn a lot of details so as to honestly weigh your own deficiencies vs the<br>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<br>does it on their own. Department managers like it because it’s one less party not reporting to them to depend on (and nothing<br>scares managers more than needing things from people not reporting to them.) And the people managing the department managers<br>like it because they don’t need to deal with the centralized service department allegedly failing — and having to figure out if<br>that’s really true and how to fix it,...