The last time you started a new job at virtually any 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 gets done and organized. It is a big part of company culture but isn’t usually an explicit focus unless it’s broken (e.g. 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 to create rhythm and momentum that everyone understands. The company’s operating cadence helps keep things moving along regardless of any individual's 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 pacing 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 company development may set the pace and tone 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 belo
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, but they are particularly important disciplines to embrace early in a company’s life. A little 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. Set 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: better product onboarding, CRM and customer service initiatives, 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 operating discipline. 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 to be revisited and possibly revised 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 equipped they are to make good decisions, and the less operational friction is created. 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 - 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 an open forum allows you to recognize and celebrate small successes that might otherwise go unnoticed by many in the team. Just as important, reviewing challenging outcomes and performance disappointments in an open forum has 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 is working 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 across the team. 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 (often at the beginning of the week) and a bigger more in-depth monthly business review meeting that 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 and then eventually separate it out into its own meeting. 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, and 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 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 (like the example of talking to 25 new customers I used above) has a lot of the same organizational and process challenges that Agile was designed to address for software development:
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 team 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, a company needs to learn how fast it can go to market with a given 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. 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 engineering teams might even find themselves talking the same language, with a better understanding of what each other do! If you're interested in exploring the use of Agile beyond software development, here are a couple of good articles that go a little more in depth: Harvard Business Review: Embracing Agile McKinsey: A business leaders guide to Agile Define roles and decision-making authority as early as possible No one likes writing job descriptions, especially at a startup where everyone is wearing many hats the 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 and will instinctively reject anything that smells like big company bureaucracy. But if you’re growing fast and expect to continue doing so, 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 simple organizational questions you should be able to answer if you are defining roles effectively and empowering your team. It’s not comprehensive but if you can’t easily answer questions like this, or if the only answer to all of them is “the CEO,” you probably aren’t providing enough organizational clarity.
Who can authorize spending of more than $X (e.g. $500+, $5,000, $10,000, etc). This one is about creating financial controls as well as establishing basic trust and culture.
Who needs to be in the approval loop for [_______]. Fill in the blank with things like: 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. The list can include any subjective decisions that have to made on a regular basis.
Who interviews candidates for various positions and what are the core criteria for hiring or rejecting someone? Do hiring decisions need to be unanimous?
Who has to approve product roadmap/strategy decisions? Who should be consulted? This is often the trickiest challenge in growing organizations with a lot of competing pressures on product development.
Who has the authority to fire an employee and what constitutes a fireable offense?
The best approach to answering most of these and other 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. Build a culture of decisiveness and consistency because uncertainty is the enemy of progress in any team. Other perspectives on establishing operating cadence: John Lilly (Greylock Partners): Cadence in organizations David Brock: The importance of establishing a cadence Note: This post was originally posted by Dave on his LinkedIn profile in 2019