The other day I wrote about engineering team balance, and I want to expand on the subject a bit.

There’s a common sense idea in the tech industry that a happy engineer is a productive engineer. The important thing to remember is that (broadly speaking) with two different kinds of engineers, there are different things that keep them happy (and conversely, different ways to burn them out, which are worth knowing in order to avoid).

Obviously managing a team is a big subject. My goal here is to just point out a few differences and get you thinking about what’s going to be best for your situation.

I’m going to start with the the ‘best practice’ engineer who loves having things done right.

The best practice engineer is likely to appreciate extra time to refactor and pay down technical debt. Every programmer appreciates some time to clean house, but it’s much more valued by the best practice engineer. It’s like people who hate clutter – they can do great work, but they want things to be very organized. This type of engineer is going to do well on code that’s intended to stay around for a long time. They’re going to appreciate the freedom to spend time refactoring code for readability, writing good documentation, and beefing up automation (test coverage, deployment, etc).

When working with a best practice engineer, sometimes you don’t have the luxury of giving them as much time as they’d like to have – and that’s ok. The point is to make sure there’s a healthy amount.

Let’s say you’re running a Lean environment, very early stage project, and you’re running various experiments. This type of work can really burn out a best practices engineer, because doing pure TDD does take time, and usually Lean adherents are looking for gains in both quality and speed. When you’re releasing features and you know that you’re going to be removing ones that don’t perform, it’s worth taking out a loan on your technical debt.

The problem is that it is very easy to lose focus on the debt and look for the next set of experiments because “it’s already working”. This is a serious risk for ruining a software team (and a codebase), but the people who feel the pain first are going to be the best practice engineers. Business stakeholders need to be very understanding of this – and accommodate for it.

The 20% technical debt rule comes in here. – giving the engineering team 20% of the development schedule to work on whatever they want, as long as it benefits the team or codebase. Usually they’ll prioritize this very well as technical debt causes engineers pain – self-prioritizing means they’re going to automatically start with whatever hurts the most. Be very sure that the engineers get their time, however you manage it – a day a week, or every fifth week are two easy strategies to start with.

Another way to manage this is to use ‘debt tickets’ – adding an unestimated ticket called “refactor Experiment X” when starting a new set of Lean experiments. If the experiment isn’t worth keeping, delete the refactor ticket. If it is worth keeping, the engineers should add an estimate, assign it to an engineer who worked on the experiment, and cycle it into the work schedule.