Cut old habits to maintain momentum and urgency

Healthy habits are critical for all successful product development teams. Much of the content you’ll read from product pundits (like yours truly) covers the variety of (sometimes contradictory) habits we think you should adopt. I think the importance of breaking (and avoiding new) bad habits is under appreciated. This effort is much more important than forming healthy habits because, without the bad getting in the way, you can make the rest up with common sense and a dedication to self-improvement. I believe that, while adopting good routines and practices is valuable, high-performing teams succeed because they successfully avoid settling into a rhythm, always making decisions with intentionality rather than delegating to autopilot.

First, let’s establish why habits can be positive: by adopting a routine, you are standardising how you deal with a problem. This can be a great way to break down something big or to simplify the decision-making required to get something done.

For example:

• Retailers adopt end-of-day/shift reporting routines in the short term to simplify their business reporting duties in the long term. By getting your finances in order at the end of each day, you are breaking down the mammoth end-of-month or end-of-year tasks that come later.
• Airlines centralise decision-making through the adoption of checklists for personnel. Without routines, each pilot and crew member across all fleets would have to devise their own way of working. With established practices, individuals don’t need to know the best way to get something done that has already been investigated and decided: they simply need to execute the steps they are given.
• Individuals exercise daily to remove the “when should I exercise?” decision from the health and fitness equation.

A recurring theme in the examples above is that when something becomes a habit, it becomes almost automatic. Completing tasks within a routine comes with much less cognitive load than completing a job outside of a routine. This is great when you just need to get something done without overthinking whether you should do it or how you should do it. Unfortunately, the most critical decisions faced by product and engineering leaders are whether you should do something and how you should do it. This is where turning everything into a business-as-usual, standardised, nothing-to-see-here routine starts to work against you.

In the world of building software, there are a lot of decisions that you never want to make while cruising on autopilot. This is where routines can become the enemy because teams make fewer decisions with intentionality by relying too much on established habits. In scrum, for example, teams tend to do great with sprint goals for the first few iterations. When planning their work for the next two weeks, they set a clear goal and only take on work that contributes to it. The problem is, after a few sprints and as the backlog grows, sprint planning becomes too ritualised, and many teams fall into the habit of making decisions about what to work on next based purely on what is at the top of their backlog that can fit into two weeks. Sprint goals are now drafted as summaries of what made it into the sprint, rather than the contents of the sprint being based on the predefined goal. What was a productive ritual (sprint planning) has turned into an unproductive one: this team is no longer goal orientated and is unlikely to achieve great outcomes.

Here’s the rub: every productive habit is at risk of eventually becoming unproductive. This is why teams should entirely avoid the autopilot problem through a radical dedication to intentional decision-making and an allergic resistance to unnecessary (or no longer necessary) processes. Retrospectives are the best preventative for bad habits, but not all retrospectives are created equal. To succeed, someone who is truly dedicated to having frank conversations about how things are going must facilitate them. Self-accountability is the best form of accountability for a team; anything the team can change or can have changed for them should be discussed. This is where teams should scrutinise their rituals and identify bad habits they are falling into.

Here are some more tips for avoiding the autopilot problem:

• Where possible, adopt dynamic rather than static rituals. For example, many teams break up their work into two-week sprints. This arbitrary cadence is precisely the type of thing that pushes teams to settle into autopilot eventually. Instead, define sprint goals first, and set the sprint length based on how long the team needs to achieve the goal.
  • During long sprints, teams lose their sense of urgency quickly. I recommend only ever running one-week or two-week long sprints.
  • Be biased towards shorter sprints. If a goal will take two weeks to achieve, try two one-week sprints. If a goal will take three weeks, start with a one-week sprint, followed by a two-week sprint. This allows you to revisit the plan just a week after getting started.
• Set time-based goals beyond individual sprints. While sprint goals are naturally time-boxed due to the set length of a sprint, many teams do not set deadlines for initiatives that will take longer than a single sprint. I think that this is essential for the intentional decision-making that we want. So, when picking up an initiative, teams should set their own deadline for when they want to have it completed.
  • To explain this further, one critical component of good product decision-making is finding alignment between the value in solving a problem and the effort required for the chosen solution (i.e., return on investment). As a team, you want to make sure that the effort you’re investing into solutions is proportionate to the size of the respective problems, otherwise you won’t get return on invested effort. One way for teams to manage this is by setting deadlines. Ask yourself: “How much time are we willing to invest in solving this problem? How much would we be delighted with? How much would be acceptable? How much would be unacceptable?” Stick to these deadlines — sometimes it is best to move onto something new if your current solution is taking much more effort to implement than you originally expected.
  • When I talk about deadlines, I’m talking about deadlines that are internal to and owned by the team, not imposed on them externally. These are a tool for self-accountability.
• Avoid abstractions when assessing progress. Many teams work in one tool (e.g., JIRA) but communicate through something entirely differently (e.g., PowerPoint, Confluence). While this is OK when trying to distill your message for others, decision-makers should try to be as connected to the work as possible. During team rituals, look at the board or task list directly. Pay attention to where progress is being made, and where it is not.