Finding Your Operating Cadence
The last time you started a new job at an established company, there was no doubt a lot to learn and a lot of adjustment. But there’s one thing you could probably count on without thinking about it much if at all: the company’s inherent “operating cadence”. Operating cadence is the rhythm and pace at which work is done and organized. It is a big part of company culture but isn’t usually an explicit focus unless it’s broken. This might include poorly run meetings, too many redundant processes, etc. In a well-established, well-run business, goals are clear and work happens at a somewhat predictable pace. Quarterly sales targets, earnings reports, annual budgeting processes, seasonality, historical product development speed and customer expectations all converge. Together these create rhythm and momentum that everyone understands. The company’s operating cadence helps keep things moving along regardless of any individuals personal energy level or focus on a given day – even the CEOs.
But what if you’re running a relatively new company (or a new line of business) that is just emerging? Before you have customers or investors, the only expectations you have are the ones you set for yourself. The only work is that which you decide to do. Even when (maybe especially when) you start to build a team, get customers and raise some capital, there can still be a sense that the only internal momentum is coming directly from you; that everything will come to a grinding halt the moment you stop pushing.
So it’s vital to your own and your company’s well being that you find a way to get the company flywheel turning on its own as quickly as possible. What you do during this stage of development may set the pace and tone of your business. That will define the company culture and cadence for years to come. The question is, how?
After 25 years of launching new companies and new products here are a few practical and straightforward disciplines that have helped me and others I’ve observed navigating this very tricky time in a company’s development. I will explain each one in more detail below.
- Set a limited number of highly specific KPIs for any given period and revisit them regularly
- Conduct regular, disciplined internal business reviews, no matter how painful or time consuming they may feel
- Use Agile principles (if not full Agile processes) in every function and significant initiative
- Give your team clarity on roles and decision-making authority early and insist that they use it
These are good general business practices for any size business. However, they are particularly important disciplines to embrace early in a company’s life. A bit of structure early can go a long way towards having an effective, fast-moving culture as you scale up. Here’s a little more detail on each one and how it can help you establish the right cadence.
Choose highly specific short-term KPIs (no more than 3)
KPIs, OKRs, call them what you want, the key thing is that what you use to measure internal progress must be very specific and actionable within a given time frame. High-level goals like absolute revenue, profit or user/customer growth may be critical metrics for objectively measuring the value of a business and its overall performance but those kinds of metrics are rarely actionable in a short time frame. Setting absolute growth goals will do little to help your team focus their day to day efforts and output.
So pick something very specific like, “get direct product feedback from 25 potential customers in the next 30 days”, or “increase free to paid conversion rates by 20% this quarter.” These examples are precise, actionable and measurable for a small team. They also take effort from everyone to accomplish. For example, talking to 25 customers may seem like a bizdev or marketing activity but you can’t do that without a solid working product demo or at least solid mockups from the product development team. Likewise, improving LTV (if you have a product in-market already) directs the whole company’s work towards a very specific set of activities that even very small companies can mostly control internally. This includes: better product onboarding, CRM and customer service, new product features or better product performance, price testing and optimization.
Just as importantly, by setting highly specific, actionable goals you are demonstrating that understand the intricacies of the business and are willing to prioritize – another important cultural value. By definition, if you say that improved LTV is your top KPI this month or quarter, you are also saying that other things that could drive growth (such as acquiring more new users or doing a distribution deal) are at lesser priority – at least for now.
It’s also important to note that your KPIs need revisiting and possibly revision regularly during the early stages of a business. At least every 30 days at first and quarterly thereafter.
Conduct regular in-depth business reviews
Most startups today operate with a high degree of transparency and for good reason. The more people know the better they can equip themselves to make good decisions, and the less operational friction you create. Transparency also breeds a culture of personal responsibility to the business. So reporting dashboards are usually widely available and KPIs are visible to anyone at any time. Or at least they should be.
So why take the time to conduct regular (at least monthly IMO) business reviews if everyone already has access to all the data? They do take up time and aren’t always easy meetings. The answer is that they go a long way to establishing and maintaining a healthy operating cadence – and company culture:
- They create a consistent rhythm and reinforce a culture of accountability to results.
- Business reviews will help your company “institutionalize” your KPIs and help everyone fully understand the rationale behind choosing them. Because you’ll be discussing them regularly.
- Many minds looking at the same data together will often find new insights. Good business reviews can quickly lead to focused creative thinking and brainstorming.
- Regularly discussing results in open forums allows you to recognize and celebrate small successes that might otherwise go unnoticed. Just as important, reviewing challenging outcomes and performance disappointments in an open forum has a more intellectual and emotional impact. Positive or negative, the in-person discussions will help the team feel more included and accountable.
- They are an opportunity for the team to regularly see and hear how the CEO and leadership team think about and respond to problems and opportunities and vice versa. It’s not an issue when you are 12 people, but it becomes much more important as you scale.
- The meetings ensure that everyone works from the same set of information and assumptions. Arguably your entire team should regularly be looking at dashboards on their own, but the reality is that it doesn’t always happen – especially not in-depth and with the same regularity. So make it inescapable.
- Even when you outgrow the ability to do full team business reviews, the meetings provide opportunities for new team members and individuals with specialized knowledge or functional roles to occasionally join the meeting and discuss the results of what they’ve been working on and see the leadership team interact together.
Everyone needs to find what works best for their company, but my personal preference is a short and relatively small weekly dashboard review meeting. This can be often at the beginning of the week. You can also have a bigger more in-depth monthly business review meeting. This allows time for discussion or to dive deeper into specific areas of interest. If you’re transitioning from a pure product development focus to having a live product and customers, you may want to start by adding a metrics review to your regular Agile retrospective meetings. Eventually, separate it out into its own meeting.
Try to use Agile principles in every function
At its core, Agile is a very effective project management methodology designed for software development. It is exceptionally good at breaking large, complicated product development initiatives down into digestible chunks of work. Like time (sprints) for small teams that can generally self organize their work and adapt dynamically to changes. Once I started using Agile for product development in the early 2000s, it quickly became apparent that the basic principles work just as well for any loosely defined, complex project or initiative that is likely to evolve and change over time. I.e, virtually anything a startup or rapidly growing business is likely to encounter.
For example, an early-stage sales and business development initiative have a lot of the same organizational and process challenges that Agile was designed to address for software development. This is similar to my example above of talking to 25 new customers:
- It’s a broad initiative that needs to be broken down into digestible pieces (stories, tasks, and sprints)
- The work requires a small cross-functional team as product demos, customer meetings, and results steer the work. Participants typically wear a lot of different hats.
- Success requires regular communication, ideally in-person to track progress, discuss any obstacles and dependencies, etc. (standup meetings)
- High-level goals are in place but how to accomplish them is best decided by the team doing the work. The approach/priorities may change over time
- The final output requires both a high level of quality and flexibility. In this example valid, actionable customer feedback and leads.
- The team needs to be able to measure its progress over time and learn what it can accomplish in a given timeframe (velocity). Just like product development, companies need to learn how fast it can go to market with their team and resources.
- It is critical for the team to reflect on its progress periodically, and fine-tune its approach (retrospective meetings)
Agile goes quite deep into specific methodologies, best practices, tools, and terminology around each of its principles but you don’t have to be an Agile-trained software developer or product manager to appreciate – and put to use – some of its most basic methodologies as described above. By adopting simple Agile principles for anything complicated, you can save a lot of time reinventing the wheel on new processes and quickly establish a rhythm for small teams that self-manage. As a bonus, your biz dev and product teams might even find themselves talking the same language. Moreover, they can better understand what the other does.
Define roles and decision-making authority as early as possible
No one likes writing job descriptions. Especially when it’s a startup where everyone is wearing many hats and specific roles seem to change all the time. When you are under a dozen people and the dynamics are good, you probably don’t need formal job descriptions. So you will instinctively reject anything that smells like big company bureaucracy. But if you expect to continue growing fast, a lack of clarity around decision-making is virtually guaranteed to breed uncertainty and inefficiency. Without role clarity, everything defaults to decision-by-committee or all decisions have to be run by the CEO. Neither approach scales and both will hurt the formation of a healthy operating cadence. Also, remember that your team not only needs to be empowered to make decisions, but they also need to be expected to make those decisions. Like almost everything else that happens at a startup, what you do has far more impact on culture than what you say.
Here are five organizational questions you should be able to answer if you’re defining roles effectively and empowering your team. It’s not comprehensive but you should easily answer questions like this. If you can’t, or if the only answer to all of them is “the CEO,” you probably aren’t providing enough organizational clarity.
1.Who can authorize spending of more than $X (e.g. $500+, $5,000, $10,000, etc). This one is about financial controls as well as establishing basic trust and culture.
2. Who needs to be in the approval loop for?
- A product feature addition or major change
- A design tweak or improvement in an existing feature
- An ad, social media post or other marketing creative
- A new bizdev/sales relationship or partnership
This list can be much longer. It goes to almost any subjective types of decisions that you make regularly in the course of your business.
3. Who interviews candidates for various positions and what are the core criteria for hiring or rejecting someone? Do hiring decisions need to be unanimous?
4. Who has to approve product roadmap/strategy decisions? Who is the consultant? This is often the trickiest challenge in growing organizations with a lot of competing pressures on product development.
5. Who has the authority to fire an employee and what constitutes a fireable offense?
The best approach to answering most of these role-related questions at an early stage is to do it iteratively. Tackle issues when you first encounter them in a real-world situation rather than trying to imagine every possible scenario in advance. But once you decide how to handle something once, make a habit of codifying it for the future and set up your operating cadence. Build a culture of decisiveness and consistency because uncertainty is the enemy of progress in any team.
