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.
Ehh. The SMA post is too disconnected to play an ear-to-ground role. Always felt more ceremonial or focused on soldier quality-of-life issues that didn’t really matter.
The real conduit for change in the military is a good stiff Congressional or IG complaint. Ask anyone who drove an MRAP.
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.
Less punchy but close to the truth: people leave for a lot of reasons. I can’t think of a time I’ve quit over a bad boss. Bosses come and go, even bad ones. If you only ever have bad bosses, that’s an executive problem, not a manager problem.
I guess the point is that a lot of those other reasons are caused by managers.
Gotta put up fights with other teams to do your job? Manager should be unblocking you.
Got no tools, bad computer? Manager should be putting up a fight.
Low salary? Manager should be negotiating on your behalf.
But on the other hand, maybe I'm just old fashioned.
Today, in the world of micromanagement, line-managers aren't expected to be much more than cannon-fodder to be blamed by C-levels when developers are unhappy.
> Today, in the world of micromanagement, line-managers aren't expected to be much more than cannon-fodder to be blamed by C-levels when developers are unhappy.
Exactly. Line managers take the heat from above and below. In a dysfunctional organization, they can make your life worse but they have very limited ability to make it better. That’s why I object to the “people quit bad managers” quote. It’s just not true to my experience, and it absolves poor executive leadership from responsibility.
That makes sense. Funny enough, the person who told me that was a C-Level who was blocking salary increases that were long overdue. I ended up leaving, ha.
I have quit because of bad management, but never because of one bad boss. (Or it may have been one bad boss, but it was high enough up the management chain that I didn't know specifically who it was.)
One of the biggest reasons I left a company was because the CTO and his toady, both coming from company X, made a unilateral decision to switch to X's proprietary and expensive framework above senior developers' objections because, in his words, if people leave the company, we can always go back to company X to support the application written in X's proprietary framework. Um, yup. Never mind that framework was totally inappropriate for the application, or that the UI looked like a refugee from 2000. Oh, and never mind that the biggest customer had nothing but trouble in another application written in said expensive proprietary framework.
That mindset plus a dash of RTO equaled me out the door.
I recall from the Lost Connections book that this was one of known causes of depression. People doing the same job, but with a sense of empowerment and ownership, were quite protected from such a negative outcome.
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'm not sure of the motivations (the author is definitely trying to market themselves), but I think the insights here are really spot on. Having recently left an employer who was undergoing many of these experiences, it felt almost too accurate. That said, there's one main thing that I think is missed here:
It's not just about executives being surprised by what engineers are thinking. It's also engineers not understanding the purpose and goals of the business.
Consider a typical startup environment. Lots of highly competent, experienced engineers working at startups will willingly, even excitedly make choices which are expensive, unscalabe, unmaintainable, etc., in the name of getting things out the door fast. They do that not because they enjoy creating problems but because they, and the startup's leadership, are aligned. The goal of the startup is to push a good proof-of-concept, get customers and investors, and gain traction to become a going concern.
Likewise, in an environment that is well-established and used to delivering a certain quality on a certain timeline, those same engineers will do more expensive, scalable work for less reward, and be rewarded. This feels uncommon because we don't hear about it a lot, but there are tens of thousands of small, capable, going-concern companies that do exactly this. They go on year after year, making a profit and delivering a decent to great product, without a lot of fanfare. They don't run away to billion-dollar valuations, and they don't crash out. It's just fine.
But in still other organizations, it's rarely made clear that the org doesn't value the things engineers assume, by default, ought to be valued. For example, an organization might say they want reliability, scalability, good design, etc., then repeatedly make decisions indicating that isn't what they value. They do not communicate their goals to the engineers. They do not say their actual intentions. They claim to want A, actually want B, ignore and deprioritize work that'd help produce B, and then are surprised when people are distrustful and resign.
I have no problem with doing a job a certain way if that's what I signed up for and you ask me to do it upfront. But if I signed up for A and you gave me B without warning, I might just leave. And I wouldn't bother to tell you why on the way out.
(Also, I think that there's a slight error in the author's timelines: Junior engineers would notice after senior engineers that senior engineers are checked out, since it's the senior engineers doing the checking out. But they'd probably notice before management does.)
> It's also engineers not understanding the purpose and goals of the business.
This is a oft-repeated canard which is untrue 99% of the time. By the very decision to join a company, the Engineer has signaled that he understands the business' purpose and goals. Only after joining a company does he come to see that the process of execution towards the said objectives is untenable.
The problem is almost always the enduring fiction in Management teaching that one can manage a business without knowing much about the domain in which the business operates. This false belief becomes fatal the more technical the domain is since the non-linearity of the effects due to events in the domain is what makes or breaks a business.
As the author, it's less about marketing and more about scratching my itch as a shy writer to explain some of the things I've experienced and seen. Having spent 12 years as a Royal Marine, and seen behaviours that map into the startup and corporate world, I'm using the time that I now have to write more and share opinions. Your comment about my timelines is partially valid. There are situations where the timelines are indeed reversed.
I've been thinking about resurrecting my blog, but never have the will to go through it. Perhaps after writing a couple entries it'll be worth putting it up.
I liked the article, but I also laughed a bit because <sarcasm>it was the engineers’ fault that they didn’t rise to the occasion and skip-level to save the company!</sarcasm>
in my short employment career I have never seeing orgs with that those layers of management ship anything useful.
things take time to get shipped, teams spend a lot of time in meetings.
personally my preference is a flight hierarchy. a team then its team lead who ships code - reports to CTO. Product & Design report to engineering. likewise you need fewer product managers if needed at all.
Ok but what do you do when you have a large company that works on... 50 products all in parallel? This doesn't exactly scale. You can't have 50 team leads ALL reporting to the CTO.
Companies can be successful despite bad practices though. Google is successful and they developed multiple competing chat apps, but that doesn't mean that developing multiple chat apps will make one successful.
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?
I appreciate the attempt to explain in executive speak that engineers may not be fungible, that they can be costly to replace, that the organization will suffer if attrition gets out of hand, and that their decisions can influence these outcomes. I don’t think it quite hits the mark for organizations where this is a problem, because I think bad executives play a fundamentally different game. I’m not quite sure what it is, but the success of the company doesn’t seem to influence their decision making. Maybe it’s just that confidence in their ability to fail up makes success irrelevant?
Product Managers? I've seen them brushing off concerns so that it doesn't even reach to senior leadership. I've once had an entire team coming to a CTO for a very serious meeting (TM), and the surprise was the CTO assuming the team was overloaded, while the team claiming there were not tasks. The PM basically lied to save her butt.
Engineering Managers? Those tend to be more transparent, as long as they are actually technical.
I'm a contractor. I've worked at 11 different companies since 2010. Here is what I have observed: Engineers are happier when their managers are also skilled engineers. Of the companies that I've worked at, only 3 operated this way. The 3 that "got it right" were small to mid-size companies (and they all got acquired a year or two after I started).
Imagine if 70% of all foremen on construction sites were accountants by trade that don't even own or use a screw driver or a hammer in their personal life. That's pretty much the situation at most places where they use software to support their business, but their business is "not software". This is of course the perspective of a non-engineer, as an engineer would be quick to point out that their business is increasingly dependent on the software; How exactly will you make money when your website is down and your infrastructure is failing?
Everyone should be empowered to make as many decisions as possible. It gives people agency.
To make good decisions, you need context, knowledge, good judgement, and clear boundaries. The context gets built by managers who do a good job.
I've spent a decade of my career at 15Five where we've built a system of doing just that based on a weekly check in. When done well it worked marvelously.
Depending upon the size and dynamics of the team/organization the probability can be very low. You have to be ready to face Objections, Conflict, Suspicion, Politicking and really really want to do it.
Start with setting up a one-on-one with the CTO or VPoEng privately, have your points clear before going in, anticipate their pov and make it very very clear that you are being open and honest. You have to really focus on communicating persuasively with emotion; which people do naturally when they really believe in what they are doing.
> 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.
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.)
No, because the VPE was doing it out of ego and because he thought the problem was easy, not out of any practicality.
No amount of argument was enough.
This was his only job, he was at the company for 10 years, was a schoolfriend of the CTO and suddenly got promoted to VPE when the company grew over 50 devs. So total lack of experience.
The funny thing is we didn't even need to prototype: another team had already integrated the same third-party in their own project, so there was ZERO doubts, we had an in-house expert.
Do people really give candid feedback in skip levels? Your skip obviously doesn't trust your boss if they are having them. Are you really going to bad mouth your boss? They have the most direct control over your career at the present company.
If you don't feel free to be honest with your skip level that's on all 3 of you to fix.
If I put my own spin on something my boss has already explained is a problem he's working on, this gives my skip level confidence we all understand the problem approximately the same. If I say, "this thing came to me that I don't really agree but I'm doing my best to get it done" this only reflects well on both me (taking one for the team) and my boss (he carried forward an unpopular thing and trusted me to give it a shot).
And if I say, "this other team's behavior is causing me this problem" that's just facts. Data that we can all use to fix it. Maybe my skip level can explain the competing priorities and I'll decide to solve my problem another way.
If people usually don't see that the house is on fire, they won't see it or care about it if you point at it. The fact that you have to do that says a lot.
Seen this time and time again. Motivated engineers will leave, smart engineers will realize nothing actually matters and fall into doing as little as possible to complete a given task knowing it'll be thrown away/deprioritized/etc. Continue to collect a paycheck (and possibly raises and promotions) without truly doing anything meaningful. LLMs have been a boon for this type of engineer who realizes the pointlessness of it all and can see through the reality distortion field your average CTO has.
I've been at companies where we have had to beg for a few hours a QUARTER to do meaningful fixes outside of bandaids. These are pushed off time and time again until suddenly the company is weeks out from a costly SEV0 and then it's an emergency. But, while time is finally given it's only enough to bandaid it for another year. I've been at companies where the pagerduty alarm go off every 15 minutes with actual problems. Despite complaints nothing changes. Instead, management decides we're all incapable and adds more process but still grants no time. There have been numerous times in my career where I effectively have 2-4 bosses, meetings, and status reports and am still expected to somehow deliver something that requires deep thinking. For this fact alone I am thankful for LLMs because I can completely disconnect from my work, check the LLM, and dump whatever garbage it gives out. At the end of the day it's not "me" so who cares.
"Skip level" meetings are worthless. Meeting with your VP/CTO is just going to be a bunch of ceremony around what they want you to do and you telling them what they want to hear. No one wants to hear they're incompetent, and you'd be stupid to tell them so given they sign your check. It turns into a ritual of "yes sir" and nothing gets done.
Then the yearly company feedback comes around and one of two, or both things happen:
1) The questions are catered so that they can be interpreted in a positive light either way. Either you agree with <question> or you don't understand the importance of <question/question-compliment>. You are made to look stupid.
2) They deliberately ignore negative feedback.
The truth is, unless your company is putting the VP/CTO/CEO on the L1 pagerduty cycle and having them woke up at 3am every night nothing will change. There are too many layers of bureaucracy involved as the article points out. That's why the "leadership" is always "surprised" when the company burns down. They simply do not feel anything at all relative to what the people actually building the product feel. They get a wild hair and want a fizz-frobnicator added that will produce net-negative return on investment. You do it, because despite how stupid it is you have to.
As long as they get their 3 martini lunches, bonuses, and mansions, it doesn't really matter. We've all seen and heard enough of their bullshit to know even the the "best" bosses are absolute snakes.
Truth is, no one wants to build things to last anymore. We live in a reality where everything including you, your dishes, and your software are disposable commodities. At least in actual engineering there are some laws available to protect you from having to do things that are deliberately putting people at risk. We have no such protections especially in this economy.
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.
https://reddit.com/user/sma-pao/?sort=top
Don't NCOs have a very hard ceiling of promotions and compensation which ends around lowest rungs of officer levels?
Not sure understand your point. The post is talking about information and you are talking about pay?
My point is that it's not really parallel is it?
Ehh. The SMA post is too disconnected to play an ear-to-ground role. Always felt more ceremonial or focused on soldier quality-of-life issues that didn’t really matter.
The real conduit for change in the military is a good stiff Congressional or IG complaint. Ask anyone who drove an MRAP.
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.
That and/or a single bad direct line manager.
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.
This is the second best advice I ever got in my career.
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.
Less punchy but close to the truth: people leave for a lot of reasons. I can’t think of a time I’ve quit over a bad boss. Bosses come and go, even bad ones. If you only ever have bad bosses, that’s an executive problem, not a manager problem.
I guess the point is that a lot of those other reasons are caused by managers.
Gotta put up fights with other teams to do your job? Manager should be unblocking you.
Got no tools, bad computer? Manager should be putting up a fight.
Low salary? Manager should be negotiating on your behalf.
But on the other hand, maybe I'm just old fashioned.
Today, in the world of micromanagement, line-managers aren't expected to be much more than cannon-fodder to be blamed by C-levels when developers are unhappy.
> Today, in the world of micromanagement, line-managers aren't expected to be much more than cannon-fodder to be blamed by C-levels when developers are unhappy.
Exactly. Line managers take the heat from above and below. In a dysfunctional organization, they can make your life worse but they have very limited ability to make it better. That’s why I object to the “people quit bad managers” quote. It’s just not true to my experience, and it absolves poor executive leadership from responsibility.
That makes sense. Funny enough, the person who told me that was a C-Level who was blocking salary increases that were long overdue. I ended up leaving, ha.
Maybe people quit bad management, instead of bad managers, then?
Yep. That actually makes more sense in modern micromanagey companies, especially tech companies.
I have quit because of bad management, but never because of one bad boss. (Or it may have been one bad boss, but it was high enough up the management chain that I didn't know specifically who it was.)
One of the biggest reasons I left a company was because the CTO and his toady, both coming from company X, made a unilateral decision to switch to X's proprietary and expensive framework above senior developers' objections because, in his words, if people leave the company, we can always go back to company X to support the application written in X's proprietary framework. Um, yup. Never mind that framework was totally inappropriate for the application, or that the UI looked like a refugee from 2000. Oh, and never mind that the biggest customer had nothing but trouble in another application written in said expensive proprietary framework.
That mindset plus a dash of RTO equaled me out the door.
Edit: spelling
I recall from the Lost Connections book that this was one of known causes of depression. People doing the same job, but with a sense of empowerment and ownership, were quite protected from such a negative outcome.
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'm not sure of the motivations (the author is definitely trying to market themselves), but I think the insights here are really spot on. Having recently left an employer who was undergoing many of these experiences, it felt almost too accurate. That said, there's one main thing that I think is missed here:
It's not just about executives being surprised by what engineers are thinking. It's also engineers not understanding the purpose and goals of the business.
Consider a typical startup environment. Lots of highly competent, experienced engineers working at startups will willingly, even excitedly make choices which are expensive, unscalabe, unmaintainable, etc., in the name of getting things out the door fast. They do that not because they enjoy creating problems but because they, and the startup's leadership, are aligned. The goal of the startup is to push a good proof-of-concept, get customers and investors, and gain traction to become a going concern.
Likewise, in an environment that is well-established and used to delivering a certain quality on a certain timeline, those same engineers will do more expensive, scalable work for less reward, and be rewarded. This feels uncommon because we don't hear about it a lot, but there are tens of thousands of small, capable, going-concern companies that do exactly this. They go on year after year, making a profit and delivering a decent to great product, without a lot of fanfare. They don't run away to billion-dollar valuations, and they don't crash out. It's just fine.
But in still other organizations, it's rarely made clear that the org doesn't value the things engineers assume, by default, ought to be valued. For example, an organization might say they want reliability, scalability, good design, etc., then repeatedly make decisions indicating that isn't what they value. They do not communicate their goals to the engineers. They do not say their actual intentions. They claim to want A, actually want B, ignore and deprioritize work that'd help produce B, and then are surprised when people are distrustful and resign.
I have no problem with doing a job a certain way if that's what I signed up for and you ask me to do it upfront. But if I signed up for A and you gave me B without warning, I might just leave. And I wouldn't bother to tell you why on the way out.
(Also, I think that there's a slight error in the author's timelines: Junior engineers would notice after senior engineers that senior engineers are checked out, since it's the senior engineers doing the checking out. But they'd probably notice before management does.)
> It's also engineers not understanding the purpose and goals of the business.
This is a oft-repeated canard which is untrue 99% of the time. By the very decision to join a company, the Engineer has signaled that he understands the business' purpose and goals. Only after joining a company does he come to see that the process of execution towards the said objectives is untenable.
The problem is almost always the enduring fiction in Management teaching that one can manage a business without knowing much about the domain in which the business operates. This false belief becomes fatal the more technical the domain is since the non-linearity of the effects due to events in the domain is what makes or breaks a business.
Relevant Reading:
1) A radical article from HBR, First, Let’s Fire All the Managers : https://hbr.org/2011/12/first-lets-fire-all-the-managers
2) Speech by Dave Packard to HP Managers (1960) - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... (this is one of my favourites)
3) Also see the book Why we do what we do: Understanding Self-motivation by Edward Deci and his Self-Determination Theory(https://en.wikipedia.org/wiki/Self-determination_theory) for insights.
As the author, it's less about marketing and more about scratching my itch as a shy writer to explain some of the things I've experienced and seen. Having spent 12 years as a Royal Marine, and seen behaviours that map into the startup and corporate world, I'm using the time that I now have to write more and share opinions. Your comment about my timelines is partially valid. There are situations where the timelines are indeed reversed.
Thank you for writing it so I don't.
I've been thinking about resurrecting my blog, but never have the will to go through it. Perhaps after writing a couple entries it'll be worth putting it up.
I liked the article, but I also laughed a bit because <sarcasm>it was the engineers’ fault that they didn’t rise to the occasion and skip-level to save the company!</sarcasm>
No one bothers to ask why do you need
1. Engineering Manager
2. Senior Engineering Manager
3. Director
4. VP of Engineering
5. CTO
in my short employment career I have never seeing orgs with that those layers of management ship anything useful.
things take time to get shipped, teams spend a lot of time in meetings.
personally my preference is a flight hierarchy. a team then its team lead who ships code - reports to CTO. Product & Design report to engineering. likewise you need fewer product managers if needed at all.
Ok but what do you do when you have a large company that works on... 50 products all in parallel? This doesn't exactly scale. You can't have 50 team leads ALL reporting to the CTO.
Why not? What better things does the CTO have to do?
the nvidia CEO has 50 direct reports, yet he's running the most valuable company.
Companies can be successful despite bad practices though. Google is successful and they developed multiple competing chat apps, but that doesn't mean that developing multiple chat apps will make one successful.
Shh, people who think differently get shut out.
I agree massively btw, most orgs are so incredibly bloated its funny to observe.
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?
I appreciate the attempt to explain in executive speak that engineers may not be fungible, that they can be costly to replace, that the organization will suffer if attrition gets out of hand, and that their decisions can influence these outcomes. I don’t think it quite hits the mark for organizations where this is a problem, because I think bad executives play a fundamentally different game. I’m not quite sure what it is, but the success of the company doesn’t seem to influence their decision making. Maybe it’s just that confidence in their ability to fail up makes success irrelevant?
It depends on who's talking.
Product Managers? I've seen them brushing off concerns so that it doesn't even reach to senior leadership. I've once had an entire team coming to a CTO for a very serious meeting (TM), and the surprise was the CTO assuming the team was overloaded, while the team claiming there were not tasks. The PM basically lied to save her butt.
Engineering Managers? Those tend to be more transparent, as long as they are actually technical.
I'm a contractor. I've worked at 11 different companies since 2010. Here is what I have observed: Engineers are happier when their managers are also skilled engineers. Of the companies that I've worked at, only 3 operated this way. The 3 that "got it right" were small to mid-size companies (and they all got acquired a year or two after I started).
Imagine if 70% of all foremen on construction sites were accountants by trade that don't even own or use a screw driver or a hammer in their personal life. That's pretty much the situation at most places where they use software to support their business, but their business is "not software". This is of course the perspective of a non-engineer, as an engineer would be quick to point out that their business is increasingly dependent on the software; How exactly will you make money when your website is down and your infrastructure is failing?
18 months ago yeah, but these days you're lucky to get an email rejection no matter the pedigree on your resume
People try to define the manager's job. There are many decent definitions, but one I really like is:
The essence of a manager's job is to push context down and pull information up. Here's a short article that explains it well: https://jacobian.org/2021/apr/19/the-fundamental-purpose-of-...
Everyone should be empowered to make as many decisions as possible. It gives people agency.
To make good decisions, you need context, knowledge, good judgement, and clear boundaries. The context gets built by managers who do a good job.
I've spent a decade of my career at 15Five where we've built a system of doing just that based on a weekly check in. When done well it worked marvelously.
In this economy?
Maybe a few years ago sure.
To whoever wrote this... thank you!
As a team member, is it possible to change a team like this?
Yes, but ...
Depending upon the size and dynamics of the team/organization the probability can be very low. You have to be ready to face Objections, Conflict, Suspicion, Politicking and really really want to do it.
Start with setting up a one-on-one with the CTO or VPoEng privately, have your points clear before going in, anticipate their pov and make it very very clear that you are being open and honest. You have to really focus on communicating persuasively with emotion; which people do naturally when they really believe in what they are doing.
> 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.
That's what skip level connections and surveys are for. The tools are there, for organizations that care to use them.
I don't know.
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.
> tearing apart feedback from surveys
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.)
I had this today when I cancelled a Microsoft Subscription, where it asked me for feedback on why I left.
One of the options they gave was because "My company needs an AI solution".
None of the options had anything to do with why I was unsubscribing.
Well, it was just a simple NPS, people were giving zeroes, so they decided to ask why.
People didn't answer so they made it anonymous.
In the end they just expected amazing results without putting up the work.
That was another YC hellhole, by the way. I'm out of this shit, I still frequent HN but I'm done with Paul Graham affiliated assholes.
Just wondering, was there ever any discussion about trying a quick prototype with a 3rd party auth solution before trying to go off and build one?
No, because the VPE was doing it out of ego and because he thought the problem was easy, not out of any practicality.
No amount of argument was enough.
This was his only job, he was at the company for 10 years, was a schoolfriend of the CTO and suddenly got promoted to VPE when the company grew over 50 devs. So total lack of experience.
The funny thing is we didn't even need to prototype: another team had already integrated the same third-party in their own project, so there was ZERO doubts, we had an in-house expert.
That’s unfortunate.
Do people really give candid feedback in skip levels? Your skip obviously doesn't trust your boss if they are having them. Are you really going to bad mouth your boss? They have the most direct control over your career at the present company.
If you don't feel free to be honest with your skip level that's on all 3 of you to fix.
If I put my own spin on something my boss has already explained is a problem he's working on, this gives my skip level confidence we all understand the problem approximately the same. If I say, "this thing came to me that I don't really agree but I'm doing my best to get it done" this only reflects well on both me (taking one for the team) and my boss (he carried forward an unpopular thing and trusted me to give it a shot).
And if I say, "this other team's behavior is causing me this problem" that's just facts. Data that we can all use to fix it. Maybe my skip level can explain the competing priorities and I'll decide to solve my problem another way.
If people usually don't see that the house is on fire, they won't see it or care about it if you point at it. The fact that you have to do that says a lot.
>company survey
Cool, I can honestly tell them how I feel and what's not working
>your input is not anonymous
Everything is smooth sailing, 4s and 5s
Seen this time and time again. Motivated engineers will leave, smart engineers will realize nothing actually matters and fall into doing as little as possible to complete a given task knowing it'll be thrown away/deprioritized/etc. Continue to collect a paycheck (and possibly raises and promotions) without truly doing anything meaningful. LLMs have been a boon for this type of engineer who realizes the pointlessness of it all and can see through the reality distortion field your average CTO has.
I've been at companies where we have had to beg for a few hours a QUARTER to do meaningful fixes outside of bandaids. These are pushed off time and time again until suddenly the company is weeks out from a costly SEV0 and then it's an emergency. But, while time is finally given it's only enough to bandaid it for another year. I've been at companies where the pagerduty alarm go off every 15 minutes with actual problems. Despite complaints nothing changes. Instead, management decides we're all incapable and adds more process but still grants no time. There have been numerous times in my career where I effectively have 2-4 bosses, meetings, and status reports and am still expected to somehow deliver something that requires deep thinking. For this fact alone I am thankful for LLMs because I can completely disconnect from my work, check the LLM, and dump whatever garbage it gives out. At the end of the day it's not "me" so who cares.
"Skip level" meetings are worthless. Meeting with your VP/CTO is just going to be a bunch of ceremony around what they want you to do and you telling them what they want to hear. No one wants to hear they're incompetent, and you'd be stupid to tell them so given they sign your check. It turns into a ritual of "yes sir" and nothing gets done.
Then the yearly company feedback comes around and one of two, or both things happen:
1) The questions are catered so that they can be interpreted in a positive light either way. Either you agree with <question> or you don't understand the importance of <question/question-compliment>. You are made to look stupid.
2) They deliberately ignore negative feedback.
The truth is, unless your company is putting the VP/CTO/CEO on the L1 pagerduty cycle and having them woke up at 3am every night nothing will change. There are too many layers of bureaucracy involved as the article points out. That's why the "leadership" is always "surprised" when the company burns down. They simply do not feel anything at all relative to what the people actually building the product feel. They get a wild hair and want a fizz-frobnicator added that will produce net-negative return on investment. You do it, because despite how stupid it is you have to.
As long as they get their 3 martini lunches, bonuses, and mansions, it doesn't really matter. We've all seen and heard enough of their bullshit to know even the the "best" bosses are absolute snakes.
Truth is, no one wants to build things to last anymore. We live in a reality where everything including you, your dishes, and your software are disposable commodities. At least in actual engineering there are some laws available to protect you from having to do things that are deliberately putting people at risk. We have no such protections especially in this economy.
Took the words right out of my mouth, couldn't agree more