Why Your Best Engineers Are Interviewing Elsewhere, Codegood

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.

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

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.)

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.

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.

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.

Maybe a few years ago sure.

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.

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?

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.