Upcoming Webinar: Scaling Alignment in Engineering Teams Register Now

Celebrating the Menders who Enable Continuous Product Health

Technical Debt

Celebrating the Menders who Enable Continuous Product Health

New features and big launches tend to get all the in-house publicity in most organizations. Those are the visible milestones that indicate success and forward momentum. And they should be celebrated! But there’s equally important work, like paying down technical debt, that we don’t often celebrate with the same vigor.

The engineers who conduct that work deserve to be appreciated just the same. And you can start to incorporate the importance of their work into your organizational culture to keep it at the fore.

“It’s not one hundred percent about new features,” said Andrea Goulet, CEO at Corgibytes, in our recent roundtable on Working With Technical Debt. “If your organization is there, changing that mindset is the first step in paying down your technical debt. If you’re not thinking about it on a regular basis, it’s accumulating all the time.”

Investment in fixing work should always be going on—just like feature work is. We discussed the idea of rebranding “addressing technical debt” as Continuous Product Health in this post about getting buy-in for fixing tech debt. Your codebase requires ongoing maintenance to maintain optimum shape, just like a house or your body does.

However, because maintenance work isn’t treated as sexy as feature work, it gets left behind. The engineers who like doing the feature work, we all call “Makers,” and they get plenty of opportunities—maker fairs, maker magazines, you name it. Goulet has a term for engineers who thrive on fixing code: Menders.

“Just like there are introverts and extroverts in the world, there are people who naturally gravitate towards feature work and who naturally gravitate towards fixing work,” she explains. “So build your team so that you’ve got people who enjoy doing both.”

We’ve identified two particular kinds of menders that we’re celebrating here and now: those who mend as they go, and those who are full-time menders.

Mend as you go

Your codebase at large is constantly evolving by its very nature, but it doesn’t evolve evenly in all aspects. Engineers working on the code will spot shortcomings, whether in their own past work or somebody else’s. Perhaps the deficiency wasn’t a deficiency when it was first written, but with the evolution of the code, it now falls short.

Engineers who exhibit this pattern spot what can be improved upon, and they mend the code while they’re working on something else—even if it’s not essential to what they’re doing. These mends are often low-risk changes that usually don’t change the logic of the code.

Not every engineer does this kind of mending—but honestly, it’s something that every engineer can (and should) do to contribute to a culture of continuous product health.

And it’s a behavior you can encourage in your team or organization. When you see this pattern appearing consistently in GitPrime’s data, you want to praise this behavior in a standup or otherwise publicly. Mending as you go is a highly desirable habit for engineers to model, because it keeps your technical debt in check instead of ignoring it until it grows unwieldy and burdensome.

You can also bring the mending-as-they-go engineers on board to help promote this behavior. Ask them if they’d like to do lunch and learn to show others what they’ve been working on, how they’ve been operating, and what they’re trying to accomplish. Some teams establish “advancing the state of the art” as a culture value, which also supports this pattern. Any of these approaches from a leader will help promote this pattern as a cultural touchstone, so that every engineer feels encouraged to mend as they go.

Full-time mending

Yes, every engineer on a team should be conducting maintenance work on a rolling basis. But there are engineers out there who absolutely love fixing things. They’d rather mend code and address technical debt than develop features.

Why not allow them to tackle those issues? And why not bring on board engineers who love that work?

The key is that you cannot lionize feature work at the expense of mending work. If you want to bring in true full-time menders, as Goulet has done at Corgibytes, you need to learn to manage them and motivate them by letting them do what they do best—namely, solving problems with trust and autonomy—as well as celebrate their contributions on par with their maker peers.

Beyond incorporating mending into your company culture, you can also improve your continuous product health by investing in your menders.

“There’s this inflection point between growth and stability where menders must surge, and you start to balance them more equally against the makers focused on new features,” Goulet says in a post on First Round Review. “You have your systems. Now you need them to work better.”

Making maintenance a priority for your organization—and making heroes out of menders just like we all do out of makers—will improve your team’s long-term productivity as well as pay dividends for your product’s performance, she says.

“The number one reason we see for security vulnerabilities is the failure to update twenty-third party dependencies,” Goulet explains. “Somebody’s got to do that work. It’s important, and it feeds the business value. If you don’t do it and everyone’s working on new features, you’re building your software in a house of cards.”

In other words, menders are the ones who ensure your organization’s longevity and success. Too often, they go unrecognized and unrewarded. So here’s to the menders!