Learning #3: Optimising for Velocity and Optimising for Scale Can Be Conflicting Goals

I have so far in this article series covered the first two of the Cognite scaling learnings: #1- Always Be On Your Way, as well as learning #2, Build Processes and Culture for Continuous Change. The essence of these is that the best way to get things done will change continuously as you grow. There is not a single truth you can turn to. And beware of people who claim to know THE answer! Even learnings from other organisations need to be adapted to your own organisation’s makeup and people. However, to avoid chaos, you need to create a structure and ways of working that balances the needs for stability and for adapting to constant change.

In this article, I will focus on the trade-offs in building for (future) scale and velocity (here and now). Summarized, these trade-offs are:

• Optimise for scalable practices vs getting the most out of the people you have.
• Visibility and predictability of roadmap and plans vs opportunistically chasing customer value.
• Team velocity vs organisational velocity (aka “dependency handling”).
• Optimising for throughput vs optimising for alignment.

People are Your Most Important Assets

A mantra of any modern knowledge-based organisation is that its people are its most important assets. However, most people seem to assume that this means the same thing in a startup as in a large organisation. When you are a handful of people in a startup, everybody needs to roll up their sleeves and get things done, independent of age, experience, or (objective) suitability to the task. Whoever identifies an issue is often tasked with solving it. You can quickly learn new things and become experienced. A single individual needs to cover a broad range of areas, and titles hang low. Make up your own title, you are all peers anyway, and everybody gathers in the kitchen weekly to get and share the latest news. People with initiative, willingness to do things they don’t know how to do, and with a bias for action are rewarded.

As the company grows, the company has more and more specific needs, and you start hiring based on role descriptions. However, startup and scaleup organisations still tend to look for people who “fit their culture”, which typically means people who like to figure out things and not being told what to do (see also Annicken Day’s Culture Code post for an approach that is more systematic). Tony Fadell talks about “breakpoints” in his book “Build”: These are points in the growth of an organisation where new structure needs to be introduced: Tony’s breakpoints are around 15 people, between 40 and 50, then 120-140, and between 350-400 people. At these breakpoints, you need to make changes to how you do stuff, while ensuring that your existing employees understand the changes that are happening and that they can get new challenges, not only feel that something is lost. This is non-trivial as many of the changes you need to introduce seem to be conflicting with how your old-timers want to work. Very often these breakpoints are not executed well or are started too late, and you end up with growth pains you should have had while you had far fewer employees and things were easier to manage.

I have mentioned introducing role definitions too early as an important trap to avoid. However, what you do need are clear expectations for how people are supposed to work together. You need more structure and process in order to scale, but you risk alienating many of your most important employees unless you spend time on making sure that they can find their place. They are likely to feel constrained by roles and are annoyed by meetings that only concern how to get things done, not actually getting things done. And since they are likely to lean into solving the hard problems, they are often not too concerned about engineering work practices that allow things to be scaled, maintained over long time, or done in standardised way.

The “siloed role trap” is often the result of the introduction of externally recruited functional leaders/Vice Presidents (typically engineering, design, program management, and product management) who feel they need a team and start recruiting (internally and externally). Leadership groups are often established based on functions or “”one from each function”, and unless you have a strong product culture with clear practises that are anchored in cross-functional product teams, you start getting functions that focus on planning within their own function. This happened at Cognite with the functions building expectations to each other based on a siloed understanding of what the other functions were supposed to do. Once this started to happen, it was really hard to change the culture back to “how do we build product together” instead of “how does function X do things”.

How to Build Customer Value?

In the early days of a company’s life, you have not yet found a product that works (aka product-market fit). You cannot afford building a castle in the sky, you need the product to connect deeply into the problems of the customers. But you don’t know if you have found a solution that works for other customers until you get (in business to business) 6-8 other customers willing to pay for your solution to the problem. This phase is sometimes referred to as “seeing what sticks”. You need smart product teams to opportunistically chase customer value. And then you need to sift through and make product out of the things that work. This latter thing is often forgotten as the organization is so focused on finding what sticks.

However, as you grow, there will be calls for roadmap, reporting, and questions about where you spend your product resources. You will be pushed towards more planning and more project management. Yes, you need a product strategy and yes, the product teams need to spend time on the right things. But unless you are careful, you quickly end up with a top-down driven roadmap and your empowered product teams end up as feature teams (see Marty Cagan’s excellent discussion of the difference). The same is true with program management and product operations. Diligence in execution and attention to details in planning and releases are necessary. But a bit too much and too many people focused on planning and process (or people with the wrong approach), and you are turning the organisation from being outcome-focused to output-driven.

At Cognite, we were so good at chashing customer value that we could have built many companies around the problems we solved. We resisted roadmaps and planning simply because our company priorities changed so often that we were unable to build a stable product. A six month priority seems like a long time in sales, but for the product organisation this is not long enough to build a lasting product. You need to remember as you grow that unless product builds what the majority of the customers want and sales sell what product builds, you are not a product organisation. The most important product decisions need to be driven by product, but decided on by the most senior leadership team and maybe even the board, and every funtion needs to be behind these decisions.

Dependencies Slow You Down

At Cognite, we were so successful in selling to new customers with slightly new challenges (though within our core broad product scope) that the majority of our engineering capacity was spent on discovery, prototyping, and proof of concepts. We got a fragmented product and struggled defining a clear, repeatable go-to-market strategy. Cleaning up and consolidating was a major effort that temporarily impacted our velocity for too long.

When you get to a certain size as a company, more and more functionality relies on refactoring a service you already built, expanding it, or maybe building an entire new app while incorporating functionality from an earlier version. Either way, you need to continously invest in refactoring existing functionality to fit with your refined product strategy of today. When you built that thing a year ago, you didn’t quite see the bigger picture you see now. Building new versions and leave the old running will give you short-term velocity, but at some point will have far too much debt (and lots of customers on half-baked code) and your velocity will grind to a halt. In a startup’s early phases, you don’t really know yet what is going to stick, so don’t engineer things too well. When you see that something should be a core part of your product (70-80% of your customers should use that functionality), you need to very pro-actively refactor !

Sidenote: “don’t engineer things too well” is not a recommendation to go wild west, allow any language, or any practice. It is important to have a baseline set of engineering practices that you always follow unless you are sure you are doing a throwaway prototype. All code that is used by a customer has a tendency to become part of the product. How to manage customer expectations and deprecate old code when you allow customers onto prototypes is a topic worth a separate discussion.

How do you keep the velocity of the early days of your startup while also making sure that you refactor and consolidate functionality in a way that allows you to build new features? There are three basic patterns you can use to handle dependencies:

• Use a customer-supplier relationship between your internal teams and sequence their deliverables (“When can you give me API x and component Y that solves the following problems for me?”). Many larger organisations use this model.
• Program manage dependencies across teams with joint milestones and a future release date.
• Establish a virtual team with participants from each important code base and empower them to deliver.

We used the virtual team approach at Cisco, so I knew that worked. Also, that is what naturally happens if you have a unified tech stack and all engineers are able to commit to all repositories. However, at Cognite, the teams were used to either working dedicated in their own code bases and stay in a team for a long time, or that we stood up new teams to tackle new problems (thus abandoning code bases). The culture was thus split in half. Very few teams were able to do both regroup into new teams and tackle new challenges as well as maintain a product code base over time.

At Cognite, we wanted to ensure that all teams got a better understanding of the end to end customer problems we wanted to solve. Also, as a scaleup working hard to get to profitability, we wanted to optimise for getting new functionality out quickly, but built in a sustainable way. The leanest approach was then customer-problem focused virtual teams (with members from different tech areas) with clear empowerment and closeness to their customers. However, with our sprawling tech stack and culture for prototyping, we needed multiple teams to work together just to get some functionality out.
To change this pattern, we established product initiatives for the key strategic priorities with one team as the clear owner of discovery and used a two-month release cadence to coordinate implementation across multiple teams. To avoid too many stakeholders in each initiative and to reduce coordination costs, we asked the engineering managers to program manage the deliverables.
This model takes time to get right, but we HAD TO implement features across lots of code bases. We didn’t want to slow down development and probably ruin joint understanding of end to end customer value with a customer/supplier relationship. And we didn’t have the scale to take the coordination costs of program management and risk fragmentation of ownership.

After two cycles, we started to see some of the customer-near teams increase their planning horizon, and overall velocity on solving larger end-to-end customer problems started to pick up. We saw how these cross-team product initiaives taught people how to work together across teams, form new teams, and independently we worked on cleaning up our tech stack. Our hypothesis was that by focusing on continuous discovery work on new product initiatives while practicing formation of virtual teams around initiatives, 2-3 teams would emerge as more stable customer-focused teams that could tackle the larger product initiatives with more horizontally focused teams that now knew how to contribute into virtual teams to deliver end-to-end customer value. After our third cycle, we got a new Chief Product Officer (CPO) with background from AWS and Microsoft. He immediately initiated a shift towards an AWS model with Technical Program Managers (TME). As a result, I cannot say anything about whether we would have been successful in our transitioning as programs were established top-down and many team identities were replaced with program-identities, thus basically top-down forming customer-focused teams.

I’m personally sceptic to a technical program management focused operating model for scale-ups. You do need a project execution focus. However, there are some important negative side-effects when you dedicate program managers to ensure this focus instead of instilling it in your culture and operating model of building product. Firstly, instead of an engineer talking to another engineer to resolve a dependency where the possible solution is an integral part of the discussion, you get a program manager handling the alignment. The solution is defined with less technical collaboration often leading to inferior solutions and increased integration cost. Secondly, program managers often end up with the “measure success” ownership as they are closest to the result of product execution. This can distance product management from measuring outcomes, something they clearly need to own and drive to adjust and iterate. Thirdly, as program managers are responsible for resource allocation (in order to be accountable for deliverables), you reduce engineering managers to people managers. Alternatively, you end up with team leads, senior engineers who take on people management because that is the only path to have more say in how things are built. You get some great managers and then you get some great technical people who should never have had people responsibilities. You also typically loose a lot of really great senior coders. Finally, due to the ownerships being fragmented across many different roles, it is harder to get people to see the end to end bigger picture. You will struggle with growing more holistic senior product leaders, and you need to invest in a lot of communication. The organization has a tendency to become more top-down as less people see the whole picture.

Throughput and Alignment

The tradeoff between throughput and alignment i a higher level tradeoff than the others. In the early phases when you don’t know what is going to stick, you want smart people to group together in teams to focus on customer problems, find good solutions, and incrementally build a hypothesis around what your product is going to be. You want to work across sales and product to ensure that sales always sells “your best product” and that product hones in on problems that many customers are willing to pay for. In product you will thus optimise for “throughput“, meaning more outcomes solved for the customers and more data gathered in order to make the right decisions on what your product is going to be. Practically, this means that you will allow more duplication across teams if it increases their velocity. It also means that you will allow more variance in the tools, languages, and frameworks that are used. People will be productive in different tools, and they will choose what they are fluent in. Overall, dependencies are handled ad-hoc and between the teams, typically by techleads or engineering managers.

So, you will get some designs in Figma, some in Miro, some in Framer, and drawings will be in draw.io, lucidchart, or Miro. You will have teams working in React with several different state libraries or charting libraries. Some teams will work full-stack and build node.js backends, maybe Python. Other teams will use Java or Kotlin or Rust. Where do you draw the line?

You struggle painting a roadmap, because all the teams do their planning in different tools and with different timelines and granularity. And you don’t really have the concept of a release because the teams ship when they are ready. What does “shipped” really mean to customers? Is the functionality stable? Can they rely on it for their own work without getting surprises? Do they get a Service Level Agreement (SLA)?

How much alignment do you need? When? Where? The answer is both “more than you think” and “less than you think”. In sum, any operating model for large companies where accountability is distributed is made to rely less on individual excellence and more on repeatability and standardised roles. This is clearly a choice to make as you grow. But remember that creating more alignment does not necessary mean adopting a large company’s operating model. AWS’ and Apple’s operating models are two very different models. And Cisco with its acquisition strategy for product innovation has a far less structured operating model allowing variance across business units and product areas.

As you grow, my recommendation is to establish early deep alignment where you have limited costs to do so and identify where you need to be world-class. You want the most freedom for the teams to find the right path where you really, really need to compete. No company has been successful because they chose Framer over Figma, or because they enforced the use of Java in all backends. If you have areas that need super-high performance and where reliability is important, maybe Rust is the right choice. But then again, maybe that is not something that will be important until two years down the road. Be conscious that when you hire people, you also make alignment decisions as they will come with their own set of ways of working.
As a general rule of thumb: take the cost from day 1 of training everybody on a baseline set of tools, languages, frameworks, and methodologies that form a foundational set of “how we do things around here” (see What Good Looks Like). But allow deviations where you have a strategic advantage of doing so. Train your teams in making trade-off decisions by showing them the consequences of their choices to the wider organisation. And set clear boundaries for what kind of decisions individuals and teams can make on their own (but give as much empowerment as possible within the constraints). And finally, make sure that any decision that has to be made organisationally-wide can be raised with very little red-tape and quickly concluded on.

My next and last article in this series will tie together the learnings covered in this series into a framework for how to manage and evolve your operating model. This is learning #4: Your operating model needs to be coherent, built on a set of fundamental principles, and evolve over time.