Learnings From Scaling a Product Engineering Organisation to 280 People – Part 1

Follow me on Twitter/X @GregerWedel

Back two years ago, I wrote a blog post on the principles and biggest pitfalls of scaling a product organization charged to build a unified and complex product. Naturally, being employed at Cognite, what I had in mind was the Cognite Data Fusion platform product and its ~280 people product development organisation. In an upcoming series of posts, I want to share the four most important learnings from the last two years. These learnings lead to an evolution of a coherent and unified operating model for product development that can be described along six aspects.
There is a one-liner: there is no such thing as the best way of organising a product development organisation. How you build product should be more contextual and tailor-made than what the literature out there tells you.

Context: Cognite’s Product Development Organisation

To better understand what we did, why, and our learnings, it is useful to understand the state of the Cognite product development organisation back 2-3 years ago. Cognite was initially funded by Aker, an industrial investment company, and Cognite’s sister company AkerBP (Norway’s 2nd largest oil & gas company) was from the beginning a close partner and pilot customer (this collaboration was also extended to other Aker companies). Cognite product engineers were working very closely in teams with AkerBP employees to solve real concrete problems that gave real value while also trying to build a product at the same time. It was a challenge to bring the learnings from 10, 20, 30+ projects with individual goals into a unifed product vision suitable to scale to many customers’ problems. The product development organization was set up to maximize success in each project, and the result was a fragmented product experience with lots of code in prototype- and proof of concept-stages. There was a very clear company vision and strategy, but it was not detailed and close enough to the day-to-day priorities to drive all the teams towards a single, coherent product experience.

The result was a highly fragmented and distributed understanding of the customer problems how they should be solved. Features were being pushed out in a continous stream based on a local understanding of priorities. Small subsets of users got feature improvements, but it was hard to tell a coherent product story on the company-level. So, in order to fix this, we had to make dramatic organizational changes along three dimensions:

• how we planned and prioritised features – from a fully distributed model, to a centralised model with local empowerment.
• how we built the product – from a culture where features that did not involve other teams where prioritised, to a collaborative culture where dependencies were identified, joint deliverables defined, and features were delivered together.
• how we released the product – from a DevOps-oriented continuous stream of uncoordinated updates, to a continuous delivery model with feature toggles and company-wide releases focused on end-to-end customer value.

Two-three years ago we had a product organization split into four functions, each reporting up to a leader in the product leadership group: product management, design, engineering, and Office of the CTO (including infrastructure and security). We emphasised empowerment of the product teams, and the product trio of product management, techlead, and designer. We looked to Atlassian and Dropbox as reference organizations. Each of the four functions were also represented in the company executive management team. It was very clear that we didn’t have a clear operating model for building product together, and the functions were to a large extent doing prioritzation and planning in silos, and often bottom-up and based on what was going on in the teams. This created fragmented prioritization, confusing context for the teams, and a feeling of not being empowered, just reacting to the loudest screamer. Each team had responsibility for less than 4% of the total product, and it was hard to aggregate priorities up and get agreement around what should be organizational priorities.

Four Key Learnings

Throughout this series, I will describe how we practically set up the organisation to change along these three dimensions and what we learned. In hindsight, I can summarise four key learnings. These learnings may seem to be things you have heard before, but for each of them I will give you more context to allow you to go beyond the surface level:

1. you are always on your way towards an ideal organization
2. rather than focusing on some ideal end state, focus on building processes and culture that allow continuous change
3. optimising for velocity and optimising for scale can be two conflicting goals
4. your operating model (how you set up your organization and processes to get things done) needs to be coherent and follow the same set of fundamental principles.

A coherent operating model should cover the following six aspects:

• how you ensure focus on the value to the customers,
• how product priority decisions are made,
• how you communicate and give teams enough context,
• how code and people dependencies are managed,
• how you ensure things are built the right way for long-term success, and
• how things get into production and into the hands of the customers

Unless these six aspects are done in a coherent way, you will confuse the organization and loose a lot of velocity.

Having four product functions all report up to the CEO makes it really difficult to agree on roles, how to get things done, and how to collaborate. With all the leaders coming from different “schools of thought”, you can have endless discussions on “what is the right way”. Ours tended to focus on how to identify the top priorities in a very fragmented picture of requirements, needs, and signals from our commercial organization, partners, and customers. And, as described to above, we had lots of discussionns around roles.

In subsequent posts, I will deep dive into the four key learnings and explore the six aspects of a coherent operating model for product development and how to build one. Understanding these should allow you to build your own coherent operating model that is uniquely adapted to your context, phase, needs, and people.