How to burnout a software engineer, in 3 easy steps
engineercodex.substack.com
engineercodex.substack.com
Lie to their team about their criticality, before laying off half of the same team
Replace large amounts of management 3 times in a single year
Hire so many people nobody knows what their role is and everyone competes for influence
Ensure that every engineer has at least 5 hours of meetings a day, half of which aren’t relevant to their team.
Stack ranking
Don’t give them a raise for years despite praising them for being a top performer with large impact
Arbitrary KPAs which undervalue anything other than LoC
Make people be on call with no training for what theyre being on call for, and have critical alarms go off every 3 hours
Host meetings in front of your giant glass wine cellar larger than most your employees apartments. Bonus points if you talk about belt tightening in that meeting
Make sure that things never calm down after a giant release, make it the new normal until people start dropping out on medical leave, then install a new engineering leader who loudly states that he thinks the engineering team is lazy
Fire or layoff people, give their duties to an already busy engineer, promise that engineer it’s short term but never replace them, give that engineer a middling performance rating for not excelling at their “core” job despite doing the work of 3 previous engineers, deny them a raise, get a promotion and a massive raise as a manager
Have useless stand-ups at the ass crack of dawn "just so everyone sees each others' face, isn't that nice?".
Change the priority of eleven different projects every week.
Lie about finances and runway, miss paychecks the week after doing so. Ask employees to work extra hard so it doesn't happen again.
Favor one employee due to $personal_reason, ignore the other engineers you've hired.
Completely isolate customer feedback from people working on product and engineering.
Make product decisions without discussing with engineers.
Go to fancy talks and banquets on the company dime every month and never be in the office. Blame employees for not "letting you know earlier" when they finally get a chance to tell you something is on fire.
... I could go on.
Lol, name the company please.
It’s hard not to become jaded, since this has been the eventual outcome at last two employers (even if they didn’t start out that way, the rot set in). Trying to find a healthier place to work, without sacrificing career growth.
This is just a specific variation on a theme that applies to all of STEM.
The half life of a STEM career in the USA is about 10 years. 10 years after graduation, half those with a STEM degree are no longer doing STEM. Another 10 years and those who remain have decreased by half again.
But once you start digging into all this you will slowly come to realize that the core of the problem is bigger still --- it is actually a cultural phenomenon that applies to American business in general.
American business culture views those who create products as expenses to be restricted and controlled. In contrast, those who *sell* products are viewed as productive assets to be lavishly praised, nurtured and rewarded.
The illogic here is deeply rooted and is fully illustrated by a phrase I heard over and over again down through my career.
"No one gets paid until something gets sold"
"Nothing gets sold until something gets built"
"Nothing gets sold until something gets built"
Yes. In my humble opinion, selling a non-existent product is really just a scam --- being perpetrated against the customer as well as the producer/seller in some cases. The sale isn't complete until the product is delivered.
But the salespeople don't care --- and apparently, neither do the execs who reward them with bonuses for their fake sales numbers. If the non-existent product doesn't materialize on schedule, it's obviously not the sales person's fault.
Just further illustrates the inherent bias that I mentioned.
If I have a synchronous meeting at 11am, I get nothing of value done before 11am.
If I've loaded an hour of context to search for a hard bug and at 4pm I'm forced to answer a "just 2 minutes" phone call, then I'm done work for the day.
This is not because people were somewhat better back at that point in time.
We had trust, respect for people's time and overall everyone was at least directionally pulling in the same direction.
Today we have a low trust, hustle and micromanagement culture. I am shocked every time people with experience simply don't help grow a junior engineer (because fuck em and they're gonna find a better job if they grow, amiright?). I am shocked whenever we throw people at a problem while it was shown over and over again the approach does not work for that problem. Shocked when trivial improvements are hailed as the ultimate engineering feat and impressive engineering feats are met with meh. I am shocked when people do not think (at all, zero, nada) about the performance and maintainability of the code they bang out.
People just started giving zero fucks. The future is bright.
Do you work at my company?
I think we can thank the MBA-ification of the workplace for that.
In stead of a layer of management above the people manager the assistants also share an assistant.
With a small salary comes a rigid job description without free styling.
1-4 times per year you bring in a consultant/freelancer to read the reports (AI generated abstractions) and twiddle the knobs for however long it takes. Say 1-2 weeks with nothing but meetings. It should probably involve a hotel, resort or boat trip.
That's ultimately why Managers wind up "on top", they can make choices about who to bring on, and who to let go.
And since they are "on top", they say they deserve more money and more control, etc.
That is a bit of a you-problem though. Pointless interruptions are bad of course, but if you not being responsive blocks other people, that is a problem too. You write that you also have an issue with synchronous meetings, which would be the alternative to get input from you in a plannable way. Doing all communication asynchronously is not acceptable if you are at all involved in team work.
Blocked means that you've tried solving the problem and that you've tried in multiple ways. Also you can be blocked because production is burning down or "blocked" since you give 0 fucks and have zero incentives to try.
If you claim you're blocked and I get a blank stare when I ask you what the problem is, what have you tried and what is your current hypothesis on why thigs are not working I am going to slap you so hars that you'll be back to using RCS for source control.
Hypothetically.
This is not about that one instance where 5 minutes saves you days of struggling. This is about becoming and being self sufficient to the point you are an asset to the business, not your liability. In your convoluted example: how do you know who the expert is?
If I were working at a hospital and debugging a medical device that somebody needed to have online that evening, then you can be darn certain I'd reload that context in my head over and over until the work was done.
But for shipping widgets back and forth, there's no point in making myself tired and resentful. I can pick it up the next day.
My most recent position descended into a farce. The company had been reborn from the ashes of the old company. The product was 15 years old and had accumulated a lot of tech debt during the crash-and-burn of the previous company. There was a huge list of things that must be done, or the company dies.
However the new company spent 6+ months designing a top-heavy set of processes. After that, critical tasks from the "must be done" list that should have taken hours turned into a 2-6 week ordeal of following the process, meetings and busy-work. Generally a two week sprint to research, then put it on hold for a planning session, then another 2 weeks sprint to do the task.
When it's something that must be done no matter what, and as quickly as possible, then this is sheer lunacy. I'm talking about existential risks to the company.
I found out how the other engineers are coping with this. Just about everyone is actively deceiving management in order to get things done. It goes something like this: 1) just do the work during the research/planning sprints. 2) when the work is complete, write up your proposal and estimate time retroactively. 3) the engineers rubber stamp each other's estimates 4) during the time assigned, work on the next task instead, and commit the code at the end, right on time, exactly as predicted. repeat.
The company pivoted from producing a product to producing arbitrary process. People's performance was measured on the accuracy of their estimates, so the engineers designed their own process to hit the mark perfectly.
Unfortunately it's a good way to burn out.
I don't know what Google they're talking about, but for non-customer-facing code, Google was atrocious for that when I was there.
"Docs? Just read the code," was a VERY common refrain there.
Google was absolutely non-negotiable on the necessity of checking in tests with your code, but missing docs was definitely the norm.
In the same vein: "Shipping useless code".
I worked at a company who created a product that everyone (except the bosses) knew was useless. A minimum of a million dollars went into it. Yes it shipped, but very few customers used it. That's seriously damaging to morale. The worst part was that we knew we were working on something useless.
This stings. I’ve spent so much of my software career writing code that management just threw away after months of work because priorities shifted, or money moved, or a C suites mistress didn’t like the name of it. It’s beyond frustrating to design, implement, and actually complete a hard software product that never sees the light of day.
This is over simplifying it. There are dozens of reasons- currently my job is fairly easy and we are shipping to the customers but we are understaffed so I’m supposed to keep track of 20 separate things. When the appropriate amount for this company would be 2-3.
I usually quit because I lose hope in the senior leadership.
No matter what your project is, whether it is a fun thing with friends or a big corp, the people organizing it always have to keep in mind that everybody is in it for a reason.
Abondon these reasons for long enough and people will not give you their full potential. Abandon those reasons longer and they will be gone. And you will be left with those who think they can still extract value from you or those who have problems saying "No" — a organization only consisting of these two types is dysfunctional.
As a manager/director/producer you should be aware what the reasons are for your team members and keep track of whether you believe you can honor those reasons.
That principle is diluted in most corps because money is involved. As someone who had to keep teams functional where members worked for free I believe it would be wise for more managers to understand how to do this.
It is better to say: "Bob, I know you are in it for $reason, but I am afraid we will have to do $Y for the next to months. I promise you I will try to make it better for the time after!" than knowing it will be shit for them and saying nothing in the hope that Bob won't notice. He will. And he will remember.
CGP grey did a video like this that's still my favourite example of the format: https://www.youtube.com/watch?v=LO1mTELoj6o