Comment by bruce511
13 days ago
I work on a product that has been built over 25 years. Lots of the work I did years ago is to ensure the product longevity.
Lots of the work I do now is to ensure it lasts another 25 years. Thats good, but its only the start of "my work".
It's up to me to "sell" that benefit to upper management. There's no point in assuming they'll figure it out by accident. Part of my job is enumerating the value I add.
By all means work on technical debt. But be sure to make a compelling case as to how the eradication of that debt will impact the project over the next decade. Try and throw in immediate results as well (faster, more reliable, reduced support) but more importantly translate that into terms that measure the improvement in cold hard cash.
100%, although also:
Try to be as objective as possible when evaluating that tech debt. It's possible (in many cases, probable) that the tech debt actually isn't as bad for the business as an engineer perceives, and it's quite possible there are other engineering efforts that are more worthy of development time and resources.
Being willing and vocal about acknowledging and accepting that reality is also quite helpful.
How do you put numbers in there usually? I'm facing an issue at work where an important factor should be done to correct a serious design mistake, but it doesn't get in the way of any feature. It's probably the cause of a lot of loss of development time over the lifetime of the project, but I don physically know how much of a boost will it give to development.
I know it will, but I wouldn't feel comfortable without quantifying.
I have some rough idea for approaches to this, but would appreciate some external input as well
One way to communicate this is in terms of _schedule risk_, rather than straight-up lost productivity. E.g. for a particularly troublesome design flaw, you might estimate that for any given 4-week project there's a 20% risk of the project blowing out by an extra week due to that flaw.
Depending on the stakeholder(s) you're dealing with, approaching it like this (as risk assessment/management) might help to convey the short-term impact of a long-term problem.
It can be tough, and in some cases measurable numbers are hard to find. That can make prioritization hard.
It's worth keeping open the option that "now is not yet the right time".
One key way to understand the situation well is to explore both thd upsides and downsides of the issue. Its almost never an obvious decision and being acquainted with all points of view really helps both to figure out what is right, whether it's worth doing, if now is the right time, and so on.
If it was obviously necessary it would likely already have been done, so it may be necessary, but it might not yet be time.
Sometimes it comes down to groundwork. Finding out who us affected, and how. (And if you can't find those people, that's a clue too.)
Indeed, I was the one suggesting to not do the refactor because I couldn't find a reason. Today at standup though, a task that would take 1 hour once the refactor is done, will probably take about 2 days instead, so i'm back thinking about it (the refactor would take longer than 2 days)
I only do small solo projects but the value from maintainable code depends on how often it needs to be updated.
If management comes with new [crazy] ideas and/or feature [cruft] every other week it should be easy to prefer a warehouse with ready to use components over a scrap yard. If you need a set of usable tires a few times per year the scrap yard will provide. If you need a set of tires 20 times per day you want at least 200 sets of each kind stored in a convenient place. You probably live some place in between.
edit: Also, timing is everything. Write down everything you want, add the pony. Wait for the right moment when their head is not raging with 50 deadlines.
Most important imho is to not want anything but explain what options they have. If they want faster results they might be able to get them by attacking the technical debt.
> How do you put numbers in there usually?
Make them up. If you're uncomfortable with this, ask ChatGPT to make them up for you. Most places don't have any real way to measure productivity or rate of feature delivery, so as long as you promise a reasonable number (5-10%) they have no way of contradicting you.
Incremental refactoring is also the other classic way to do this. Slip bits into other tickets until you've slowly dragged the ship around. But it's not always possible.
I get your point at the basic level, but as engineers and managers, we need to stop this nonsense. Think deeper about why do you need to "sell" your work inside (some) companies ? Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work. What's the value such busywork managers are adding, besides the anti-value of layers of explanatory communication and wasted time? The busywork folks should be working to understand where their salaries are coming from, not the engineers. Note that I am not saying all managers are useless (its also a part of my job), it's the people-and-ideas-managers who are useless in the technical setting. The point about technical debt should be a non-issue, why the hell would you have to explain that the technical debt is a bad thing? Did we not clear this issue many times over and establish zero technical debt as an engineering ideal a long time ago? Well it is because some person with 1/4 of your experience and competence somehow got lucky and talked themselves into one or two hierarchical positions above you. We need to start a pushback across the industry and stop allowing former accountants and humanist science graduates into "leadership" roles in IT.
Could it be because those companies are full of people who somehow occupy important positions without understanding the basics of the engineering work.
Every company I've ever worked at has more work that they would like to do than they have engineers to do it. The problem often isn't that they don't understand why fixing technical debt is important, it's to decide if fixing that particular technical debt right now is the best use of these resources right now. Also they might also know things that I might not know, like long term plans for and the relative profitability of different projects, which will affect how they make decisions. No point in spending effort fixing technical debt if that project/department is already slated for closure.
Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
Sometimes they're looking for the next big product that will make millions but IMO they never really stack the odds of that working against the chance of losing current business through not updating, improving their current offering to make it e.g. more sticky.
Hence you work on "huge priorities" and then they turn out to attract 2-3 tiny customers....Meanwhile you have horrendous problems with things that do sell that make them inconvenient for your customers such that they will be delighted to go elsewhere the moment they find out that your competition does it better.
> Every company I've ever worked at has more work that they would like to do than they have engineers to do it
I've worked at a couple of BigTechs, where there were between 5-20x more engineers than actual work. The trade-offs are... strange in that world.
> Also maybe it's a US vs EU thing, but at every engineering and IT company I've ever worked in Europe, the person two steps above me was basically always an engineer or at least has a science or technical background.
I haven't found that to be common in the US. I've had a number of front-line managers who were (somewhat) recent engineer conversions, rarely had anyone above that level who was.
2 replies →
There’s a difference between management knowing that it’s worth paying off tech debt in general, and management knowing that now is the right time to pay off this piece of tech debt in particular.
Why pay off tech debt A and not tech debt B? Is this really more urgent than implementing feature C?
I have some financial debts, but I prioritise paying off some over others, and even allow myself to buy myself nice things instead of paying off the mortgage early. The same principle applies with tech debt, except I have to justify my choices to my bosses instead of to my girlfriend.
Fortunately I don't work in such an organization, and I have extremely competent in my chain of command.
The reason I explain the value of what I am doing (to both technical and non-technical managers) is because it helps them understand the bigger picture.
Or perhaps it helps them understand that I see the big picture, so that they know (and I know) our goals are aligned.
I am aware that not everyone is as fortunate as I am. I'd equally suggest that not many managers are fortunate enough to have engineers that can articulate what they are doing in terms they can understand.
There are plenty of managers out there who are not team players. And probably more engineers who are equally unable to see the bigger picture. Which is unfortunate because when you learn to work together towards a common goal, it really improves everything.
Please don´t take it as trolling - but if your higher ups are as competent as you say: why do you need to help them with the big picture ? Shouldn´t they be the ones setting it or at least directing? I am saying this because topics like improvement of performance and reduction technical debt were established as drivers of revenue a long time ago. That is why Amazon optimised the sh*t out of their checkout process and Google (before they were took over by the business types) obsessed about page loading times. Oh coincidentally - that was also the time when major tech companies were run mainly by engineers. Is that why their products used to be so much better? Too many "busyworkers" are now wasting everyone's time by having engineers explain "the big picture" so that they can present it at some meeting and take credit for. And in the process, the products get more entshittified every damn day.
> Think deeper about why do you need to "sell" your work inside (some) companies
Mainly to prove you can sell, not that they can buy. Selling involves understanding the customer's needs, their tradeoff preferences, your value prop and being able to reflect that back to them. The minimum bar for successful selling requires you to demonstrate a certain degree of competence and due diligence that provides assurance that you're able to operate autonomously with trust.
No, actually. He said it was a part of his job because they did not understand his work? So we are back at square one here, why do people not understanding engineering work, end up managing engineering work?
4 replies →
That's an excellent summary!
Man, you are making too much sense, somebody is going to have his feelings hurt by your words. Management is now trying to have even more control on the people that actually do things, and AI is being used as scapegoat to entrench their position. The reason is fear, because most managers couldn't do even 1/10 of the work people under them can do.
"zero technical debt" is a pipe dream. Not all tech debt is equal; think "low-interest student loan or mortgage" vs "high-interest credit cards or payday loans".
Well, that is why I said it was an ideal, something to strive for. Since we are in lecture-mode here, ever heard of objectives and key results? Think that would be a more fitting alternative to your black-and-white metaphor of low-interest vs. payday loan ...
4 replies →