Ask the CTO: Completing projects is difficult with a changing business roadmap
Anticipate change, but keep an eye on technical debt.
Forks of the Credit Turn Pike. (source: Michael Gil on Flickr)
The problem: It’s hard to direct a team when our goals as a company keep changing
I’m a manager at a growth-stage startup, and every year the same thing happens: the executives go off at the end of the year and do big planning. They roll out the planning, we all get on focused teams, and start working on that plan. Then, around July or August, something big changes and some of the teams are moved around to deal with that change, whether it is a new product initiative or a business scaling issue. The problem is, I feel like I can’t give my team any certainty at all, and we never get to implement half of the things we say we will do at the beginning of the year. My team has all of these ideas for technical improvements that we rarely manage to accomplish, and I just feel like we never get into any flow before things change again. How do I deal with this?
The solution: Accept the challenge and be flexible
Change is inevitable, especially in a startup. In fact, change is probably what drew us to working for a startup in the first place! We want to be able to move fast, and switch direction as needed. So, why do we fight against the changes when they actually happen?
Learn faster. Dig deeper. See farther.
The challenge of changing product and business roadmaps is a very common problem that managers at all levels face. Especially in smaller companies, it is hard to keep commitments made a month in advance for work to be done, let alone plans that last a year or more. Things just change too fast. Even at big companies, changes in the market can lead to sudden-seeming shifts in strategy that cause projects to be abandoned and planned work to be cancelled. If you’ve ever been at a big company during an economic downturn, you’ve probably experienced the surprise of massive shifts in focus that can come, even to a company that rarely seems to change.
This is really hard for engineering managers to deal with. When you hear the phrase “middle management,” changes in strategy are where being stuck in the middle feels the most unpleasant. You may have very little ability to push back on the changes to strategy coming from above, and even when you have promised your team that certain projects will happen, you sometimes have to pull back on that promise because of unexpected changes. This, in turn, makes the team unhappy and they complain to you. Because you have no ability to do much of anything about it, you can feel like it exposes you as powerless, and your team might feel that they are being treated not like humans but rather as cogs in the corporate machine.
Coming into play here is a secondary challenge: how do you manage to make the time for your team to deal with “technical debt” and other engineering-focused projects when there does not seem to be a clear process for prioritizing that work? After all, if you don’t put any time into dealing with the technical issues themselves, your team will start to slow down their ability to do product features. And yet, the product team will never have “technical debt” on their roadmap, so the planning process often means there is no time given for this type of work.
Practical advice: Shift work to respond to company’s goals and create a plan to reduce technical debt
How do you handle this kind of change and uncertainty?
Be realistic about the likelihood of changing plans given the size and stage of the company you work for. Since you are in a startup that has a history of changing the year’s plans every summer to account for the business results from the first half of the year, be prepared for a change in the summer, and try not to promise things to your team that would require continuity beyond that point.
Think about how to break down big projects into a series of smaller deliverables so that you can achieve some of the results, even if you don’t necessarily complete the grand vision. Breaking down the technical work will require you to work closely with the product or business managers to figure out how the details should be prioritized. All of you should be aware by now that things will change quickly, so everything must be repeatedly re-examined with an eye toward what is most valuable right now.
Don’t over-promise a future of technical projects. Don’t promise your team exciting technical projects “later” because the product roadmap for later hasn’t been written yet. This kind of thinking will get hopes up and then disappoint. If the project is important, get it scheduled now. Or as close to now as possible. If the project is not urgently important, you can put it on the backlog, but you should be realistic that once “later” rolls around, there will be a long list of competing priorities from other parts of the business. If you haven’t taken the time to articulate the value of this work, it will get pushed aside in favor of projects that are more clearly valuable.
Dedicate 20% of your team’s schedule to “sustaining engineering.” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, minor cleanup, and ongoing support. This should be taken into account in every planning session. Unfortunately, 20% is not enough to do big projects, so additional planning will be needed to get major technical rewrites or other big technical improvements. But without that 20% time, there will be unpleasant consequences with missed delivery goals and unplanned and unpleasant cleanup work.
Understand how important various engineering projects really are. Product and business projects usually have some kind of value proposition to justify the project. However, the same rigor isn’t always applied when it comes to technical projects. When an engineer comes to you with an engineering project that she wants to do, think about framing the project by answering these questions:
- How big is that project?
- How important is it?
- Can you articulate the value of that project to anyone who asks?
- What would successful completion of the project mean for the team?
The value of these questions is that you start to treat big technical projects the same way as product initiatives. These projects have advocates and goals, they have schedules, and they are managed like other big initiatives. This is a scary process because there are times when you “know” something is important, but you don’t know how to articulate it in a way that the business will value. Especially given the complex nature of technical projects and the challenge with measuring things like engineering efficiency, you’re sometimes stuck trying to explain technical details to a non-technical partner who may not totally understand where you’re going or why. My advice is to do your best to gather data to support yourself, and talk about what will be possible when the work is done. If you look at a technical project and realize that you’re proposing a bunch of work for a system that is rarely changed and is not going to enable core improvements to your technology or business, it is probably not worth the effort. Unfortunately, there is never enough time for all the exploratory engineering, legacy code cleanup, and technical quality improvements your team will want to do, and this process will help you pick your battles.
So, back to our uncertain roadmap. Projects change. Teams may even be disbanded, or moved around, in ways that you don’t understand or agree with. As a manager, the best thing you can do is help people feel capable of tying up loose ends, stabilizing the current in-flight projects, and easing into their new work in a controlled fashion. This is where you can and should push back. Make sure that your teams get adequate time to finish up current work. Furthermore, push for engineering involvement in the early planning for the new work so that people can get excited about the projects they are moving onto. Take the time yourself to understand the reasons for the move, and even if you don’t totally agree, do your part to help make those reasons clear to your team and help them understand the new goals. The calmer you can be in the face of these changes, and the better you can show (or fake) enthusiasm for the new direction, the easier the transition will be for your whole team.
When you are faced with waves, you can let them pull you under, or you can learn how to surf. Hang 10.