Technical debt is a function of management's priorities.
If management does not see good practice as a priority or prefers not to make long term choices, then there is no managing technical debt. What happens is that the number of engineers grows faster than the management and management will leave some number of engineers relatively unattended who will take it upon themselves to be a "hero" (jargon for someone who does thankless work) while they slowly become more cynical doing the equivalent of janitorial work.
The gambit every manager is making is that with today's investments in product you can hire a team to solve infrastructure problems tomorrow. That is because all these companies get advice from companies with very successful exits, but fail to see the survivorship bias and fail to see that being in a rocket ship is different than being in a cessna. Your company's advisor from google/investor's advisor from google is giving you advice from the perspective of a company that could hire an engineer and devote them to a microscopic problem if they wanted. Advice from companies that are not practically resource bound is bad advice.
Another important thing to consider is that these upper management types might incur a lot of technical debt in order to get short term gains which pads their resume which allows them to go to other companies where they then do the same thing. This is the conflict of interest that results in technical debt. Managers can create problems they won't have to solve because they can just leave.
Short-termism is a disease that can only be fought via leadership, and the fish rots from the head.
By the third time you see an obvious problem not being addressed until it becomes a catastrophe, it's probably time to understand that your leadership doesn't get it.
My take is take the lessons of other cynical people who work near operations and only work on feature production. Don't ever be the poor sap fixing problems before they are a catastrophe because nobody can understand the catastrophe before it happens. Nobody can measure the impact of resolving a catastrophe before it happens.
Comments
Technical debt is a function of management's priorities.
If management does not see good practice as a priority or prefers not to make long term choices, then there is no managing technical debt. What happens is that the number of engineers grows faster than the management and management will leave some number of engineers relatively unattended who will take it upon themselves to be a "hero" (jargon for someone who does thankless work) while they slowly become more cynical doing the equivalent of janitorial work.
The gambit every manager is making is that with today's investments in product you can hire a team to solve infrastructure problems tomorrow. That is because all these companies get advice from companies with very successful exits, but fail to see the survivorship bias and fail to see that being in a rocket ship is different than being in a cessna. Your company's advisor from google/investor's advisor from google is giving you advice from the perspective of a company that could hire an engineer and devote them to a microscopic problem if they wanted. Advice from companies that are not practically resource bound is bad advice.
Another important thing to consider is that these upper management types might incur a lot of technical debt in order to get short term gains which pads their resume which allows them to go to other companies where they then do the same thing. This is the conflict of interest that results in technical debt. Managers can create problems they won't have to solve because they can just leave.
Short-termism is a disease that can only be fought via leadership, and the fish rots from the head.
By the third time you see an obvious problem not being addressed until it becomes a catastrophe, it's probably time to understand that your leadership doesn't get it.
My take is take the lessons of other cynical people who work near operations and only work on feature production. Don't ever be the poor sap fixing problems before they are a catastrophe because nobody can understand the catastrophe before it happens. Nobody can measure the impact of resolving a catastrophe before it happens.