Doing nothing at work
seangoedecke.com
seangoedecke.com
> 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.
It does not work for large corporations with pools of billions of dollars and various incentives to staying within the ecosystem. It's impossible to measure the contribution of one feature team to perception and retention of something like "Microsoft Intune" or "Google Chrome", and without the ability to measure that no effective check on those teams.
See: https://corecursive.com/building-powershell-with-jeffrey-sno...
Of course, game theory implies "infinite games" and of course the real world doesn't operate like that.
And large bureaucratic orgs collapse under their own weight, and the enshittification is the norm despite the number of paying customers.
You see this pattern of "make fire, put it out, get rewarded" a lot on devops type teams, almost always by the lead (IME). Often it is very difficult to determine customer impact of these types of events, especially if monitoring/alerting is lacking (very common), and even if it isn't, often these same teams have the ability to turn those knobs any way they want anyway.
Much easier to liberally sprinkle mutex locks and "Thread.Sleep(1000); // Quick fix" everywhere until the problems almost always go away!
Meanwhile the guy screaming that this is eldritch madness and can't ever work is "not a team player" because the guy that wrote the code was a hero for applying yet another layer of band aids to the gaping wounds.
Well from a philosophical point I would argue that you can measure the weight of nothing too.
*solid in a pure engineering sense - availability, maintainability, chance of leaking the users' nudes etc.
A good honest approach is just to build a few complex but essential tools so that other engineers have to keep coming back to you. It's a good way to stay relevant. You become really good at identifying misuses of that particular tool and it makes you look way smarter than you are when you can identify bugs in other people's code in mere seconds. This tends to happen naturally as you become more familiar with all the common gotchas that people tend to run into when using your tool.
Ideally you want your tools to be reliable and useful but complex... That way, whenever other devs run into bugs while using your tool, they keep coming back to you and you can point out their mistakes. The mistakes must be almost always be on their side for the strategy to work; this is key. Your code has to be rock solid.
If they find a genuine bug in your code, hopefully a small edge case, you have to be very humble and apologetic about it and you should praise the developer in the team meeting for identifying this complex bug.
This approach is better than getting credit for fixing your own buggy code; that only works with management and junior devs but other senior engineers will hate you.
The approach of building complex but reliable tools gets you credit over and over (often much more than twice) and the approval you get from other devs eventually finds its way to managers' ears. Smart leaders know that this is a better signal than flashy demos.
The leaders who just dish out praise onto specific devs for producing prototypes quickly tend to learn their mistake sooner or later. Many young founders tend to go through this phase though when they praise superficialties.
Even when you can, you can't prove the impact. As a real example, our team has extensive presubmit infrastructure to catch and block some classes of configuration error that have caused customer data corruption in the past. There have been CLs which were caught by those presubmits and meant that we didn't have outages, but there's no dollar amount tied to an outage that didn't exist.
Meanwhile, team X did something similar that caused data corruption, had N customers affected for such a period of time, scrambled to root cause, roll back, and restore from backups, getting customers back up and online. Look how responsive and great they are!
The impact is how many outages overall. If you only prevent one outage then maybe it's not that meaningful.
Your last paragraph, your right that happens in the short term. In the long term those teams get reputations for being a shit show, there will be high turnover, good engineers won't transfer in, people's compentaencies start to get questioned, other teams will avoid working with that team and develop their own solutions, and higher up people will start to look at what's going on.
Reputations with who? The VPs who rotate in and out every few years (if you're lucky enough to go a few years between reorgs) for a new title and salary bump?
> there will be high turnover, good engineers won't transfer in,
On the contrary, many people want to work on the team that gets visibility where people can actually get promoted rather than having to justify their existence constantly
While they’re busy fixing their own problems, the teams that wrote outage-free code get first dibs on writing new systems.
On the (online game) teams I worked on there are an infinite number of new & exciting systems needed, so this approach means that the best developers are the ones building them.
The person who made the breaking change is often diligently following instructions to get it done as soon as possible.
Put this in a frame.
If you’re not being recognized for your work that’s a leadership problem. Stiff arming work feels like a way towards an ossified lumbering work culture.
Seems insane that the latter can even be a functional business, but monopolistic profit can enable all sorts of tomfoolery.
But I'll equivocate by saying there are exceptions. If you work a union gig (technically a contract), you have to be careful to stay in your lane unless you want a grievance filed. If you are a licensed engineer and your boss tells you to design/stamp something outside your domain of competence, you have a duty to say no. But that kind of stuff is the exception.
As for unions - yeah thats what got them kicked out of the convention center. Only certified electricians are smart enough to plug in laptops into sockets!
If the proper channel means coordinating with finance to allocate money, get it assigned to labor codes, and reflected in my bi-monthly time allotment, I think I'd rather just jump the job and get it done this week than get it properly assigned two months from now. It does require a certain amount of cover and trust within an organization, though.
This makes it easier to query and show what you've done in a time period. It makes it easier to go through the list of your assigned tasks and understand where it fits in the priority order.
Likewise, there may come a day when I need something from coworkers, and when it comes, I'd appreciate enthusiastic help instead of being swatted away and told to go through the "proper" channels (which could take much longer).
At good companies, they have a culture, and people help each other out.
Like lunch-table talk that helps people understand things.
But yeah, maybe not doing hours of work for someone.
Where I work the title "Principal Engineer" is a coveted, well compensated, and rarely achieved. Those I've worked with are all highly effective and personable, but I interviewed one about how he achieved the title at his previous company.
His strategy had been to help people and actively give away the credit. In 1 on 1s or in meetings with multiple layers of managers, he would consistently emphasized the value of his other team mate's work. This ingratiated him with his team; years later, when a high dollar project was behind schedule and several key engineers had quit, he carried the project to victory with some late nights, and was awarded the title+raise at his next review. While the key project pushed him over the edge, he wasn't the only engineer there working late nights. He credits his promotion to the goodwill he'd built during his tenure by actively giving others credit.
I got the bump in the end. How? Finding new company, both literally and figuratively. Overextension/sacrifice played no part and I'd like a refund, were it possible.
(one such way to retaliate against defectors is similar workplace anti-social behavior. For example if someone asks you to do something off the books, you can agree and then just flake on them and not actually do it, while hinting that if it was in the ticketing system it would be prioritized)
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.
If you save a sales deal, they'll cheer the sales staff. And pay them a commission, which you will receive no part of.
If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicating with them.
Most people either want hypergrowth idiocy or to be bought by the people doing hypergrowth idiocy.
Setting consistent expectations means you can plan, you can actually reasonably budget, you can have predictability in your business dealings - if you are trying to run a good business these are all real features instead of "puts out more code that might or might not make us money, but at least we were pulling all nighters and adding perceived meaning to our lives!"
Yeah, but did you take Hofstadter's Law into account?
It always takes longer than you expect, even when you take into account Hofstadter's law.
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.
Unfortunately very few jobs are structured to take advantage of that. So many blockers and distractions from you getting into actual deep work.
It was a bit ironic though, as most of the work I did during that time was ultimately shelved, as I can tell by looking up public DNS entries, probably due to other people exiting or the team being reorganized.
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.
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.
After that, yes it'd make sense to find something else.
And the best part is that since it's not an assigned task, nobody is waiting for it, so I'm under zero pressure.
Sadly it doesn't happen that much as we're always pushing for more new features out.
Easier to sit back and not do anything.
And I work on the backend in a smaller company these days. Our backend code doesn't pass through QA, we just write tests and another backend coder reviews the tests if new tests are written. QA only handles frontend.
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
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...
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.
Love this!
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.
> 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"
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.
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.
> 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.
One that is very important: Do you have another opportunity to accept? There is nothing better to get a job than being employed.
If you do have a offer, consider if you take; but if you don't, try to get one while you are employed and jump ship when it's a better one; repeat.
For the first 10 years or so, this is relevant. After that you can figure out what you really want to do.
Early career pick learning and exposure to different technologies, processes, and company organizations.
That being said, this job market is pretty bad for the youngins so unless you are top 1% of noobs I would say focusing on stability and learning would be my north stars in the next 3 years.
It's going to take time to earn trust from peers and your manager to start getting more meatier work. If you're early career, I think 2 years is a good guideline. Many places hiring someone for their second job will expect you to be leaving your first job around 2-ish years. 2 years gives you the chance to take on larger projects and see the results of your work and get feedback about things you've pushed to production.
You probably shouldn't stay at your first job more than 3 or 4 years. The second job change is the hardest. It's when you realize that different companies do and value things differently. Staying too long at your first job will make it tougher to adjust. It's also good to get exposure to new ways of working while you're still agile enough to soak it up.
If you've left more than 2 or 3 jobs within 2 years it starts to look like a red flag.
But understand the ecosystem. People make promises that arent entirely dependent on them to be able to deliver
Definitely! It's been that way everywhere I've ever worked. Unless you are churning out code at maximum speed then it's only a matter of time before you get fired.
One common misconception the article touches on, for example, is that Jira tickets represent latent task assignments, such that you should always be working on some specific Jira ticket and immediately pick up a new one when you finish or are awaiting review on the last one. That's not how the most successful engineers work, and often it's not even really what management wants.
I've found that most of that autonomy comes with trust, and that trust gets unlocked via good relationships, and good relationships get unlocked by a history of good communication.
You are 100% correct that every person has agency, the trick is to get yourself into a social dynamic where it is acceptable to assert it.
Proactive vs reactive
You need to learn to manage your manager(s). Google it.
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 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.
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.