3 ms·

The other problem with “tech debt” time (and same with “devops”) is it becomes a bucket for all kinds of stuff that isn’t tech debt at all. For example upgradin

The other problem with “tech debt” time (and same with “devops”) is it becomes a bucket for all kinds of stuff that isn’t tech debt at all. For example upgrading framework versions, fixing bugs, and so on. Not necessarily wrong to do these instead but it is kind of the team fooling itself. Instead I think you need the unicorn of someone who understands product and engineering and can decide at any given time whether to pay down tech debt or add a new feature.

ebiester 4y ago
This is why I prefer a balance of "Product Initiatives" and "Engineering Initiatives" and that number has to be bigger than 10% because of all that it encompasses. The hard part is explaining to the business the return on investment on engineering initiatives because often times, product thinks of this as a zero sum game. They really care about the sum output of features, but it gets conflated with the number of hours placed in product development. It is engineering management's task to break that mental model.
- mmcnl 4y ago
  I honestly think they're the same. If you think they're not then you simply haven't thought it through well enough, which means you need to spend more time on that.
  - ebiester 4y ago
    There are some subtle differences, but framing is important. Debt has connotations of digging yourself into a hole. If you are in a new project, you likely have all sorts of tools that you would like to build. You are not in debt to start - you have no code! This gives latitude for thinking ahead and it also allows for including things like enablement and platform teams. Debt retirement, in this view, is a subset of technical initiatives. And some of that technical initiative budget should also go to product teams.
    - mmcnl 4y ago
      That is true but framing it as technical budget means there is no business benefit. This is false. Long term maintainability and increased innovation speed are clearly business benefits that you hide behind ambiguous terms if you use wording such as technical debt. Just be specific. Technical debt isn't specific.

ebiester 4y ago

This is why I prefer a balance of "Product Initiatives" and "Engineering Initiatives" and that number has to be bigger than 10% because of all that it encompasses. The hard part is explaining to the business the return on investment on engineering initiatives because often times, product thinks of this as a zero sum game. They really care about the sum output of features, but it gets conflated with the number of hours placed in product development. It is engineering management's task to break that mental model.

mmcnl 4y ago
I honestly think they're the same. If you think they're not then you simply haven't thought it through well enough, which means you need to spend more time on that.
- ebiester 4y ago
  There are some subtle differences, but framing is important. Debt has connotations of digging yourself into a hole. If you are in a new project, you likely have all sorts of tools that you would like to build. You are not in debt to start - you have no code! This gives latitude for thinking ahead and it also allows for including things like enablement and platform teams. Debt retirement, in this view, is a subset of technical initiatives. And some of that technical initiative budget should also go to product teams.
  - mmcnl 4y ago
    That is true but framing it as technical budget means there is no business benefit. This is false. Long term maintainability and increased innovation speed are clearly business benefits that you hide behind ambiguous terms if you use wording such as technical debt. Just be specific. Technical debt isn't specific.