What is Operations?
Unpacking the all encompassing term in early stage tech companies.
I’ve spent a lot of my career working in “Operations” in tech companies. This has resulted in spending a lot of time explaining to people what exactly it is I do. Unlike Sales or Product, there isn’t an immediately obvious, tangible outcome that Operations is associated with. Operations is one of those nebulous terms that’s everywhere, and yet there is no one agreed definition on it. In a selfish attempt to reduce the time I spend repeating myself, I’ve decided to write this overview to help unpack the mystery of Ops. This overview focuses on early stage tech companies (Pre-Seed to Series B-ish), diving into:
Defining Operations
Operations Org Structures
Advantages, Pitfalls & Considerations
Defining Operations
There are 3 broad areas which are typically defined as Operations:
Operations - the internal operating system of a company
Operations - the scaled customer impacting workflows
Operations - the physical component of product/service delivery
Version 1: Operations is the internal operating system of a company. It’s how people, technology and processes intersect to get work done.
Operations in this context refers to the inner workings of a company. It incorporates a wide spectrum of activities. In its broadest range, Operations is every activity which supports the making and selling of a company’s product and services. It’s everything from hiring people to build the products, to ensuring the product is legally compliant with regulations. It’s implementing tools and processes which allow teams to gather insights and work more efficiently. It’s designing and leading cadences which enable all parts of the organisation to work in tandem. Operations is a standalone function, an embedded function and a conduit between functions:
Standalone Operations: Often internal-only teams. Historically referred to as the “back-office” e.g. Legal, HR, Finance. These teams are responsible for the day-to-day running of the business, and in supporting the delivery of the company’s products and services.
Embedded Operations: These are specific teams or roles whose purpose is to enable their part of the organisation to operate effectively e.g. RevOps, ProductOps, FinOps. They analyse data to gather insights. They design workflows, implement tools, automate processes and deliver training. They are the operational backbones of specific teams. They are often the first point of contact when their team needs to interface with other parts of the org. Embedded operations that are not part of internal-only teams usually report to the senior leader in their org e.g. SalesOps to Head of Sales in the Commercial org. However, in early stage companies, these roles sometimes have dotted lines, or directly report to the Operations leader.
Conduit Operations: Sometimes referred to as the “connective tissue” or “glue” in an organisation. Operations acts as a conduit between distinct functions within an organisation, and distinct teams within a function. It is the systems and practices (e.g. cross-functional meetings, goal setting process) and people (e.g. Chief of Staff, BizOps, Programme Managers) that ensure alignment within teams and across the entire org. It acts to fill the cross-functional gaps identified under the guise of special projects.
As you may have gathered by now, Operations is everything. Distilled simply, Operations enables and connects.
This version of Operations is applicable to all companies as all companies have people, technology systems and processes. However, not all companies refer to, or even consider these activities to be “Operations''. We’ll delve into why in the Operations Org Structures section.
Version 2: Operations is customer impacting workflows, delivered repeatedly at scale.
Some organisations have workflows which are regularly applied to a large volume of customers and/or suppliers e.g. Fraud Ops in a payments company, Driver Ops for a rideshare app, Supplier Onboarding Ops for a marketplace, Vendor Ops (for Support) in a social media company. These types of Operations are often invisible to the end-user, yet have an impact on the customer experience.
These workflows may be delivered by employees or outsourced vendors or both. The design, implementation and optimisation of these operations is often complex and continuous, yet delivery of workflows is generally repetitive.
This version of operations is applicable to many but not all organisations. It typically features in B2C companies serving large numbers of customers or platform companies whose customers process significant volumes of transactions (e.g. API calls, payments, bookings). However, again, not all companies which have these workflows refer to, or even consider them to be “Operations''.
Version 3: Operations is a physical component of the organisation’s product/service delivery.
Companies that create a physical product, have a logistics component or offer a service often refer to that part of the business as Operations e.g. supply chain management for a wearable device company, or fulfilment ops in an e-Commerce company.
This version of operations is applicable to a small set of tech companies and a larger set of tech-enabled companies. It is more traditionally associated with organisations that make and/or move things e.g. manufacturing plants, pharma, retail, transportation providers, humanitarian NGOs. And yes, you guessed it, organisations may not refer to, or even consider these activities to be “Operations”.
To summarise:
Operations is the internal workings of all companies, the scaled customer impacting workflows in some companies and the physical component of product/service delivery in even fewer companies, however, not all companies have all 3 types of operations and even when they do they may not refer to, or even consider them to be “Operations”…
You will have noticed that I have failed in my quest to create a singular definition for Operations for the tech world. There isn’t one. Perhaps someday we will be provided with an agreed resolution from the World Operators Organisation (affectionately known as WOO 🥳) For now, what constitutes Operations is largely dependent on a company’s business model, the background of the leadership team and the org structure implemented.
Operations Org Structures
The rest of this article is mostly focused on Version 1 type Ops (inner workings).
In Pre-Seed companies, Operations, if it exists, is usually a one person role and the catch-all term for everything, except Engineering and Design, that the founders do not have time to do. It is the ultimate generalist position. It can consist of highly strategic work (e.g help figure out company strategy, explore market opportunity). It's predominately hyper-tactical (e.g. set up payroll, run All-Hands, act as first X role until hired). This role is usually called Business Operations (BizOps) in the US. It more commonly appears as Operations Manager or Founder’s Associate (junior Chief of Staff) in Europe, although BizOps does appear here too. There tends to be slight variations between the scope, profile hired, and truthfully, prestige of these 3 roles. I’m biassed but I’m team BizOps for many reasons.
Once a company starts to scale, it usually takes on the form of one of the four common scenarios below. (Note: pre-Series B, the most senior Ops role is usually a “Head of” or “VP” unless they are a founder or an exceptionally experienced hire).
Scenario A: COO is responsible for all internally focussed functions & the operating cadences of an organisation.
Scenario B: COO is responsible for some internally focussed functions, where there isn’t another dedicated leader in place. The COO owns internal operating cadences.
Scenario C: COO does not exist. Senior leaders are responsible for ops related to their functions. The CEO and/or Chief of Staff own internal operating cadences.
Scenario D: The COO is responsible for some or all internally focussed functions, some or all GTM functions and some or all of the physical operations related to delivering the products and services.
Whether Operations emerges as its own function depends on:
Division of responsibilities between founders
Founders’ prior experience with Operations (no prior exposure to Ops can make it difficult to understand or value the function, especially the conduit nature of it)
Skillset and order of senior leaders hired
Size of customer base (requirements differ if serving hundreds vs millions of customers)
Centralised or decentralised business model
The nature of the product and/or services being delivered
There is no one right answer. I’ve seen Heads of Sales report to COOs, Ops Managers report to CEOs, CFOs take on additional operational responsibilities beyond Finance. As with any org structure, the best approach for your business is the one that simplifies decision making and best enables execution. It is dependent on the calibre of leaders available and the goals of your business.
However, all things being equal I do believe there is significant value to be gained from having one leader being predominantly responsible for the overall inner workings of a company.
Advantages, Pitfalls & Considerations
Operations has a tendency to be under-appreciated and undervalued. This is partly due to the nature of the role. Consider Version 1 (inner workings) and Version 2 (scaled customer workflows) mentioned above. As humans we tend not to appreciate how bad a particular practice is until someone fixes it (yay, go Team Ops!), and quickly take for granted the marvellous updated process, or continuous improvements made (um..what do Ops even do!?). When systems are broken, or the internal rhythm of a company feels off, we immediately blame “poor Ops”. We rarely take note that the fact that if things are not broken/creaking/bad most of the time, that means that Ops is generally working well. Operations as a function and as a role primarily operates in the background. Operations analyses, enables, connects, scales, delivers. But it rarely takes centre-stage. This is the case with Ops people too who have a tendency to be some of the most modest folk in the industry.
One advantage of having an Operations function is that it enables most teams to not think about operations. This enables them to focus on higher-leverage tasks e.g. marketing managers focusing on creative, rather than tracking campaign data. Work doesn’t just happen. If you don’t have a role/team in your organisation focussed on how the work gets done, and how that work connects with other pieces of work in the organisation, then you are most certainly losing efficiency somewhere. Consider where this may be happening on an individual role level and/or on a company wide basis.
I have also witnessed the bad side of Operations. The pursuit of perfect processes leads to bureaucratic nightmares, grinding the internal gears of a company to a halt. Products are slow to ship. Decisions take months to agree. Time spent in meetings skyrockets. These processes are often well-intentioned yet incredibly harmful. Kill them before they kill your organisation. Consider where your existing operations may be hindering you, why is that the case, and how to change it.
Operations is often viewed as a cost centre, which objectively it is, unless we are considering GTM activities in the definition. It can be difficult to quantify the value of operations (including people and culture related activities) running smoothly, without having a baseline of “bad times” to compare it against. This makes Ops a prime target for metric driven layoffs. It costs to have Operations and it costs not to have Operations. Consider the tradeoffs you’re making.
I've witnessed the spectrum of great ops to bad ops to no ops. Done well, Operations can super-charge a company's growth trajectory. I truly believe it’s a function worth investing in!