Even small startups are amazingly complex networks of teams. Each team produces a ton of data that is either used by the team internally, or is sent to other teams using some sort of tool. For example: A marketing team runs campaigns and feeds the resulting leads to the sales team, but also analyzes an alphabet soup of KPIs internally.
Sales tries to close those deals through calls, meetings and two-martini lunches (their internal data feed). And if worth their salt they will let marketing know in very explicit terms if those leads are any good. So we add an outgoing feedback feed that starts at sales and becomes marketing's incoming feed.
Looks simple, right? Two teams with one internal data feed, and one outgoing and one incoming data feed, each.
Now let's add four more teams: DevOps, HR, Product, Finance. Each has an internal data feed and exchanges information with the other teams. And suddenly the network looks like a drawing of a toddler:
Of course not all of those feeds warrant their own process beyond "Slack me when you need something", let alone their own tool or dedicated person. But the complexity of the organization increases faster than most people are aware. And it can slow down even the nimblest organization very quickly.
Early milestones such as "We just hired our first dedicated HR person" or "Finally someone else is doing the accounting stuff" introduces new tools and new links in a company's network of teams.
Later, teams are often split in two, e.g. a sales team responsible for new business, and an account management team that handles existing customers. Again, that’s another team that needs to be fit into the network.
Format matters
Hardly any organization will ever reach the maximum number of data feeds, but it’s a good reminder how quickly complexity grows. Another aspect of complexity is the format of the data that’s being sent.
One example is above, here is another one: A customer support team will send feedback on various features back to product. Such feedback is turned into new or altered features (via product's internal data loop). However, what product sends back to customer success is not a list of feedback but a description of new functionalities. Those might even necessitate additional training for the CS team, yet another form of data that's exchanged between the two teams.
Speed, speed, speed
Granted, this is a fairly formulaic way of thinking about how a company operates. And again, not all teams (thankfully 🙏) have to communicate all that much with each other. But this framework is the starting point of how high-growth internet companies should think about their inner workings. Speed is so essential, especially at the beginning of a company, and maintaining it despite growing complexity is hard.
Ops focuses on exactly that. It starts by analyzing the overall business equation: How does the business actually make money?
What are the most important processes for that equation?
Who is working with whom?
What sort of data does each team generate?
How does it share that data with other teams?
What does the team receive in return?
What are the best processes or tools to manage all of that?
We’ll answer and explore each of these questions in future posts and also talk about what additional insights Ops generates given its vantage point deep inside the machine. Let’s go 🚀
Thanks to David and Simon for editing this post.