[jeremyperson]

Love it. "Work with enduring value leaves a service permanently better, whereas toil is “running fast to stay in the same place.” Therefore, as a service grows, unchecked toil can quickly spiral to fill 100% of everyone’s time."

[mlthoughts2018]

It depends on the point of view of management. In a lot of companies, managers don’t care about tech debt much and see “toil” as the rightful majority mode of work that engineers ought to focus on. They may simply lack the capacity to understand what an investment in paying down tech debt to free engineer time could buy them, or they may view that process as too risky, or they just may not care.

There are a lot of managerial reasons why this happens. It’s one of the biggest lines of questioning I pursue in job interviews, to try to understand what point of view people have elsewhere in the food chain about how (or if) engineers add value to the business.

[nostrademons]

There are two sides to this:

On one hand, good management should realize that automating repetitive tasks and paying down technical debt is how you add to a tech company's capital stock, and is the only reason why tech company valuations tend to go parabolic. If you're just trading money for labor and labor for customer's money, you have a consulting service business. These can be profitable, but you don't build an enduring asset this way, and the valuations that business owners usually think about when they decide to start a tech company are those that come from owning a monopoly asset that you can sell to multiple customers for virtually no additional cost.

On the other hand, the part that engineers are usually blind to is the business context that the company operates in. Tech moves fast. It's not uncommon for basically all of a company's founding assumptions to be obsolete 3 years later. New tech platforms are available; customers want different things; a new competitor has just demoed a killer feature. All of these have the possibility to render large swaths of a product's feature set obsolete. There's no sense investing engineering time in a codebase that's about to be killed anyway; just rack up the technical debt and declare bankruptcy. Worse, management often can't tell engineering about many of these external realities without killing the product: would you continue working for a company that said "Our competitive position is untenable. Pump out as many features before anyone external notices so we can sell the company" or "We need you to keep the lights on for our existing customers while this secret division over there builds the next generation of the product"?

It's often good to ask questions about the company's overall strategy and competitive position (and to do research on this yourself) before joining. While the owners usually won't tell you everything, it'll build trust if they can tell you some things. They should be able to think of these issues in terms of trade-offs: "What's technical debt?" is the wrong answer, but so is "We care deeply about technical debt and give our engineers as much time as they want for code cleanup" (the latter is a bullshit answer, designed to make the hire). Similarly, it builds trust if engineers can also recognize the business tradeoffs and accept that sometimes the right answer is to hack something together and ship it so the customers can get value while management figures out the next strategic move.

[lapnitnelav]

I think -and it depends on the corporate culture / industry- the value of culling toil, ergo using tech as force multiplier for tech problems, is both beyond their grasp and is a threat to the status quo.

Much like the type of fuel injection used in a combustion engine is irrelevant to most people that use their car.

If you are managing a hauling company and a brand type of fuel allows you to save 20%, you can see the value but you also know that it means updating your fleet, infra and all the costs and hassle associated with that. Which means that while you are keen on making those savings, you probably will not roll out fleet update ASAP.

I think this is how in companies which are not pure IT players, management might see those situations. Yes there is some value in reducing the toil but the perceived costs are too high for them to be fully on board, and I guess it's because their perspective is too rooted in the physical world (i.e my example).

Not that there are no costs when automating toil management in IT, it just doesn't map 1 to 1 to the real world equivalents.

[aliswe]

Shouldn't that be something like "innovation is about improving a process permanently, whereas toil is continous, laborious work only for /status quo/ to be preserved"?