redroot

> I think it's a mistake to ask non-experts to prioritize things they don't understand.

Exactly right, for the most part if the business has enough trust in engineering to do the best they can, the technical strategy to realise business value is up to engineering, including 'debt'.

The most effective strategy I've seen so far is my current employer. We split our time across the quarter. 60% to core product focuses for the quarter, 20% to ad-hoc requests from the business, and 20% to 'tech improvement'. The latter includes personal growth for new engineers related to our stack or exploring new tech, improving our current tooling, and addressing areas of 'tech debt'. This split is agreed with the business, and the tech lead in a team is responsible for maintaining the balance and has autonomy here too - often we see areas of debt that impact our product focuses so that becomes core for example. It takes trust on all sides but seems to be working well.

I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we don't have to worry about it because are a growing startup and debt is normal.

Two alternative explanations I've begin to use over the last few years that have helped:

1) Inertia / Inert Areas - the reason this 'debt' is a problem is it means future changes are hard to execute cleanly, and previously. An area becomes inert to change unless an intervention is made. For non-technical stakeholders they most important thing is often that we can keep making changes, so this sets all sorts of loss aversion alarm bells ringing in a way the term 'debt' doesn't - this is where you can start talking about risk, which crosses the divide between engineering and other functions quite well.

2) Product Debt - Yes in some cases code is just badly written, which is an engineering concern, but often the reason changes in Year 5 are hard to make because the domain / reality has moved on, and the assumptions baked into the code written in Year 2, no matter how clean the code, are now just wrong. For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering, just the reality of a product that continues to persist - core changes are inevitable. Product leaders therefore need to also get strategic about when it makes sense to rethink previous decisions driven by product needs, and work with engineering leaders to mitigate otherwise you might end up in an inert ball of mud unable to hit goals.

In the most idealised vision of a piece of software, changes will get harder to make in a linear fashion if previous decision are not revisited will new information. In worst case it's more like an exponential graph, so intervention steps will always have to be taken.

As you say, once you're talking the same language, then you get into the details about what strategies to address this inertia / current conditions.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

I'm interested to hear what the opinion on jQuery are like these days. Even if it's a little unglamorous, this is the perfect use case - a one-off project where you have needs for cross-browser animation, resizing, DOM manip, and where something like React might be overkill, even if feasible. CSS animations might be an alternative but it depends on audience browser breakdown.

Ex-employee here, left a while before this process started. We had a really strong product, and loyal and growing user base, who rated us over Cite This For Me consistently. It's a shame for the users that it ended this way, I naively hope that CTFM pull their finger out and improve their product