Your Magic Spell

Your magic words as a technical manager are, “that’s out of scope”. You need to wield this spell intelligently but ruthlessly. Your team needs you to do it so you can keep their workload manageable and allow them to stay focused. Your manager needs you to do it so that they know why you can succeed.

Now, you don't want to be in the situation where you say that to a product owner right before a release. If that happens, something went wrong. Most likely, it would have to do with one or more assumptions on your part - and the product owners part - that didn't come up early enough to be resolved.

Some companies try to address this with really detailed product specifications. That can work, but it's no guarantee that missed requirements based on assumptions won't come up. I've found that a better way to prevent assumptions that lead to scope creep is close communication, fast iterations and short demos.

To me, those are some of the best aspects of Agile development. Product owners don't always know every requirement before development begins; the same way that developers don't always know how they'll solve requirements until they are into the code. Seeing running code is one of the best ways of coming to a mutual understanding of what all the problems are that a product owner is trying to solve so that your developers really understand what the goals are. It also allows for trade-offs that can help speed development. For example, it's not uncommon for developers to offer some options for difficult or time-consuming requirements that, once adopted, can speed development and still satisfy customer expectations.

I'm not a fan of blaming missed requirements on "bad communication". Go deeper with your stakeholders; take the time to try to find assumptions; talk through outcomes; ask the questions you may not want to know the answers to. By doing these things, you'll prevent yourself from getting into trouble with unexpected scope creep.

Planning is Your Job

As a technical manager, one of the most important things you can do for your team, yourself and your organization is planning. If you're like me, you're good at managing a crisis bug - and you may even enjoy it. Engaging a whole team to focus on one, critical problem; communicating with stakeholders; severely limiting scope. All of these things come into play when you're managing an emergency with your team. Planning is a lot harder and just as, if not more important.

It's harder because it requires you to think way ahead - not just the next sprint or two but 2,3, 4 or even more quarters. Managing tasks one or two sprints into the future is easy compared with looking 6 months or a year into the future. What's important now may not be quite as important in a year. Answering the question, "what are our goals for the next year and how will we get there?" is complicated. You'll have lots of technical things you want to accomplish but making sure you know what the product needs requires working with more than just your technical peers. You need to understand your product strategy, talk with the people in the organization that are in touch with customers and can really help set priorities.

You communicate with stakeholders differently, too. During a crisis, it's "all hands on deck" and you can make decisions quickly and decisively. Planning, though, is all about working with product managers, program managers and the like negotiating priorities and analyzing capacity in an environment where you likely won't have all the details. You're not going to know all the requirements and risks but you'll still need to be able to decide what you can fit in and when.

Having the long term view is critical if you have to coordinate with other teams. They're going to take your plan, look for dependencies and then plan accordingly. You'll need to do this with their plans, too.

My planning skills have gotten better over time, but they could always use improvement so I'm always learning how to plan better. I've been lucky to work with people that are really good at it; or if they're not planners themselves, they know how to challenge me and ask questions to help me refine my plans.

Planning is a critical skill for a technical manager. It takes a lot of practice but the payoff can be huge.