Across the clients I've worked with over the years it's often bureaucratic disempowerment that drives good engineers away.
When they cannot affect change or encumbered with toil - be that from painful change management processes, restricted or privacy invading operating system controls, or a work from office policy.
The military has a parallel system of officers (managers) and enlisted/NCOs (sort of ICs).
Even generals will have an NCO reporting into them whose job is to speak to the frontline and figure out wtf is actually going on.
e.g. The Sergeant Major of the entire US Army used to post on /r/army. If someone in the 950,000 person bureaucracy was really getting screwed, he or his office would step in.
I have seen CEOs and CTOs tearing apart feedback from surveys at all-hands meetings. To the point of mocking answers and saying people are "tripping", or that "in other YC companies people work 80 hours".
And I've seen leads/managers leaving due to micromanagement as well.
As long as the expectation is for managers to hide concerns and fall in line, the information will be hidden from C-levels.
For example:
> A fintech company decided to build their own authentication system rather than use established solutions.
I lived this exact scenario. Fintech wanted custom authentication! It was pushed into my team. I said no and put my foot down, VPE disagreed with me and gave to another team. That team failed to deliver after 6 months, and my team finally ended up being the one implementing a third-party solution in a couple weeks. That third-party solution costed less than $100 per month, because of how little users we had.
On my yearly feedback I still got knocked down a peg due to this incident. It really hurt my career at that company, even though I was in the right. That other team failed to deliver other projects too, and we got the same feedback I did, same salary increase. I got the yelling, I got the negative marks.
Of course people will rationalize this with "you should have been more political".
Well, that's what the people being criticized in TFA are doing: being political.
That's amateur behavior. Real pros design the feedback forms in a way that only allows you to give them the answers they want to hear.
"Which three company benefits are most important for you?" Frankly, all of them are meaningless, but there are ten checkboxes, and unless you mark three of them, the form won't allow you to proceed.
"Do you understand how $buzzword can make you more productive? (on a scale from 0 to 10)" Answering "yes" implies that $buzzword is great. Answering "no" also implies that $buzzword is great, but you are too stupid to understand it, so you may be given some mandatory training on $buzzword. (There is no way to indicate that $buzzword actually makes you less productive.)
Appreciate the time taken to write this, but imho the problem is a bit worse: you grew up in a context where analysis of facts, risks, knowing your stuff, were valued. That's your training data and reinforcement function.
Here's the thing: the world in general didn't get that training data upload. They don't care about your reasoned analysis. They want a new boat. Like now!
I bet there's an email thread at Amazon years back with someone saying "You're using DNS as a distributed database-- that's a bad idea". But even after crashing the entire internet for a day, the stock is up.
I recommend starting your own company or going freelance. Then at least any organizational nonsense will be your nonsense. And if there's any boat coming it'll be yours.
I love the optimism that senior leadership is just in the dark and wouldn't agree with a high percentage of the bad dynamics. With the benefit of hindsight the causal link to attrition is highlighted. In the moment, how many concerns would have been brushed aside as nerds getting carried away with nerd priorities instead of business priorities?
> The decision was made: ship now, refactor later.
I guess we already know how this ends. There will never be "refactor later", because there will always be a new feature to add, or a new product to ship. "Later" is merely a diplomatic way to say "never". When the project is decommissioned 20 years later, the refactoring tasks will still be in the project backlog; that is if someone won't delete them first.
> The CEO approved 15% raises for remaining engineers. More left anyway.
One possible explanation is that money wasn't the real issue. But another possible explanation could be that the 15% was not enough, but ironically it could have been the nudge that made people think again about their salaries.
> Middle managers believe they are doing their jobs by "handling problems at their level."
That is not necessarily a bad thing... unless they are handling them by ignoring them.
> The monitoring system generated so many false alerts that engineers had learned to ignore it.
That reminds me how I once told my manager: "If I get one alert a week, I will immediately drop whatever I was currently doing, and start investigating the issue. If I get several alerts a day, I will finish my current work first, and probably handle the issues in batch at the beginning or at the end of the day. If I get several alerts per hour, I will just mute my phone and ignore them."
> They watch decisions being made that will cause problems, they raise concerns, and they are told to implement anyway. When the predicted failure occurs, they are blamed for not preventing it.
Even better, they get assigned an on-call duty during evenings and weekends to fix the failures when they occur. The on-call duty is such a wonderful thing -- every time a bad technical decision is made, you know someone's evening or weekend is going to get ruined, but it is rarely going to be the person who made the decision.
> If Sarah is leaving, maybe I should look too. Engineers assume departing colleagues know something they do not.
I think this is a needlessly complicated explanation. More likely, Sarah was a good friend, and the colleagues who were already unhappy about their jobs procrastinated with leaving the company because of Sarah. Now that Sarah is gone, they realize they don't have any more positive job-related emotions.
Of course the company can speed this up by giving them Sarah's work on top of the work they already had. Then everyone will start interviewing like crazy, because they will be scared of being the last person who stays at the company and inherits everyone's work.
> The test: would a 20% raise keep them? If yes, it is compensation. If no, it is something else and they are being diplomatic.
Or maybe it's compensation, and the other company offers them 50% more.
> Regular skip-level conversations. Allocating several hours per week for direct conversations across all levels provides ground truth.
I have seen a situation where a manager did skip-level conversations, but only used them to tell the engineers his glorious vision, not to listen to them. It's like most management advice -- even if the original idea is great, most people will just take the buzzword and do something else instead.
When they cannot affect change or encumbered with toil - be that from painful change management processes, restricted or privacy invading operating system controls, or a work from office policy.
One of the best managers I worked under when I was young used to say "people don't leave companies, they leave managers" and he was right.
The best one was still "Listen to reports when they come to you, even if you're focused on your own task."
I wish there was this kind of advice for dealing with unreasonable CTOs and VPEs. I got lucky in my last job, but it took years.
Even generals will have an NCO reporting into them whose job is to speak to the frontline and figure out wtf is actually going on.
e.g. The Sergeant Major of the entire US Army used to post on /r/army. If someone in the 950,000 person bureaucracy was really getting screwed, he or his office would step in.
https://reddit.com/user/sma-pao/?sort=top
I have seen CEOs and CTOs tearing apart feedback from surveys at all-hands meetings. To the point of mocking answers and saying people are "tripping", or that "in other YC companies people work 80 hours".
And I've seen leads/managers leaving due to micromanagement as well.
As long as the expectation is for managers to hide concerns and fall in line, the information will be hidden from C-levels.
For example:
> A fintech company decided to build their own authentication system rather than use established solutions.
I lived this exact scenario. Fintech wanted custom authentication! It was pushed into my team. I said no and put my foot down, VPE disagreed with me and gave to another team. That team failed to deliver after 6 months, and my team finally ended up being the one implementing a third-party solution in a couple weeks. That third-party solution costed less than $100 per month, because of how little users we had.
On my yearly feedback I still got knocked down a peg due to this incident. It really hurt my career at that company, even though I was in the right. That other team failed to deliver other projects too, and we got the same feedback I did, same salary increase. I got the yelling, I got the negative marks.
Of course people will rationalize this with "you should have been more political".
Well, that's what the people being criticized in TFA are doing: being political.
That's amateur behavior. Real pros design the feedback forms in a way that only allows you to give them the answers they want to hear.
"Which three company benefits are most important for you?" Frankly, all of them are meaningless, but there are ten checkboxes, and unless you mark three of them, the form won't allow you to proceed.
"Do you understand how $buzzword can make you more productive? (on a scale from 0 to 10)" Answering "yes" implies that $buzzword is great. Answering "no" also implies that $buzzword is great, but you are too stupid to understand it, so you may be given some mandatory training on $buzzword. (There is no way to indicate that $buzzword actually makes you less productive.)
Here's the thing: the world in general didn't get that training data upload. They don't care about your reasoned analysis. They want a new boat. Like now!
I bet there's an email thread at Amazon years back with someone saying "You're using DNS as a distributed database-- that's a bad idea". But even after crashing the entire internet for a day, the stock is up.
I recommend starting your own company or going freelance. Then at least any organizational nonsense will be your nonsense. And if there's any boat coming it'll be yours.
I guess we already know how this ends. There will never be "refactor later", because there will always be a new feature to add, or a new product to ship. "Later" is merely a diplomatic way to say "never". When the project is decommissioned 20 years later, the refactoring tasks will still be in the project backlog; that is if someone won't delete them first.
> The CEO approved 15% raises for remaining engineers. More left anyway.
One possible explanation is that money wasn't the real issue. But another possible explanation could be that the 15% was not enough, but ironically it could have been the nudge that made people think again about their salaries.
> Middle managers believe they are doing their jobs by "handling problems at their level."
That is not necessarily a bad thing... unless they are handling them by ignoring them.
> The monitoring system generated so many false alerts that engineers had learned to ignore it.
That reminds me how I once told my manager: "If I get one alert a week, I will immediately drop whatever I was currently doing, and start investigating the issue. If I get several alerts a day, I will finish my current work first, and probably handle the issues in batch at the beginning or at the end of the day. If I get several alerts per hour, I will just mute my phone and ignore them."
> They watch decisions being made that will cause problems, they raise concerns, and they are told to implement anyway. When the predicted failure occurs, they are blamed for not preventing it.
Even better, they get assigned an on-call duty during evenings and weekends to fix the failures when they occur. The on-call duty is such a wonderful thing -- every time a bad technical decision is made, you know someone's evening or weekend is going to get ruined, but it is rarely going to be the person who made the decision.
> If Sarah is leaving, maybe I should look too. Engineers assume departing colleagues know something they do not.
I think this is a needlessly complicated explanation. More likely, Sarah was a good friend, and the colleagues who were already unhappy about their jobs procrastinated with leaving the company because of Sarah. Now that Sarah is gone, they realize they don't have any more positive job-related emotions.
Of course the company can speed this up by giving them Sarah's work on top of the work they already had. Then everyone will start interviewing like crazy, because they will be scared of being the last person who stays at the company and inherits everyone's work.
> The test: would a 20% raise keep them? If yes, it is compensation. If no, it is something else and they are being diplomatic.
Or maybe it's compensation, and the other company offers them 50% more.
> Regular skip-level conversations. Allocating several hours per week for direct conversations across all levels provides ground truth.
I have seen a situation where a manager did skip-level conversations, but only used them to tell the engineers his glorious vision, not to listen to them. It's like most management advice -- even if the original idea is great, most people will just take the buzzword and do something else instead.