Micromanaging, yes. Another one: synchronous meetings and random phone calls.
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.
I used to feel this was true for me, and to a large degree still do. But lately I’ve been wondering to what extent this is a self-limiting belief, and how much I can train myself to remain productive in the face of interruptions. My life is more complicated now than when my career started, and the interruption causers seem to be multiplying, so I’m seeing it as something I need to learn to deal with if I’m going to be able to stay in the field.
Since having kids I’m a lot more able to get in the zone for 1-2h at a time since I rarely get a whole day free (also due to a more senior position). I think it’s largely procrastination. But I also try to batch and minimize the meetings the engineers on my team have to take
I will tell you what. When I joined this field (decades ago) an entry level engineer would (after rampup) do more than whole teams do today.
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.
> 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.
I'm "secretly" pondering a formula where a group of employees share an assistant rather than a manager.
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 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.
Jfc. I'm going to slap the next person that claims they're blocked.
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.
You must really be a hot shot to afford this attitude, or you are one of these passive aggressive types that express it in subtle ways that do not get you fired. Let me explain something from the employers perspective. If you expect people to spend hours trying to figure out something that is not obvious, that could reasonably be cleared up with a five minute conversation with the expert (you, presumably) then you are wasting my money. I am paying both of you. I expect you to cooperate. I do not accept a toxic communication environment. Minimizing communication may increase productivity, but massively raises the risk of producing the wrong thing.
I agree with all of this. With the caveat that "resolved with a 5-minute meeting" isn't "my inbox is full of garbage so I'm too overwhelmed to read your 4-sentence email answering my question, therefore I'm phoning you to reiterate the problem you already fully understand and have dealt with, just to remind myself of what was in my email to you, before asking you to read to me verbally what you wrote in your email."
Let me explain something to you: if every time you don't know something you start bitching about it and ask everyone around you until you wear them down to ELI5 you are dragging everyone down.
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?
I'm not saying I'm blocked or blocking someone, I'm saying I'm tapping out. At 4pm-something I'm not going to spend the next half hour reloading the context in my head and getting back to where I had been before the 2-minute (i.e. 15-minute) call, not because I can't, but because I'm tired and don't want to.
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.
Create deadlines arbitrarily and without discussion or even a feasibility check
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
Claim you work "like open source", proceed to have six disparate systems I have to log into every day.
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.
> 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
This seems to be the trend in US business culture as a whole. I work in a more industrial sector, but the same problems persist: Repeated management turnover and restructuring. Despite top performer reviews, withholding promotions and raises. Under hire/over work personnel (“we run lean here”). Preach cost cutting on public side with the need for layoffs, all while hosting extravagant trips and dinners for upper management behind closed doors. Petty department politics and nepotism.
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.
Don't forget to ask them to be a "Mentor" then lay off anyone that they are actively mentoring. Then at their performance review ask how their mentorship is going...
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.
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.
> Working on projects that never ship is, anecdotally, one of the largest causes of burnout.
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 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"
This is objectively true --- but no more logically valid than my counter point:
"Nothing gets sold until something gets built"
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.
I suspect I'm not alone in saying this, but having started my "tech" career in marketing/eCommerce agencies, I have _definitely_ worked in organizations where the sales team would sell absolutely anything they could get somebody to agree to buy -- fully ignorant of whether it had been (or even COULD be) built.
oh dear, I thought that was common only in my own marketing-in-tech career! My solution was to move away from the agency and to the agency's vendors, instead. Worked so far, a decade on!
I work on sales/customer facing side of a non-tech industry, but my experience has been different than root comment. My industry is engineer/finance driven, with sales as more of an afterthought or necessary evil. I try to stay tied in with the development/production side as much as possible for sales, but the mismanagement and culture rot on the development/production side has me looking for a new job as it spreads through the company. It’s tough seeing top performers leave/forced out and petty politics and mismanagement take over. It makes my job much harder. The rot has eventually trickled down to other departments, so I think it’s time to make an exit.
sell absolutely anything they could get somebody to agree to buy
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.
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.
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.
A similar thing happened to me. It's absolutely bizarre when it's happening and even more so in retrospect. Every engineer knows it's a product that no one wants. That experience triggered terrible burn out for me.
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.
As someone who worked in quite some no-budget films I think this article has some truth in it.
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.
44 comments
[ 3.2 ms ] story [ 85.3 ms ] threadIf 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.
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 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.
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 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.
This is objectively true --- but no more logically valid than my counter point: 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.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.
CGP grey did a video like this that's still my favourite example of the format: https://www.youtube.com/watch?v=LO1mTELoj6o
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.
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.
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.