I'm not commenting too much on the details of the article, but the premise does resonate with me. I would argue all the engineering teams I've been on do not spend enough time thinking about how much a piece of work will cost to execute, and whether it will generate a return.
I suspect this is most apparent on things like meeting culture. Something happens and all of a sudden there is another recurring meeting on the calendar, with 15 attendee's, costing x dollars in wages, that produces no value for the customers because the lesson was already learned.
Or when reacting to an incident of some sort, it's so easy to have a long list of action items that may theoretically improve the situation, but in reality are incredibly expensive for the value they produce (or the risks they reduce). It's too easy to say, we'll totally redesign the system to avoid said problem. And what worries me, is often those very expansive actions, then cause you to overlook realistic but small investments that move the needle more than you would think.
And as a hot topic I also think the costs are an input into taking on tech debt. I know we all hate tech debt with a passion, but honestly, I think of it as a tool that can be wielded responsibly or irresponsibly. But if we don't know what our attention costs, we're going to have difficulty making the responsible choices about when and where to take on this debt. And then if we're not conscious about the debt, when it comes do it stings so much harder to pay down.
> I would argue all the engineering teams I've been on do not spend enough time thinking about how much a piece of work will cost to execute, and whether it will generate a return.
These things are almost never the responsibility of engineering teams, nor should they be. Engineers read about these things and get it into their head that they should be worrying about them. In effective organisations, these decisions are made elsewhere, by people better qualified to make these determinations. It's an ineffective organisation that leaves these sorts of decisions to their engineering teams.
Meetings aren't even the worst resource wasters. Wrong initiatives, features, apps/platforms/services are. They capture future resources in form of maintenance and complexity with them.
Agreed, and this is where I think some more nuanced and conscious use of tech debt can be used when applicable.
It might be OK to place some bets on an initiative or feature, but if we all understand we're placing a bet, this is an area to load up on debt and really minimize the investment. This also requires an org that is mature about cutting the feature if the bet doesn't materialize, and if the market signal is generated will reinvest in paying down the debt. And also has the mega-danger territory of a weak market signal, where it's not clear if there is market signal or not, so the company doubles down into the weak signal.
Also these bets shouldn't be done in isolation in my view, well executed product and market discovery should also provide lots of relevant context on the ROI.
Totally agreed! I think good orgs that run well have a good feedback process and ownership between the individual teams. In my experience, the closer they work together, the more visible the impact is on ROI. The less context everybody has, the higher the risk that an initiative goes sideways and doesn't fully match the intent.
And yeah, cutting features and offloading debt is important. I love that part when starting an engagement! It's a bit of work to check critical execution paths and how customers actually use a product, but it's a good excercise for everybody to see the relationship between revenue and code.
This all sounds easy and in reality it's not the hardest, but for some reason no one is doing it.