How Engineering Leaders Balance Platform Work vs Product Features

The call between platform investment and customer features is the one I've gotten wrong most often, and the wrong direction is almost always the same. Shipping features feels urgent and measurable. Platform work feels invisible until it isn't. Left to defaults, most teams under invest in the platform and pay for it later in compounding slowness.

The framework I use now is pretty simple. I ask three questions before making the call. How many future features will move faster if we do this platform work now. How much time is the team currently losing to the problem we'd be fixing. And what happens if we wait another quarter. If the platform work speeds up multiple upcoming features, is eating measurable team hours every week, and gets harder to fix the longer we wait, it goes to the top of the list regardless of what customers are asking for. If only one of those is true, it can usually wait.

The story that drew the line for me happened a couple of years in. We had a deployment process that took about forty minutes and failed unpredictably maybe once a week. Every engineer knew it was bad. Every engineer had adapted to it. And every quarter we pushed fixing it to the next one because customer features felt more important. One quarter I actually added up the cost. Between failed deploys, context switching, and the quiet drag on anyone shipping anything, we were losing close to a full engineer's worth of productive time every week. We were paying the cost of a platform engineer to not have one.

We spent three weeks rebuilding the pipeline. Deploys dropped to a few minutes and stopped failing randomly. Within a month the team was shipping noticeably more customer features than before, because the hidden tax had been so heavy that removing it freed up more capacity than the platform project had cost. I'd been framing it as a tradeoff between platform and features when it was actually the opposite. The platform work was the feature work.