One of the most frustrating questions that engineering managers get asked regularly is why something is taking so long. We’ve all been asked this question before. We’ve been asked it as hands-on engineers, as tech leads, and as managers of small teams, but the question takes on a whole new level of intensity when you’re managing team managers, because answering it is significantly harder when you aren’t embedded deeply in the details.
First things first: hopefully you’re being asked this question because something is running over plan by a significant margin. That is the time when it makes the most sense to ask, and when you should do your best to understand the scenario and answer.
Sadly, we are often asked this question in times when things are not taking any longer than the estimate. We are often asked this question when our leadership, for whatever reason, either didn’t like the original estimate or didn’t ask for it at all, and now they’re upset, despite nothing going wrong.
Therefore, you must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask, especially if you believe that the project is critical or likely to take longer than a few weeks. This means you must be aggressive about getting estimates, and as we all know, software estimation is a very difficult process. Negotiating the process that your team uses to estimate, on what timescale, for what projects, may be part of your job at this level.
Engineers often don’t want to estimate at all, or estimate beyond the boundary of an agile sprint (generally two weeks). This philosophy is completely reasonable if you believe that estimates must be fairly accurate, that the requirements are unknown or will change frequently, and that most of the work should be bound to features that mostly fit within one or two sprint efforts. With that said, few of these things are always true. Estimates are often useful even if they aren’t perfectly accurate because they help escalate complexity to the rest of the team. Not every project necessarily has requirements that change frequently, and it’s possible to do up-front work to drastically reduce the unknowns that make software estimation difficult. You may argue that the up-front work sometimes makes the overall process take longer than simply looking at the project sprint by sprint, and you may be right, but again, we’re not just talking about engineering teams here. We’re talking about businesses that want to plan and get ideas of costs for effort. We’re also, in some sense, talking about goal setting and learning how to get better at understanding the complexity of our software and systems. We can’t predict the future perfectly, but teaching our teams how to hone their instincts about complexity and opportunity is a worthy goal.
So, accept the fact that you’ll need to do some degree of estimation. Play with different methods, and see what works for your company, but make it a habit across your teams.
Another core element of agile software development is the emphasis on learning from the past. When estimates are wrong, what are we learning about unknown complexity? What are we learning about what is worth estimating, when? What are we learning about how we communicated those estimates and who was disappointed by the miss?
It is your job to make it clear, as best you can, what “long” actually is by providing your best view into the timescale of a project, and proactively updating that view when it changes, especially if it gets much slower.
Even with your best efforts, sometimes you’ll be asked this question when you’ve been clear about what “long” is, when you’re not actually taking so long, or when things completely outside of your control have come up and caused delays that were well communicated. It sucks when this happens, and it usually happens because someone is feeling stressed or being pushed to deliver faster than you ever claimed to be able to deliver. There’s no easy answer to this situation. Sometimes patiently reminding the other person that things are going as fast as they can and everything is on schedule is the only solution. But blame is not usually a fully rational exercise, or one that can be totally avoided under stress. Showing some empathy for the person providing pressure and being willing to help out in other ways can go a long way to shifting focus from blame to action.
Finally, don’t be afraid to work with your managers, tech leads, and the business to cut scope toward the ends of projects in order to make important deadlines. As the senior manager, you may need to play tiebreaker and make decisions about which features are worth cutting, and which features are essential to the project’s success. Help the team look out for these features, and be willing to take the fall for cutting back on someone’s favorite idea if it’s essential to getting the larger project done. Be smart about what you’re willing to give on. If you give only on matters of technical quality, you’ll just slow down the team after the project is launched, so be sure to look at product features in addition to technical nice-to-haves.