Chapter 5. Busy Isn’t Better
As managers, we are asked to spend a lot of our time making sure that our people stay busy. Busy producing new features, busy fixing bugs, busy addressing technical debt, busy figuring out what will keep us busy next. We track our team’s capacity in spreadsheets down to the hour, trying to account for how much of each day is spent in meetings or forecast who will become available next. There’s pressure on us to make sure that no one is idle. Ever.
Some of this pressure comes from appearance. We don’t want it to seem like our team isn’t pulling its weight or contributing its fair share. Some of this pressure also comes from the need to plan and estimate. We are always looking to account for each hour of the day so that we can accurately predict our team’s output. Unfortunately, the closer we get to maxing out our capacity, the worse our output gets.
Development requires research time. I’m willing to guess that every engineer on your team cannot crank out code all day without having to look up examples or investigate their approach. This isn’t a bad thing! You want to make sure that they have time to explore best practices, understand new libraries, and dig in to new technologies. Without this time, your team will be making guesses and introducing defects.
Development requires the ability to respond to unplanned work. As much as ...