GoKawiilI 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.)
But not like this
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.
... continue reading