Comment by ebiester
12 days ago
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.
"Some portion of your time is reserved to work on whatever you want to work on with no input from outside your small team" does not work long term and it does not work at scale.
Even among engineering software is somewhat unique in that we intentionally make sub-optimal decisions and then expect other departments not to raise an eyebrow when we demand time away from the next set of features to address (some of) those decisions, usually introducing more sub-optimal decisions in the meantime.
Nobody has figured out a better way to do it but it's easy to see why non-technical people would be inclined to think tech debt is just a way to do less "real work."
1 reply →
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.