undefined | Better HN

0 pointsebiester3y ago0 comments

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.

0 comments

3 comments · 1 top-level

mmcnl3y ago· 2 in thread

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.

ebiesterOP3y 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.

mmcnl3y 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.

j / k navigate · click thread line to collapse