Create deadlines arbitrarily and without discussion or even a feasibility check<p>Lie to their team about their criticality, before laying off half of the same team<p>Replace large amounts of management 3 times in a single year<p>Hire so many people nobody knows what their role is and everyone competes for influence<p>Ensure that every engineer has at least 5 hours of meetings a day, half of which aren’t relevant to their team.<p>Stack ranking<p>Don’t give them a raise for years despite praising them for being a top performer with large impact<p>Arbitrary KPAs which undervalue anything other than LoC<p>Make people be on call with no training for what theyre being on call for, and have critical alarms go off every 3 hours<p>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<p>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<p>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
<i>How to burnout a software engineer</i><p>This is just a specific variation on a theme that applies to all of STEM.<p>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.<p>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.<p>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.<p>The illogic here is deeply rooted and is fully illustrated by a phrase I heard over and over again down through my career.<p><pre><code> "No one gets paid until something gets sold"
</code></pre>
This is objectively true --- but no more logically valid than my counter point:<p><pre><code> "Nothing gets sold until something gets built"
</code></pre>
Bottom Line --- American corporate culture has an inherent bias toward those who sell and against those who create. This applies and is reflected across industries, regardless of the actual product being built and sold. And it has been this way for generations. The only workable way I found to change this was to dropout and start my own business.
Micromanaging, yes. Another one: synchronous meetings and random phone calls.<p>If I have a synchronous meeting at 11am, I get nothing of value done before 11am.<p>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.
- prioritize process over product<p>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 <i>must</i> be done, or the company dies.<p>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.<p>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.<p>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.<p>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.<p>Unfortunately it's a good way to burn out.
> Look, Google has a huge writing culture. Design docs are the norm there.<p>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.<p>"Docs? Just read the code," was a VERY common refrain there.<p>Google was absolutely non-negotiable on the necessity of checking in tests with your code, but missing docs was definitely the norm.
> Step 3: Don’t ship code to customers<p>In the same vein: "Shipping useless code".<p>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.
> Working on projects that never ship is, anecdotally, one of the largest causes of burnout.<p>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.
> Burnout happens when my work doesn’t matter.<p>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.<p>I usually quit because I lose hope in the senior leadership.
I don't consider well sourced any article that attempts to summarize burnout causes that doesn't mention pressuring workers to work long hours to meet impossible arbitrary goals imposed by leadership, or leadership pressuring teams to perform under veiled and not so veiled threats of dismissal.
As someone who worked in quite some no-budget films I think this article has some truth in it.<p>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 <i>everybody is in it for a reason</i>.<p>Abondon these reasons for long enough and people will not give you their full potential. Abandon those reasons longer and they will be <i>gone</i>. 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.<p>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.<p>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.<p>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 <i>knowing</i> it will be shit for them and saying nothing in the hope that Bob won't notice. He will. And he will remember.
I really like this format of telling people how to do the thing they don't want. Works way better, and is more memorable than doing the more common thing of telling people how to avoid the thing they don't want.<p>CGP grey did a video like this that's still my favourite example of the format: <a href="https://www.youtube.com/watch?v=LO1mTELoj6o">https://www.youtube.com/watch?v=LO1mTELoj6o</a>
It's mind boggling that people write blogs about trivial things like this... Are these people live on this planet called Earth or something is amiss?