500 Words — Day Twenty-Seven: Managing Scope
One of things that I’ve learned while attempting to ‘manage’ a software team for the past three or so years is that I’m pretty bad at down-scoping work. While I think we do a pretty good job at attempting to define the boundaries of scope when talking through the tasks with the team during our Sprint Planning meetings, decisions made in that meeting are very limited in the amount of information and context awareness. There’s two weeks for the team to find problems, issues, or considerations that weren’t taken into account when initially formalizing those tasks. Often this introduces the silent killer of software engineering productivity: ambiguity.
Ambiguity is hard. It is hard because it forces you into making a decision based on the interpretation of the developer against their internal notion of the needs of the software. And many times that interpretation can differ between different developers and between the developers and the project managers and other engineers. Since communication channels are never perfect between these respective parties, it is often the case that a developer will struggle by themselves before eventually raising the question up the chain. That typically leaves me needing to make a decision given the context that I have. And that context is often different from the developer asking the question. Because I do a lot of work at that higher level, sometimes I tailor my responses to that level. The problem with that is that it often over generalizes a solution or doesn’t take other design elements into consideration and either overcomplicates or overdesigns a solution.
I find the best way to deal with these issues is to talk over things with the developer, ask questions about the work they are doing, trust the information they are providing, and encourage them to follow their intuitions. I don’t do the best job at the second part of that, but it is important to realize that often you are missing context and they might be leaving out key details when they are describing the problem to you. Also, a lot of the time, they have spent more time on the problem than you have. The only thing you want to change their direction on is the tendency to increase scope in the face of ambiguity. This requires redefining the problem or reducing the amount of tasks that need to be performed for a task to be considered complete. You can delegate responsibility and trust your team as much as you want, but you need to be careful to avoid overcorrecting into undermanaging.
The overall goal of a manager should be to make the life of their team easier. This includes making hard problems easier to digest. Giving them space to grow into being capable of making decisions themselves. Being willing to give advice when they need it. Reducing the scope of a problem so it is more manageable and achievable within the timeline you are working on. Software is fortunately (and unfortunately) a domain where lots of choices have to be made. As a manager, it is up to you do perform the fine balance of picking which choices you trust your team to figure out and which choices you either want to remove your team from making or deferring them to a later time when more information and bandwidth is available so a better decision can be made.
