Comment by dirtybirdnj
13 days ago
I think your comment can be boiled down to "management doesn't respect engineers"
That's the fundamental problem. Some MBA or book somewhere convinced people that respect and dignity were optional. Once they realized they could apply this to more than engineers they started painting the entire world with this bullshit.
Let me take the opposite point - it isn't that management does or doesn't respect engineers, but that it does not respect them more or less than sales, or product, or marketing, or legal, or any other part of the system.
If all of sales says "I am losing these deals because our competitors have X, and I cannot make my quota without X, and you do not make your numbers without X." - how do you balance that against a department head who says, "I cannot give you any features this quarter because we've been focusing on features over codebase health for too long?"
Someone who says no for too long doesn't last.
> Someone who says no for too long doesn't last.
I actually think the engineering manager is probably in the wrong there, because if killer feature X is that critical to sales, then it needs to be prioritized in among the tech debt. It doesn't matter that the codebase health is not great if sales plummet. Being a good employee means sometimes prioritizing the health of the business and not the ergonomics of the work environment. And being a good manager means understanding when the health of the business is really at stake or whether the sales team is just throwing shade because they don't want to sell what the company has.
So, I absolutely agree here that an engineering manager has to have the insight to tell truth from catastrophising on both sides. At the same time, I've seen sales orgs drive a department into the ground where everything comes to a screeching halt. I've seen times where that "feature X" is vaporware. Times when feature X is possible there because of different architecture choices. Newer entrants who learned from the older entrants. Features that look great for smaller customers that can't scale.
And all of those might be plausible answers. As you'd agree, nuance is key here. However, that is all from the department or product head. Now consider the CEO's perspective that has 8 equally loud voices all clamoring for resources.
My point is that it might not be disrespect but rather a management team that is trying to navigate competing priorities and economic realities.
In most organizations the engineering manager would share that prioritization responsibility with a product manager who acts as the voice of the customer. One simple approach is to just divide team capacity into two buckets: 80% for new features and customer bug fixes, 20% for tech debt. The specific percentages can vary based on circumstances.
2 replies →
This is an important point. Many people lose sight of the idea that tomorrow doesn't matter if you don't survive today.
This comment shows great understanding and experience. Too often engineers treat work like their pet/FOSS project and forget it's a business, and businesses are in business to make money, not pretty code bases.
I generally believe engineering is right in this sort of hypothetical. But, at some point if they really are focusing on code quality… I mean, ultimately the point of code quality is to deliver features/reduce maintenance over the long run, right? So if they really are doing a good job of improving code quality, over the long run they should have a good relationship with management and the political capital to make this request.
From an outside point of view, focusing on code quality and playing videogames instead of working look identical over the short term (or more realistically, working on little niche bits of the code or doing tidying-up busywork that doesn’t really improve the overall quality of the project—it could legitimately be hard to tell the difference). Of course, it should eventually become apparent that the latter group didn’t actually accomplish anything in that time.
“How do you balance the,” I guess it is a social thing/judgement call ultimately.
Code maintainability could be analogized to 5S in the manufacturing world. As a hypothetical let's say someone started assembling some product on the bare concrete warehouse floor because they had a pressing order to fill. A few months later it's just a mess of parts strewn about the floor that workers have to sift through to find the correct pieces for the assembly. The goal of a business is to make money, not have a clean workspace as a sibling comment mentioned. Ultimately this would leave a company vulnerable to a competitor who doesn't have such an expensive and inefficient production process though.
I've worked on many, many features that never recouped their engineering cost despite the absolute assurance by sales that it was necessary. It would have been more effective long term to work on improving code maintainability so that we could better capitalize on features that substantially affect revenue in a positive direction. All too often I see that code maintainability only matters to the business when features can no longer be reliably and quickly delivered, but by then it's usually too late to really change course. This sort of balance also tends to drive all of the new fancy frameworks that cause so much churn as the signal from the business to engineering is that engineering needs to be able to pump out features very quickly but will not be given time to focus on maintainability so naturally this gets outsourced to someone else.
To be fair, I have also been involved in an emergency project that if it wasn't completed in a very tight time frame the company would have lost 30% of their revenue and there would have been substantial workforce reductions. We did not focus on maintainability in this situation rather we focused on saving the company.
Everything is a trade-off in business. My experience tells me companies generally focus on short term profit over long term concerns and there's very little in the way of feedback mechanisms that allow an inspection of these decisions in aggregate to see if the right balance is being struck.
Someone who says yes for too long, doesn't blast- out of the airframes plug.
> Some MBA or book somewhere convinced people that respect and dignity were optional.
Whatever the origin, this is actually a very serious problem that afflicts our society at large, well beyond MBA culture.
Software engineers tend to downplay artists, designers, marketing and product.
Frankly everyone downplays someone else based on their social circle. The only people who don’t have wide social circles but most people don’t.
"Everyone thinks their job in the Silo is the most important. Mine actually is." -- Juliette Nichols (also some Software Engineers)
Personally I think it's just their social circles that reinforce this, not the boogeyman MBA stuff. Because at some level, yes, they can be intimidated by technical people and this is a defense to avoid the "why am I even employed" spiral.
It would be nice if they could meet us half-way on the technical stuff. They regularly merge architects and sysadmins into developer roles making us learn more stuff.
I think they take them for granted not realizing that things can get much worse. I think they do this because they don't understand it. Ever been on a call with a company and they have to tell you, "You'll have to call back, our systems are down." This can cost millions an hour.
I'm an engineer with an MBA and they definitely don't teach in business school that respect is optional. It's just something bad managers do all on their own.