Cadence & Flow
Developer physics behind real productivity
It’s no secret that developers love physics analogies as to how they pertain to productivity. Speed, output, velocity, momentum, inertia, accelerate, headway, traction, drive, inflection, sustainability; and my favorite, cadence and flow.
In the perennial pursuit to understand and implement productivity strategies among engineering teams, and in experimenting in every analogy to improve efficiency — I regularly come back to cadence and flow. No amount of “it’s not a sprint it’s a marathon” or “work smarter not harder” proverbial wisdom tend to stick on our minds as devs are as we are continually engulfed in meaningless productivity biblical banter.
As a leader, there’s no doubt I’m looking at stats like reliability, cycle times, value add frequency, time to recover, and failure rates. Likewise it’s good to pay attention to retrospectives, understanding blockers, interpersonal relationships between team members and their general well being and satisfaction with one another and objectives.
Naturally when data is not moving in the direction as well as one could have hoped, it seems natural to raise the issues immediately and tackle them head on. But let’s also consider this wisdom:
The worst way to achieve a goal can sometimes be to pursue it directly
Imagine, now stay with me, it’s another Sports analogy, and I’m borrowing it from the book Atomic Habits, but imagine in the high scoring game of basketball, you were regularly paying attention to the scoreboard, looking up after each point added; ultimately losing focus on the game itself. At which point, you’ll need to accelerate to speed up (or sprint) to catch up, which is rarely sustainable, at which point the drive to get to an inflection point might not be enough to win — which of course is the ultimate objective.
Understandably, it’s harder to not look at the score constantly, especially when you’re behind. Inversely, when the game is going in your favor, you may find yourself giving much less attention to the board.
Back to reality, understanding the score in software development teams is more nuanced. You could argue that points represent the revenue your business earns. But your focus should be working together to create a winning business that adds real value to its customers. This can be tough, especially given that most sane people are driven by money at least to some degree (including myself). But pursuing it directly probably not the most efficient strategy. This is when cadence and flow comes in.
Why Cadence
Firstly looking at alternative methodologies, such as momentum or velocity (a subcomponent of momentum), both of which can play critical parts in the build process to productivity, they are the initial movements of direction (or inertia). We hear them in ways such as building momentum or gain velocity (or traction). Speed on the other hand (or high speed, or being fast) is no doubt also a goal of many inexperienced managers. Asking how can we do more in the same amount of time. Easy, work faster (or more hours in a day). Anyone not living under a rock paying attention to good leadership hygiene knows this is where working smarter not harder comes into play. But that too is likely to fall flat. I would argue that many teams are already working intelligently. Sure, maybe a thing or two can be altered for better efficiency (better planning for instance).
In my previous experience of adopting Linear, a project management tool, the real value add was how the tool mostly gets out of your way, and embodies their core value of generating momentum. In their words:
You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.
I would even argue that this is the act of having a steady cadence. Or rather, one foot in front of another (or in cycling, the rotation measurement of pedaling). And in software development, particularly capital A Agile, they refer to them as sprints — although I like to use the healthier word cycle.
Maintaining a healthy cadence, whether uphill or down, lessens the value of speed, but more often than not gives you a better sense for predictability, and surprisingly can help the team be faster inadvertently.
Isn’t that velocity, you ask? Well…
Cadence refers to the number of repetitions of a particular activity, such as the number of steps taken. It is a measure of the frequency of the activity.
Velocity, on the other hand, refers to the speed at which the activity is performed, such as the distance covered per unit of time while performing the tasks. It is a measurement of the pace.
In short, cadence is your frequency, while velocity looks at speed and pace. And because product development is not a paved, flat, and known route; optimizing for velocity is a silver bullet to burnout.
Again, in the event of running a marathon filled with rolling hills, it would be absurd to consider keeping pace on the uphill compared to the downhills. The best strategic approach among professional athletes is to keep cadence (a steady flow of steps per minute). No doubt there will be slowdowns on the ups and speed ups on the downs, but it’s all in pursuit of being more productive in the long run.
& Flow
Flow is a magical space. A quick aside, I highly recommend watching Disney’s Soul — a beautiful illustration of what getting in the flow can look like.
We’ve all [hopefully] been in a place where we’ve seen and experienced the effects of being in the flow. Whether writing, playing video games, exercising, programming, or any other enduring activity.
As a leader, I take most satisfaction when Engineers can find their flow. Preferably moving in the right direction (ha), but still being in the flow is where the greatest work happens. There are of course preliminary steps to get there, such as environment and runway, both of which can heavily influence getting into flow. Nothing is more of an impediment to productivity for engineers than frequent meetings and context switching.
Naturally, to get to flow, we move back to cadence. And as a leader in my experience managing teams, the simple trick of iterating through small repetitions, cycle after cycle, adding regular value has been the best strategy to achieving flow.
In conclusion
While there are many productivity strategies (and sometimes hacks) for engineering teams, cadence and flow are my go-to measurements. While stats such as reliability, cycle times, and value add frequency are important (for real, they are), focusing too much on these metrics can cause the team to lose focus and become unsustainable. Avoid the trap of measuring velocity, aka the speed at which the activity is performed. Maintaining a steady cadence allows for predictability and can actually make the team faster. In addition, flow, on the other hand, is a state of being in the zone and productive. For real, it’s where you want your team to be.
So as I say to all product engineering teams, let’s optimize for cadence & flow, and in doing so we will achieve the ultimate goal of adding real value to customers while being productive.
Dustin Diaz is a VP of Engineering, 3× entrepreneur, author of Pro JavaScript Design Patterns and This is Strobist® Info, and brings over 20 years of insights from previously held leadership roles at Route, Google, Twitter, Medium, Yahoo and Change.org
Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.