A challenge for all leaders of growing R&D organizations is maintaining a certain momentum throughout the ranks. Not to disregard the benefit of tools for measuring velocity, I have a hard time with its innate subjectivity. With time, teams face a stale velocity. I’ve discussed why we want to revisit our velocity in the past, but now I want to tackle the problems this brings to VPs in shaping their organization’s culture.
The first issue is with defining this sense of urgency in general. Why is it needed? Isn’t it a bad thing? Plain urgency might be interpreted as stressing the team and trying to get into blitz mode. Obviously, that’s not a healthy way of achieving success. Blitzing often shows short-term improvements at the cost of a big slowdown in the longer term. For me, urgency is about not allowing ourselves to get too comfortable or lackadaisical.
A manager with this mindset is not constantly harassing the team about statuses, delays, and changes. This is not about being that annoying manager that automatically cuts all effort estimates in half. Rather, it is about not allowing complacency to take hold. It is about always trying to keep a beginner’s mind when assessing processes and efforts so that we can refresh them as necessary.
When I’m working with teams to take steps to improve this, there are a few habits that can make a big difference.
Questioning plans: This is a very straightforward practice that is often easier for teams to start with. Don’t accept feature plans and specifications as-is, but encourage your team to ask questions, suggest ways of making things less complicated, and come up with shortcuts together. It might require some alignment with the Product team to prevent frustration (“We’re always getting pushback about everything”). Teach your teams to work alongside their product counterparts to achieve optimal plans together.
Yak-spotting: We all have cases where we start working on something with the assumption that it is going to be easier than it turns out to be. As the team uncovers more and more areas that require yak-shaving, it is essential to be able to spot this and reconsider the direction forward. Merely because we thought something was worth it initially doesn’t mean that it is still the right thing to do once we realize there were unknown unknowns. Effectively discussing the way forward with product and making changes on the fly can save teams weeks and months of effort every year.
Avoiding over-engineering: Engineers are gonna engineer, but we should make a conscious effort not to allow them to go for too grand of a design prematurely. Encourage the team to normalize criticism for suggested solutions in design reviews and planning. When we can put ego aside and openly talk to each other about plans, things go better, and we can put urgency into action.
Retrospecting: To refresh our stale velocity, try to make the team regularly reassess the way things have gone and whether they could have been done faster, cheaper, or easier. This spans across basic engineering improvements as well as talking to Product in meta-reviews to make future features more on-point.
Can-do attitude: As mentioned above, you shouldn’t be slicing estimates willy nilly. The movies scene where the team says they need two weeks and you reply, “you’ve got one,” is not proper leadership. However, if you ask the team to imagine that it is possible to do something within X days, it can help them think about what it would take to make that an actual reality. This is part of your Executive Mindset and has proven itself again and again in my experience.
Building for value: Lastly, it can also help teams to maintain urgency when we flip standard work practices on their head. Instead of getting a feature request, stating that it would take X weeks, and breaking those into iterations, do things the other way around. As suggested in Shape Up, I recommend having stakeholders state how much a feature is “worth” in development effort and then letting the team say what is possible within that budget. That’s a great way to prevent your velocity from degrading.
© Aviv Ben-Yosef 2021 — Originally published on the best newsletter for tech executives