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