Learning #1: Always Be On Your Way

Follow me on Twitter/X @GregerWedel

The last two years, we learned four important things when scaling Cognite’s product organisation to 280 people: you should always be on your way towards an ideal organization, focus on optimizing for change, getting velocity and enabling scale can be conflicting goals, and you need a coherent and unified product operating model to avoid confusion and get a healthy and productive product organisation.

In my previous article in this series, I introduced our four key learnings and the six aspects that are key in a product operating model. In this article, I will cover the first of the four key learnings: why you always should be on your way and not get stuck on the idea of what is (supposedly) THE right way to organize.

At Cognite, we grew incredibly fast. When I joined, 3 years and 3 months after the company incorporated, I was employee number 388 in the HR system. Up to three months before I joined, everybody in the product organisation reported to the head of product, and some months we added 10% of the size of the company. I have often alikened scale-ups with teenage boys, and there are no organsations I have seen where this has been more true. Some parts, like the technical DevOps setup and security controls, were as mature as in much older companies. Other parts, like how to make good, coordinated product priority decisions or good people management felt more like the early days of a startup, but there is a limit to how many people you can fit in the shared kitchen.

As you grow, you hire smart people with experience and opinions about how things should be done and how you should build a company. I assume(?) that you have managed to avoid the three deadly sins of a scale-up that I wrote about back in 2020, and especially sin #1, not controlling your hiring. So, you have hired the right, smart people who know how to get things done. What is then the problem?

All these smart people come from different organisations where they have learned different ways of building product. Here is the thing: They are all correct and they are all wrong! You simply cannot mix and match things that have worked elsewhere without investing in how they should come together. A high-performing product organisation has evolved and adapted and found its own peculiar combination of how to get things done born out of the people who work there. Just because successful organisation XYZ does it in a certain way, doesn’t mean that it’s also the right way for you. You are probably far smaller in size, has evolved differently, you are in a different industry, have a different product, and you most definitely have a different mix of people with strengths and weaknesses. A smaller organisation is capable of using the individual strengths of its employees because roles and processes don’t have to be that strict. A very common mistake in scale-ups is to pre-maturely introduce structure and processes that prevent people from contributing with all their strengths. We are so afraid of not being able to scale.

When people have strong convictions that there are some objective truths fo how you should work as a product organisation, it is SOOO easy to get stuck in endless discussions. Pick your poison: how a leadership group should operate, how projects should be executed, how you should do testing, how to measure productivity, what a roadmap should look like, what is good agile…

At Cognite, we wasted too much time discussing how the product trio (the designer, product manager, and techlead) was “meant” to work together. As mentioned in the previous article, we looked at Atlassian and Dropbox as good examples, and Marty Cagan was often cited. Although these represent great practices and I love the sparks we see when a team gels and a product trio emerges, setting that as an organisatioal goal requires so much more, and it starts with leaders who know how to go beyond what they have read about and actually act it out. Alastair Simpson from Atlassian and later Dropbox, articulates this in a great way from the viewpoint of the design-profession.

We found it hard to establish a shared understanding of what our top problems were. With all three key functions represented in the Executive Management Team (EMT) and without our CEO as the product leader, we had to establish consensus through deliberations. We eventually reached a shared understandig that our three top problems were: lack of focus on end-to-end customer value, lack of good dependency handling, and problems with shipping bigger end to end functionality. Our actions were to set up a bi-monthly release cadence (features delivered behind feature flags until release) to get everybody to follow the same heartbeat, clear ownership of discovery priorities and planning (with bi-weekly customer-value centric demos), and clear ownership of dependency management and resolution (giving engineering managers a program management mandate).

We did these changes starting with clear expectations to how individual teams should operate and get things done. We knew that we run the risk of over-rotating towards joint planning, and we saw that our changes quickly created incentives to change practices. Among other things, smaller features and customer-promises on team-level started to suffer as the bigger improvements took most of the capacity. We built an organisational muscle to master bigger cross-team planning and execution, and then small adjustments allowed us to also cater for smaller team priorities. These learnings were invaluable and could not have been achieved through discussions on what the ideal is. In fact, we had to do a detour from what we thought was the ideal to build a joint organisational understanding of how to work differently together. For each two-month release we did, we did retros and made changes based on our learnings. What was initially a big planning effort morphed into more and more continuous discovery and planning.

In the next article in this series, I will cover in more detail how to set up the organisation to tackle such continuous change. Meanwhile, remember: don’t introduce structure and processes pre-maturely and without a concrete problem that you want to solve. And secondly, have a bias for action: focus on solving the problems you have here and now, not the problems you think you will have in the future. And if you want further inspiration on how each organisation is different, I can recommend the recent podcast episode of Acquired where Jensen Huang, CEO in Nvidia, is a guest:

The architecture of the company (to me) is a computer with a computing stack, with people managing different parts of the system. Who reports to whom, your title is not related to anywhere you are in the stack. It just happens to be who is the best at running that module on that function on that layer, is in-charge. That person is the pilot in command.

Jensen Huang, CEO Nvidia