This week I'm thinking about how to make sure that engineering maintenance and tech debt work doesn't get forgotten as product focus locks in and metrics start to hit statistical significance.

I've never had great success finding time for ongoing engineering work in organizations who saw the two types of work as independent concerns. There are some "stop the world" type of events that can be scheduled, but that scheduling effort tends to fade over time. So here's my approach on how to get into shared mindset.

Note: if this isn't an issue at your workplace, kudos! you're free to go enjoy the rest of your day 🎉

Engineering needs a list of projects and importance.

This doesn't have to be a tricky thing to make. Work like: updating dependencies, improving observability, outdated pattern cleanup, and future looking scaling adjustments exist for all teams.

Engineering can't come to the planning meeting with "we needs space", but needs to come with "here's how we can keep this platform working well for our customers..."

Product needs to be aware the importance of keeping the codebase maintained.

Product knowing about the health of the platform is vital. If this is a struggle, you likely need to make some sort of chart to tell the story. Cycle Time is the golden metric here, but it's a tricky one to meaningfully measure. I've found that collecting lots of things together (PRs merged, LoC written, Deploys, Deploy time, Cyclomatic Complexity of a codebase, test coverage, outdated dependencies) can help paint the picture.

Bringing them into the eng side of things is needed to make it feel like a shared space. Their success is controlled by the time that developers can make for their ideas. So it's possible that in their minds, more time == more success. Work from that assumption to convince them that actually success comes from health collaboration.

Make sure there's a way to recognize engineering work that matches the way product work is recognized.

This is more work for the EM, but without it, the work won't get done without it. Interrupt demos, add to slide templates, whatever it takes to note progress and impact.

Then 🤞🏻 when it's roadmapping and planning time, it'll be easier to make space for this kinda work. Retro and repeat.

I try to avoid analogies because software engineering and the organizations around it are very unique. Talking about what's unique there is important. Cars, houses, and children are all tempting analogies, but fall apart when it gets into making hard decisions. Use them carefully.