Throughout my time at Hotjar, I led several teams – both directly (with me as their team lead) and indirectly (with their team lead reporting to me).
Teams were always allowed to operate in a way that was comfortable to them. Some teams used Kanban, some others used scrum. Some teams did weekly planning, some teams did bi-monthly planning.
Over the years, I tried to analyze our teams and identify patterns unique to our most high-performing ones. Unsurprisingly, the specific framework they used to keep themselves organized very rarely correlated with performance. Instead, what consistently made a difference was the pace at which they were able to ship changes – i.e. momentum.
Perhaps more interestingly, in high-performing teams, the amount of "failed" releases (i.e. product changes which did not have the desired effect) was usually no lower than that of a low-performing team. However, because the high-performing teams shipped much more often and were able to iterate more quickly, they ultimately produced much more value throughout their lifespan.
So why is momentum important?
First off, it may sound trivial but it's important to understand why any product team exists in the first place.
A product team exists to help your business grow, either through direct value creation (like a feature team) or by providing support to others (like an SRE team).
‌‌
That context is important to keep in mind – unless you happen to be a non-profit entity, if your product teams are not directly or indirectly helping the business grow, then those teams should NOT exist.
With that out of the way, let's focus again on momentum.‌‌‌‌
Since we know that not all work produced ultimately leads to business value being created (for example, you may introduce features that gain no traction), a key objective for any product squad is to increase team momentum – i.e. the pace at which work is delivered. The faster we can deliver work, the higher the chances of the team producing output that has the desired outcome.
Over the years, I realized that there were around 6 main factors that affected a team's ability to ship fast and often:
- Rapid, but thoughtful, decision-making. Bad decisions are usually better than no decisions at all.
- Commit to less, achieve more. Always prioritize shipping existing work vs. starting something new.
- Prioritize initiatives that boost momentum. Solving technical debt is sometimes the best thing you can do.
- Operate like a small startup. As you work on improving momentum, always challenge yourself to improve.
- Create opportunities for your team members to become more comfortable with each other.
- Think solutions, not problems. Encourage team members to give constructive feedback to each other.
1. Rapid, but thoughtful, decision-making. Bad decisions are usually better than no decisions at all.
A product team needs to take both small decisions (eg: should I use a new function here?) and big decisions (what should we say no to right now?) multiple times a day. Needless to say, the speed at which decisions are taken can have a huge impact on a team's pace.
Whilst at Hotjar, I had discovered the concept of two-way and one-way door decisions (by Jeff Bezos). It really resonated with what we were going through and I quickly adopted it with all my teams.
All two-way door decisions – decisions that can very easily be reversed – should be done quickly, with a clear understanding that they may be rolled back if the decision was wrong. These types of decisions should never happen by committee.
All one-way door decisions – decisions which are hard to reverse – should be taken carefully and planned properly, with the input of relevant stakeholders (eg: your Director of Product & Engineering).
Before taking any decision, your very first decision is to determine whether it's a two-way door one or a one-way door one. You will likely find that most decisions fall into the former category and can be taken quickly.
If you are a team lead or you manage multiple teams, your goal is to train your team to be able to distinguish between the two and empower them to quickly take two-way door decisions without needing your input.   ‌
2. Commit to less, achieve more. Always prioritize shipping existing work vs. starting something new.
High momentum is achieved by doing frequent deployments, not having multiple backlog items in progress. Because every backlog item requires a code review by another engineer, having fewer concurrent streams of work is usually a more efficient way of working.
The best teams always split stories into the smallest, logical chunks of work that can be deployed independently, and potentially by different engineers. If an engineer needs to work for two weeks before being able to deploy their work, then it was probably not planned well enough – although exceptions do exist of course.
If somebody in a team finishes a backlog item, their priority should be to help others get their own backlog item to the finishing line (either through work or a code review), rather than starting something new.
There is one caveat: assigning more engineers to a single backlog item does not always get it done faster. Sometimes it’s perfectly acceptable to have just one engineer work on a backlog item. Even then, they should split it into small deployable sub-tasks.
3. Prioritize initiatives that boost momentum. Solving technical debt is sometimes the best thing you can do.
Keeping up momentum sometimes goes beyond taking quick decisions and working effectively on a story. It’s critical that team members also understand and keep track of the main technical issues that hinder momentum (lack of proper testing, technical debt, too many incidents).
Anyone leading a team should advocate for prioritizing technical improvements which give the team some sort of momentum boost in the near future (eg: working on this for a week now will make us twice as fast later on).
Technical debt can be a very contentious topic, but it's important to frame it in the right way: most technical debt will hinder team momentum in some way. The tech leaders in the company need to make sure that technical debt is never presented as an engineering-only issue that only engineers want to solve. You do this by getting both product and engineering teams to understand and align on the real benefit the company gets from solving it.
If you're a team lead, you should discuss the ROI of each potential technical improvement with your team at regular intervals. Doing this won't necessarily mean that all technical issues will be solved, but it will make it much easier to justify why some of them are being tackled and some aren't.
4. Operate like a small startup. As you work on improving momentum, always challenge yourself to improve.
Although a product squad forms part of a larger engineering department and needs to work within specific boundaries set by the company (like OKRs), the way they operate on a daily basis (such as the agile rituals and the weekly calls) is usually controlled by the team.
If you're a team lead or you lead a group of teams, you should run them just like a small startup could – void of bureaucracy and with a bias to action and sense of urgency. This means not accepting the status quo and constantly trying to become a better version of themselves.
Remember that nothing is stopping you from completely changing the way you plan work, the way you take calls, or the way you communicate with each other (unless the company has strict policies around any of those areas). Be bold and move fast. Don’t put too much thought into making a process perfect if it’s something you’re trying for the first time.‌
In practice, this means that you should do regular team retrospectives that actually lead to change. Even better, you can make process improvements a part of your team culture by embedding them into the way you work – for example, by introducing a "Team experiment of the month". This is effective because changes are presented as tests which could be easily reverted vs. permanent changes.
If you're a team lead, it's important to continually assess the momentum your team has and adjust the amount of experiments and change accordingly. If your team is going through a very good period, it's probably wiser to maintain stability and keep things as is for a while.
5. Create opportunities for your team members to become more comfortable with each other.
A happy team is a high-performing team. A team is a happy team when its team members look forward to coming to work on a Monday morning because they enjoy working with their co-workers.
This almost always translates to higher momentum. Why? Because team members who like each other typically align quicker on how to tackle any given problem and are usually more happy to disagree and commit when they're working with co-workers they trust. They're also happier to voice concerns and can have more productive discussions.
As you can imagine, building that level of condidence takes time and work.
First off, any team lead needs to take the time to understand what makes each team member unique, and more importantly, what they can bring to the team. This will allow them to not only assign the right type of backlog items to them, but also to make sure they are collaborating effectively with the right people in the team.
Secondly, don’t underestimate the importance of having the right bond between team members. Think about how you can celebrate wins as a team, and how you can become more comfortable with each other.
Doing regular social calls might sound like a waste of time, but it isn't when done in moderation. A team that gels well and gets along can definitely help a team execute better.
6. Think solutions, not problems. Encourage team members to give constructive feedback to each other.
For a product team that works in a fast-paced, agile environment, it’s important that team members become very comfortable with being wrong and being told so.
Anyone leading a team needs to train their team members to give constructive feedback to each other as part of their daily conversations. Feedback is constructive when you don’t only point out what you don’t like, but also suggest an improvement or a remedy to the problem.
To have a healthy team environment, team members should always be encouraged to present solutions to problems, rather than just raising issues and expecting others to solve them. This is especially true in team retrospectives. Team discussions can quickly become highly unproductive and even toxic if discussions center around problems and “complaints”.
Teams that think more about problems (vs solutions) tend to get lost in never-ending discussions which have a very negative impact on momentum. A team lead's role is to quickly intervene and keep conversations productive and on point.
Remember: The great thing about momentum is that maintaining it is much easier than building it in the first place. Most high-performing teams will continue performing at a high level even when new team members join and when the areas they are responsible for change.
Having said that, momentum does not happen overnight. It’s built over time and requires patience and perseverance. A team has momentum when they quickly agree on how to execute and then execute flawlessly due to the great synergy between them.