> Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.

Time and time again at many companies, including well-reputed ones, I have seen that preventing issues gets you no recognition, but building a giant pile of kindling and then putting out the inevitable fire will get you recognition twice. Even in "good" orgs.

I've never been able to commit to the game theory politics enough to intentionally ship garbage fast and take that credit - I take too much pride in my work - but I have spent 5+ years managing and growing a framework designed to eliminate classes of issues that plagued the last version of our product and watched as partner teams who ship garbage code and cause outages get public credit for fixing those outages and my team, despite attempting to advocate, get no credit for not having such outages because you can't measure that.

Put this in a frame.

Not to be sarcastic but just to offer an observation: in a sufficiently large or bureaucratic organization, preventing an incident from happening can rarely get you any credit or visibility. Such achievement falls into the bucket of "what you're supposed to do". So, those who navigate company dynamics well would rather let the incident happen and then be loud on the follow-up action items. The trick is not to turn an incident into a diaster, so it's a dedicate act.

Your mental energy deployed at work is not so dissimilar: keeping some in the tank gives you the option to deploy it strategically, rather than risking your health (burnout) when something unexpected comes up.

If you join a group in one of these games with a player who is bad at managing their mana, you’ll also find that they’re not such great teammates, either.

Doing a little bit of "glue work" can make you indispensable and also a hero to your team if it makes everyone's work life a whole lot better and no one else knows how to do it.

> Second, if you perpetually look busy, your manager won’t want to volunteer for you.... "oh, Sean has capacity to help out here, let me tag him in”

That's rather primitive, does the author not realize that you can simply change priorities and just drop the working on the current "low impact keeping me busy ticket"???

Similarly,

> You won’t be chatting with people who are working on other things, or reading team updates, or keeping an eye on ongoing incidents.

That's not doing nothing! Just like writing those team updates isn't doing nothing because it's not a "ticket". I bet literally your job description is not limited to "do tickets"

on one hand it does seem a bit messed up - this was not in my "job description", so it was technically unpaid work that was nevertheless a formal part of my expectations. but on the other hand I really liked working in an environment where everyone spent some of their time and effort to improve things for everyone.

also making it an explicit requirement for everyone to do at least attempted to circumvent the more toxic culture of "I am a rockstar engineer and I'm busy doing important things, someone else can do the glue work". not to mention that "someone else" usually ended up being a woman, and that she was almost certainly getting paid less than said rockstar engineer.

the OP's implication is that the company should have formally hired someone to do all the glue work, but it is usually made up of enough diverse pieces that it would be practically impossible to hire a single person to do it - e.g. what sort of job title would cover "write documentation, interview software engineers, and organise a team off-site"? but those were all tasks that needed to be done and the citizenship requirement let the burden be distributed more fairly.

I think a better way to put it is not "don't do glue work" but "don't be the only chump doing unrewarded glue work", i.e. to push for a company culture where everyone is expected to do some of it and where it is formally recognised as work.

It’s made worse when they are not a decision-maker, but someone who gets forced to push me to do something. As a trusted expert, it’s easy to say no to bad ideas when the client is the one doing them, but when the orders come from their boss who you never interact with, you’re placed in a position where you either appear as a useless cost, or a yes-man who’ll leave behind a monstrosity.

I sometimes envy some of you guys who worked primarily internal gigs where you could at least try to reason with someone up the chain.

I've been focused on going out/socializing more which is unfortunately distracting me in life, all I can think about is going out getting laid

The result is that I often know what I should do better than I would have. Make a point of talking to the people you solve problems for, get your hands dirty, and create that domain understanding that you need. You'll likely produce less code, but it'll be more useful.

Or, in some cases, you'll write more. But it'll be for something you never would have realized you needed had you not 'done nothing'.

The key for me was allowing myself to get out of the engineer mindset and into the mindsets my coworkers need to do their jobs, being less interesting in fixing and solving, and more interested in getting a holistic understanding of the required work and how it fits into our team and org and with our partners and so on.

I'm fortunate enough to work somewhere where this isn't only permitted, but it's encouraged. The problem spaces are often highly niche and complex too, so the need for developers knowing what their users are doing is especially important.

I do think it applies anywhere, though. Even in my own personal projects. Do less, observe and experiment, use the software, let things incubate. Then do the work once the mental model has settled in a way you know is better than it was.

The more difficult it becomes to remain silent, the more likely it is that silence is the correct action.

Ego is a hell of a drug. I've been on some calls where things go sideways in prod infrastructure simply because of incessant yapping about things that are tangentially related to the tasks at hand.

Being clever tends to be a lot easier than being the other things, especially now that we have chatgpt and friends.

    > For instance, I believe that engineers should generally avoid glue work2. Most glue work - making sure people talk to each other, updating docs for work you’re not leading, volunteering to address technical debt - reflects the fact that the organization is not explicitly prioritizing this work. If they were, you wouldn’t need to volunteer for it. Either that’s fine, or it’s a big mistake.

When you're cutting trees, sharpening the saw looks like you're not working. When you're doing software or organizational work, figuring out what actually matters can also look like you're not working.

The hard part is distinguishing between thoughtful idleness and ordinary procrastination. [1] https://www.franklincovey.com/books/the-7-habits-of-highly-e...

There are people who say it's better to have multiple claude code instances crunching different stuff at the same time, and using the waiting time to prompt up another one. This might result in opening up more PRs faster but in the end it's not more productive. Context switching takes time, it divides your attention so your work is more sloppy and less thought through, and driving your brain too much makes you tired which again results in more mistakes. Having to compensate for this negates the productivity gains by finishing more grunt work faster.

Running anything at constant 100% utilization means you are going to be working in crisis mode all of the time. Even in factory labor, the Toyota Way is several decades old now, and it involves making sure everyone has at least a little breathing room to step back and think about what they're doing. And obviously this is even more important for "knowledge workers" or anyone whose output requires any amount of creativity.

High functioning organizations have a good (not too much, but not too little) amount of slack in their work pipelines. Pretty sure there is not a single person with an MBA (or, lol, any consultants) that knows this anymore.

It also sounds a lot like getting pulled into meetings. People complain about it, but sometimes that’s the job.

> Most incidents resolve on their own.

This is most definitely not true.

Otherwise I don't see why you couldn't do lower value tasks with flexibility to abandon them if something higher value comes up

It also made me hate my life.

I often fall into this role, and historically have made some quite large impacts because of it. But I take issue with TFA's position of doing nothing being a critical component of being effective and available to attack these problems.

I'm practically never doing nothing when employed. But I'm often looking like nothing is being done through the lens of ticket-oriented accounting. If the author means doing nothing by the metrics, ok, I can agree with them there. But it better be because you're too busy down in the weeds becoming one with the product and grokking details of created messes past and present.

If you're literally doing nothing, you won't be positioned well to understand the implementation details, and you won't be positioned well politically/socially within the org to thrive and be genuinely appreciated by your peers.

This is a complicated precarious path to take if you have any intention of lasting in the org. It's difficult to not accumulate enemies with every win you take at the expense of everyone else being too busy being the substrate you're scavenging. Management and your peers must come to appreciate you're filling a critical void, but the void is implicit and unaccounted for, making this tricky - it's built on trust.

They can see your selective work as exploitation while they take up the slack you create. From their perspective they're overworked because people like you don't do enough to balance the workload.

You need to be recognized as an enabler, the one minding the details, omnipresent - not AWOL doing nothing. Catching the fuckups early, preventing incidents while the green-field chaos monkeys carry on. The win is for the team, and you're effectively being a self-directed janitor cleaning messes nobody knew existed.

The reward for this role, as it really is otherwise somewhat thankless, is the autonomy. It's a management failure when these people get put on a pedestal and promoted more than the people doing the grunt work. That creates animosity within the ranks.

disclaimer: not a manager, not a lead, but often the guy in the corner course-correcting and fixing/preventing horribly broken customer-impacting mistakes. These are just some observations based on decades of startups and in recent years FAANG experience as an SDE.