Planning R&D Time

Granted that reality will disrupt the plan, I still find it useful to do a quarterly planning exercise. I’m fond of doing this with a zero based budget of person-time that has already had maintenance requirements removed. So you’ve got N full-time equivalent (FTE) people. They’re going to be sick and vacating and training 25% of the quarter, and they’re going to spend 40% of the remainder in meetings. If you have 10 people (keeping math simple), that’s 1920 hours of development in a quarter. Divide that in half to get the budget for feature work: 710 hours for maintenance, 710 for roadmap feature cards. Now, scope and prioritize the features you will try to deliver in this quarter. Scope doesn’t have to be perfect, an engineering manager’s estimate is plenty at this stage.

This exercise can be done in all sorts of ways, the tools and structure don’t matter. I’ve participated as everything from company leader to middle manager to product manager to subject matter expert. Maybe it’s a bunch of people in a room with post its and masking tape on a wall. Maybe it’s a series of screen share calls or physical meetings with a spreadsheet or a project tracking tool. Maybe meetings are with the whole leadership team, or subsets, or mixed. I have some dislike for a spreadsheet approach: specific project management tools or post it’s on a wall make it harder to accidentally over-allocate resources. Nothing can stop a team determined to tell themselves fibs about capacity though.

Here is the hard part: you have to leave the maintenance work untracked at the roadmap level. It’s whatever engineers feel is necessary. That budget isn’t open to negotiation or justification, it is a requirement of selling software that needs to be maintained. When a leadership team breaks this rule, then the maintenance work is no longer protected from the budgeting process. That invariably leads to it getting deferred, because hope of making money from a new feature is more pleasant than fear of losing money from decreasing quality. That deferred maintenance eventually comes back to haunt the organization, producing the highly prioritized “product get-well initiative” or even justification for a pivot.

My advice to give engineers freedom to maintain is not absolute, to be clear: maintenance occurs within a budget of time. Want to refactor everything or start over in a new language? You should have to convince the entire organization to sign off on that. But you shouldn’t have to fight the budget wars in order to fix bugs in product you already sold.

%d bloggers like this: