Drive Engineering Success By Thinking Beyond the Sprint

To deliver maximum value within an organization, engineering teams must balance strategic, long-term vision with enough flexibility to react to unforeseen, yet inevitable, changes along the way. An operational cadence — a scaffolding of benchmarks and meetings that provide structure for a team’s activities — is one way successful teams stay focused on goals, improve performance, respond to changes, and communicate with other business units within their organizations. We recently went in-depth on the subject in a virtual conversation between Code Climate Founder and CEO, Bryan Helmkamp, and Juan Pablo Buriticá, SVP of Engineering at Ritchie Bros. 

Read on for highlights and check out the on-demand recording here to see the full conversation.

What is an operational cadence anyway?

Juan Pablo kicked the conversation off by summarizing an operational cadence as a collection of meetings, ceremonies, or regular communications that “help create a rhythm for an organization on which to operate, on which to become predictable and do things better.”

Bryan quickly agreed, “I think about operational cadences as really being almost like an operating system… [a cadence is] a set of interlocking practices, some of them might be daily, weekly, monthly, quarterly, annually…together these give the organization the ability to have a shared understanding of what’s happening.” He elaborated that in addition to creating a predictable schedule, operational cadences allow organizations “to have a shared language to talk about, ‘this is what we do each month and this is what that means,’ without having to explain it from scratch every time.”

Fostering alignment, predictability, observability, and autonomy

With the structure and high level benefits of an operational cadence introduced, the conversation turned to the specific value that observing this cadence delivers to engineering teams and their organizations. Bryan zeroed in on one crucial benefit, alignment, and the ripple effect that ensues once alignment is achieved: “With an established cadence, you have the opportunity to increase alignment. And alignment is… a huge factor into how much impact a given effort’s going to have.” 

He elaborated on the importance of this alignment, “Parts of a cadence can serve as a way to identify issues earlier. Because if you have an issue and it doesn’t get surfaced until it’s been going on for months, the cost associated with that and the waste associated with that can be quite significant. By having a regular cadence and set of interlocking processes, you get this backstop at a minimum that makes sure that if there’s an alignment issue, if there’s a change in context that requires a change in priorities, that it’s going to get surfaced and be able to be addressed with appropriate visibility and appropriate collaboration and stakeholders.”

Juan Pablo added his own perspective, “I’d distill the value to three things. When I was in startups, the principal value I got was predictability. I didn’t like running a team where the strategy was changing every week. By pushing strategic reviews into a monthly cadence or a little bit of a longer stretch, we got air cover to work, and we also got the leadership group some checkpoints. Next, observability. If it is a larger organization, if it’s grown past 40, 50, 60 engineers, it’s hard to know — and you shouldn’t be looking to know — what everyone is doing, but rather trying to observe the system or monitor the system from outside…And then the last thing is autonomy. If you have predictability and observability, then teams can be autonomous… to not have a ton of oversight, but there’s still this broadcast of information that is flowing.”

Identifying the optimal cadence

As the conversation progressed, Bryan and Juan Pablo transitioned from the abstract to a more detailed discussion of how and when to implement an organizational cadence. One thing was immediately apparent — there is no universal “optimal cadence.” With variables such as size, structure, goals, and more affecting each business differently, teams must identify what works best for their unique situation. Juan Pablo shared his personal preference, “I generally like… having some weekly ceremonies, some biweekly ceremonies, monthly, quarterly, and then either every six months or a year.” He emphasized that this varies by organization however, “depending on your stage, if you’re trying to move really, really quickly, doing quarterly or yearly planning doesn’t really make sense.”

Bryan expanded on Juan Pablo’s assessment, “I 100% agree that there’s no single right answer. There might be a this-is-best-for-us-right-now answer that everybody can work towards, and it’s a moving target.” He then encouraged people to think about their own organizational rhythms that may be on a longer timeline than a weekly sprint, suggesting that teams supplement their sprints with sessions on a monthly, or even quarterly basis, which “can be very helpful both in terms of the planning side of things, to give people more information about what to expect… and also for the standpoint of that continuous improvement process.”

Bryan then compared the benefits of a strategic organizational cadence against the commonly-used retrospective, “I think retrospectives are fantastic tools, but they tend to gravitate towards small incremental improvements.” He then clarified, “They don’t naturally serve as well to press the really big questions… when you have 45 minutes to try to make some improvements for the next week. And I think what we’ve seen is there’s a benefit to being able to ask bigger questions and to think about bigger time horizons as a supplement to whatever’s working well for you at the tactical execution level.”

Borrowing cross-functional best practices

As the conversation touched on the strategies and practices Juan Pablo and Bryan’s own organizations employ, Bryan relayed several things that he has picked up from watching non-engineering departments within Code Climate. In particular, his sales team caught his attention, “Some of the things that they do that I think have a really interesting opportunity for helping on the engineering side as well, are things like internal QBRs, or Quarterly Business Reviews. They’re not really running team-level weekly retrospectives, but each quarter they pull out, ‘What were all of our successes and opportunities for improvement that we learned over the past quarter. What are our key focus areas going forward for next quarter?’ Maybe there are new ways we’re going to do things or there’s new content that we’re going to introduce into our sales process, and that’s at the quarterly level.”

Juan Pablo responded to Bryan’s point about QBRs with a practice he has put into place, “The QBR is a written exercise. So all engineering groups report on their business metrics because that helps engineers understand what levers they have… it starts giving insight to other people about how things are working, how they’re being impactful or not, and how to be a little bit more business-oriented.”

Bryan tied their ideas on the topic together, “Two elements of that that I think are really powerful: One is that shift from verbal communication or informal communication to written and structured communication. And that’s something that as organizations get larger, I think becomes more and more important. And you just hit this tipping point where if it’s not written down, then this is not going to work.”

He continued on, “But with respect to sort of data and metrics, part of what I’m hearing in there is that there’s advantage to using regular operating cadences as an opportunity to push information out to the collaborators and to those other stakeholders who would benefit from having that same understanding of what’s going on. And I think that that’s an area where every department can always be improving, but engineering in some ways has been a little bit further behind than some of the other functional areas in organizations.”

Metrics as a shared language

With the conversation pivoting to the idea of using metrics as a shared language to ensure cross-functional alignment, Juan Pablo relayed a fitting anecdote. When a former boss approached him to ask why their team was operating slowly, he was initially unable to answer the question. However, after a few months of digging into the metrics, “I was able to talk a lot more about Cycle Time and throughput, and not only talk about it, but visualize it. I started… to understand how to distill all of that to the board of directors who shouldn’t really know that much about capabilities or many of the underlying reasons for these metrics, but every board meeting I could show, ‘This is how far we are. Here’s an industry comparison, what a high performing engineering organization is… how far we are, and the impact we’ve had.”  

With Juan Pablo’s board and team aligned on metrics and strategy, the results followed shortly after, “Two or three quarters after we had started our acceleration strategy, you could clearly see the reduction of Cycle Time… In the period of 18 months, we reduced it by 10 times because we had visibility, and I could explain it and continue to track it with the executive team and with the board, but also I was able to give concrete direction to the engineering group.”

Balancing proactive planning with reactive needs  

In a perfect world, organizations would identify their optimal cadence, align business units and goals based on universally understood metrics, and proactively address anything looming on the horizon. Unfortunately, real life gets more complicated and situations arise that teams are forced to address reactively. Juan Pablo discussed how he manages this reality, “I’ve learned that once I’ve moved to a certain level of direction, I can’t be prescriptive on how we achieve our goals. Where I need to focus is on drawing the line and ensuring that our product strategy and our business strategy is solid… Product engineering needs to find ways to achieve those outcomes. Because then the agility is really only on how they are getting it.” 

Bryan distilled his thoughts on the balance succinctly, “There’s a value in being proactively reactive.” He elaborated with an example, “I’m thinking about how there’s this tension between, for example, roadmap feature work and things that might come up from incidents, escalations, or customer requests… I think that’s the first piece, to plan for the fact that some of the work is going to need to be reactive and you’re not going to know what it is until it comes along, but you know that something is going to come along.”  

Implementing and optimizing an organizational cadence

To close out the conversation, Bryan and Juan Pablo turned to the practical matter of who should be responsible for deciding upon and implementing an organization’s cadence, and how to do so. Juan Pablo laid out his perspective that while cadence should be coordinated with the executive group to ensure company-wide alignment, it “should be sponsored by the leaders who have ownership over it. I think engineering managers can only get as far as their own group, some of their peers groups, product, or other functions that they work in, but they’re going to have zero influence on strategic executive planning or other things.”

Bryan added, “I would say don’t make perfect the enemy of good. Get started with understanding that you’re going to iterate the cadence itself. Everything’s going to be iterated. And I agree 100% with what Juan Pablo said, that leaders do need to lead, and this is an area where leadership is really important.”

Using data to drive engineering success beyond the sprint

Successful engineering teams can leverage data in tandem with an organizational cadence to stay aligned and perform at their highest level. To learn more, watch the full webinar or speak to a product specialist.