Keep on pedaling

Cadence is a term used to describe the rate at which a cyclist is pedaling. Different cyclists find their efficiency in pedaling at different rates. Looking at the professionals you can see that Chris Froome has an unusually high cadence whilst Nairo Quintana tends to cycle at a much lower cadence. They’re both effective riders despite this difference.

As each cyclist has a preference for the cadence that suits them most. When the gradient of the terrain on which they are cycling changes, they switch gears up or down so that they can maintain it. Getting the gearing wrong can be catastrophic as it causes lost ground and wasted energy.

If the gear is too low, then the cyclist pedals too fast – what is known as spinning – and a lot of energy is consumed for a negligible amount of overall movement. If the gear is too high then the cyclist can find themselves having to push extremely hard to move the pedals – known as mashing – and again, energy is wasted. When you mash going uphill it’s very hard to change gears because you can’t turn the pedals fast enough.

Cadence in software delivery

Similar to the way that cyclists need to discover which cadence is right for them, you as a leader need to define what your cadence of delivery should be for your team, division or department. What sort of projects are you expected to ship and at what frequency? What defines a good quarter or a bad quarter? A good year or bad year?

The right cadence for your department will depend on a multitude of factors, such as the industry that you’re in, the speed of the competition, the way that your software is delivered (e.g. SaaS versus on-premise), and the number of staff that you have. You may also find that the executives at the company have a predefined expectation of how many big launches are expected per year, for example, and how fast other features should iterate.

If you’re new to the company, it’s good to solicit opinions on what is expected. Is it one headline-maker per month, quarter, or year? Are your users expecting increments every week, month, or quarter? How do you plan with longer-term, risky, innovative initiatives that might fail?

Others expect steady cadence

Regardless of what the expectation is for the cadence of delivery coming from your department, I’ve found that there is one very important thing: those outside the department are very sensitive to your cadence changing. Life is more comfortable for everybody when there is a predictable flow of completed projects, rather than a packed quarter followed by a quiet one, followed by an average one.

Now, people aren’t silly: they understand that some features are small when compared to building a whole new product or revamping the entire back end infrastructure. However, having a steady and predictable cadence is important.

• Marketing are allowed the time to plan and execute their webinars, advertisements and events. If your output is spaced predictably, they too can predictably plan their time. Too many launches in close vicinity isn’t desirable for market impact: it lessens the individual impression of each launch. A steady cadence makes their pipeline easier to manage and the results of their activities more measurable.
• Sales rely on the your cadence for their ammunition. Walking into a pitch knowing that the Engineering department is shipping predictably and often is a huge confidence boost. When working on important RFPs, knowing that Engineering will be popping out a steady stream of features during the process can be the deal breaker when you are compared to the competition.
• Engineering themselves love a predictable cadence. Your teams know that there will be plenty of times to launch and celebrate throughout the year and to get their teeth stuck into different parts of the system.

You’ll need to ensure that your selection of ongoing and upcoming projects maintains a steady cadence. That means having smaller projects delivering while long-burners tick away, iterations of existing functionality while technical debt is fixed, and that your headline launches are timed well for the benefit of the company.

Maintaining cadence

Categorizing your projects

If you have an idea of what is expected for the cadence of your department, then the next step is to work out what an ideal flow of projects would look like at any given time. These categories of project can be balanced in such a way that you are always shipping something at regular intervals, regardless of whether it is big or small.

Have a look at the categories below. Next to each is an indicator of visibility and size.

• Big ticket products and features: These are big, shiny additions to your overall offering. They could be a whole new product or an advanced differentiating feature. These can involve new and uncertain work, and will have a very visible impact if the deadline is missed (e.g. they are to be unveiled at an event, or there is an in-depth marketing announcement planned). These are of high visibility and of large size.
• Iterations on existing functionality: These are incremental improvements to what you already have. This could include new visualizations of existing data, a slicker UX workflow for a part of the application, or a revamp of the login screen. Medium visibility, medium size.
• Bug fixes and small improvements: Fixing bugs that customers have reported and tweaking what you already have. For example, fixing the format of some data being returned in an API call, making the delete button not occasionally throw an error, fixing a situation where a pop-up can get stuck. Low visibility, small size.
• Architectural work: Migrating or redesigning storage, horizontally scaling a previously monolithic process, rewriting an API. These are the long-running initiatives that ensure your future health, but may deliver nothing more than feature parity. Minimal visibility, large size.

Getting the balance right

The exact composition of your teams and the number of important projects will change over time. However, as a leader in Engineering you will need to make sure that the balance is right. There are dangerous situations that you will want to make sure that you don’t get into.

1. Neglecting work streams, where overall focus is continually biased on some areas resulting in other important streams of work becoming neglected.
2. Not tackling technical debt proactively, which causes big problems down the line that are often much harder to explain to other parts of the company.
3. Going long and thin, wherein a lack of bold decision making – typically being unable to say no – means that you have too many concurrent projects, resulting in them being understaffed and slow.

Let’s look at these in turn.

Neglecting work streams

This is a very easy trap to fall into. Running a SaaS software company requires continual improvement of your application estate. The industry and competition moves fast and, most importantly, your users are used to incremental improvements in other software they use.

Ensure that all areas of your application are revisited for refinement with time. Even better, have enough teams so that all areas have a clear owner, and that they work to KPIs that encourage continual improvement. Ignoring them leads to rot in the form of technical debt.

Technical debt

This must continually be tackled, in all forms: upgrading old infrastructure, redesigning and rearchitecting for scale, and ensuring that code is continually refactored as new code is added. Empower your engineers to be confident enough to estimate tasks so that they can always pragmatically follow the Boy Scout rule.

Also empower your engineers to tell you which parts of the application estate are due an overhaul and why. Make plans to do so while you ship other things. Not only will this work make your application more scalable and prevent future crises, but your staff will be motivated to make a difference if they are the ones suggesting it!

Always, if possible, have technical debt being tackled in some capacity all of the time. Your future depends on it: increasing amounts of technical debt will make new projects even harder to build.

This makes it akin to mashing in our cadence metaphor: the pedals get harder to turn as the hill gets steeper, and it becomes even harder to change gear.

Going long and thin

It’s also very easy to go long and thin. As a leader you will need to practice saying no to incoming demands so that you can keep your projects moving at an acceptable pace. Whilst it can be easy in the short-term to say yes to that extra favour from a client or the CEO, it further dilutes the amount of staff that you have to work on each work stream.

Although this creates the illusion that you are being more effective and working on even more projects, the reality is that you’re just getting them all done much more slowly, becoming more exposed to people being ill or going on holiday, and setting yourself up to apologize for being late down the line.

Too many concurrent projects is akin to spinning in our cadence metaphor: lots of work for not much reward.

A good mix

So consider what a good mix is for you. This will shift depending on the life stage of your company, but regardless, the advice is actually quite simple. At any given time, balance teams producing low visibility work with others producing high visibility work. For teams tackling very large projects, ensure that they are covered by other teams shipping small projects.

When you hit it right, it will feel like your projects are flying out the door all year round. That critical year-long rewrite of your backend is protected by tens of smaller features rolling out. When you hit it wrong, you may appear to ship nothing despite putting a lot of effort in, or you may produce a lot of low impact work whilst ignoring the bigger issues at hand.

In summary

We’ve looked at the idea of cadence of delivery, and how it is important it is to not only ship, but to ship predictably often. You need to balance ongoing priorities and projects, continually tackle technical debt and also be confident in saying no if it makes you oversubscribed.

Where do you stand with your current cadence? Do you feel that you are staying steady, regular and efficient, or are you spinning or mashing? If so, why do you think that is? Was it pressure from others, or was it just down to good or bad planning?