Learning #2: Build Processes and Culture

for Continuous Change

In the previous article in this series, I covered learning #1- Always Be On Your Way. I wrote about how easy it is to get stuck in “how things should be done” instead of focusing on the unique challenges you have here and now. In my response to Brian Chesky’s changes in the AirBnB product organization, I deep dived into one particular “should be done”-trap that I have seen a lot: evolving a product management organization that cannot deliver.

In this article, I will cover the next of the four key learnings the last few years at Cognite: focus on building processes and culture for continuous change. Done correctly, it also helps you prevent traps that are caused by well-meaning “process/function/role X should be done this particular way seen at company Y”. I’m sure you have heard this one before, but what does building an organization resilient to change REALLY mean?!

Follow me on Twitter/X @GregerWedel

You can scale pretty far with strong individuals. But sustainable, competitive advantage is built through creating an organisational muscle that can deliver results that no individuals or small groups can do alone. However, the stability needs of humans and the business needs to adapt the organisation quickly may seem like contradictory needs. The solution is to build an organisation where the stability is in how you change. Let’s unpack this.

Teams as a First Principle

Most great products have a complexity that is higher than what a single individual is capable of alone. You thus need teams to iterate and develop their skills and understanding together. In teams, people can build trust in each other and establish an environment where they can contribute and thrive over time. The team is the arena where humans can satisfy their foundational needs: rewarding work relationships, recognition for work well-done, coaching and feedback leading to growth, autonomy in how to get the work done, and a social benchmark for perceived fairness.

This focus on teams and trust has been an established truth in our industry for a while, but very often I see that it seems to be completely forgotten when the organisation starts building systems of roles, personal development, reward systems, reporting lines, and processes for following-up what the team delivers. Yes, people need focus on their own personal development and yes, they need a manager, and they need to get coached and rewarded on their individual contributions, but this MUST to be in the context of the performance of the team. If the team members report to different managers and the organisation does not have an established shared operating model, they will be get conflicting guidance on how to work in and as a team.

There are two ways you can get high-performing teams:

1. Either you have strong leaders who are accountable for the end-to-end performance of the entire team or
2. you have a strong team-oriented operating model and culture that is understood and shared across the organisation.

Typically, startups are formed around a few strong individuals and team performance forms naturally around these indviduals. It is easy to fall in the trap of not daring to touch such established teams. Equally, it is easy to fall in the trap of thinking that you can introduce multiple functions and reporting lines, and that people can simply be reassigned to new teams. Evolving and changing teams is not only possible, but essential to creating continuous growth, new opportunities, and new energy. You need to understand the social and professional dynamics in each team to make good changes and avoid disintegrated teams or 3-6 months of forming before a new team is fully productive. A strong and shared set of expectations to team work will simplify reconfiguration of teams without the downsides.

Such shared “how to work in teams” expectations should be part of your unified operating model and culture. The jump from strong individuals driving each of their teams to such an operating model is hard. AWS has done it. So has Microsoft, Apple, and Facebook and many other companies that scaled over time and formed their distinct operating model. However, what often happens is that roles, reporting lines, and HR processes are introduced “because we need that when we grow“, but without investing the time to form your own unique (and thus strong) operating model and culture focused on making your way of building great product efficient, fun, and friction-less. For each new manager somebody on a team reports to, one more manager needs to be aligned with the other managers on how work should get done, who is responsible for what, and how the team should work. It is better to have these alignments across the organisation, not within each team.

My personal preference is to build on strong product leaders with full accountability for teams and product, and lean on these strong leaders to evolve the operating model and culture that eventually will be understood and shared across the company. It is not obvious what your operating model should look like: Apple is a company built around strong product leaders. Their operating model is very different from AWS’ or Microsoft’s who rely more on program management. Dropbox and Atlassian again have a different approach with their focus on the triad of product management, enginering, and design. You need to shape your own operating model!

What Good Looks Like

Having high performing teams is one pre-requisite to an adaptive organisation, but not enough. Indeed, if you have strong team leaders, you may struggle with creating a shared “how things are done” into an explicit unified operating model and culture. You risk that each team evolves a different culture and creates its own ways of doing things.The teams become silos and prevent people from moving across teams, reduces organisational effectiveness, and will prevent you from adapting.

One simple method I have used, is to give the organisation a tool for how to evolve a shared understanding of how things should be done. I call it “What Good Looks Like” (WGLL).

Think about WGLL as agile for organisations. In agile teams, you do retros, analyse how things went, and do adjustments continously. The underlying process that happens is that the team establishes an internal alignment of what good looks like for their team and how to do their work. This implicit alignment is hard to make work on an organisational level. The “What Good Looks Like” method makes the process of establishing a baseline of what we believe good looks like explicit. You identify an area where you struggle without a shared understanding and nominate a small group of people to run a “workout” (a structured baselining process that Cognite’s CEO, Girish Rishi, brought with him to Cognite). The workout is a simple process where you nominate a group of people, set clear expectation on what they should cover and establish guardrails for what the expected results should be. Through one or more sessions (but time limited), the workout group creates a written description of What Good Looks Like and actively brings in contributions from the wider organisation to iterate on their conclusions. The workout process creates autonomy and participation, while the guardrails ensure that the results align with organisational goals and other activities on the leadership level.

Once a WGLL is established, you hold retros on a regular basis using your favorite retro approach, but you also introduce two new elements: how are we doing against the WGLL? And have we learned something that tells us to update the WGLL?

Where Do You Need “What Good Looks Like”?

A challenge of the “strong product leaders run teams” approach is that it’s hard to find strong product leaders who know how to run 3-5 teams with everything from sales engagements, customers, user experience to hard technical challenges. This is why companies that scale with strong product leaders (like Apple) invest in developing leaders in their own ranks.

Over time, when you have a strong operating model and culture, you may instead choose to switch to a more distributed model where you rely on functional leaders to split the accountability formerly held by the strong product leaders. This should be based on an evolved and joint understanding of how you split responsibilities and what your operating model is. Roles with the same names are not the same across organisations. If, when, and how to do this switch is a topic in itself. Here I will say: much later than you think. Meanwhile, you need to groom your own leaders.

Note that there is another often used scaling approach that I don't touch here: adopt entirely another organization's operating model and culture. The reason is that I don't believe in it. I believe you build a mediocre organization by trying to copy other companys' ways of success. But of course, learn from and be inspired by what others have done!

Your library of “What Good Looks Like” will form the foundation of your operating model. Of course, WGLL is strongly influenced by your current culture, and they again will influence your culture. This is why your very first WGLL should probably be “how teams are expected to work together”. Where do you set clear expectations and where can the teams decide? A WGLL should be concrete and actionable. For example, if you believe in retros as a tool to evolve teams, describe when teams are expected to run retros, what the important ingrediants are, and how you know that you are doing a good retro. Too often I see missing explicit expectations on how to do code reviews, security like CVE handling and threat modelling, design reviews, customer interviews and feedback, metrics and validation of assumptions, bug and support request handling, peer reviews on larger technical decisions, incident handling, and more. It’s healthy to debate where to set the bar and establish a joint, explicit understanding of how we do things around here.

Do not fall into the trap of describing roles. Focus instead on team activities, outcomes, and practices, as well as examples that illustrate the culture you want. Describe what the team is expected to care about, not who is supposed to do it. You want autonomy in how things are accomplished, but you want to be clear about the expectations to a great team. Atlassian has a great tool for teams to reason around how to get their work done that can be used within the constraints of What Good Looks Like for teams.

Other candidates for What Good Looks Like can be: how to be a good people manager, how to work distributed, how to do discovery with customers and customers’ problems, how to manage tech debt, and how to run operations and incidents. If the organisation already has a shared understanding, then maybe it is as easy as writing it up and making it explicit and a part of on-boarding of new employees. Multi-fauceted challenges that define how people should interact across teams and roles are NOT suitable for WGLL. A WGLL should focus on a specific practice that is acted out independently, but where it’s useful that everybody does things in somewhat similar ways.

Establish trust, stability, and predictability in teams, and create clear and practical expectations to how work is done and the quality expected through What Good Looks Like. Within this foundation you can coach people, set individual goals, and offer continuous learning and career progression without resorting to role definitions. Even better, you have an organisation that knows how to respond and regroup around new challenges without creating uncertainty and undermining trust. You have a stable organisation that knows how to adapt.

Once you have a working operating model, and you have figured out the archetype roles you have in your organization, what they typically do, and the expectations for each, then is the time to not only focus on teams, but also scale through more formalised uses of roles. With high probability, you will end up with flavours of the typical roles you already know. The difference is that the organisation now lives and breethes how things get done through actual practices that weave together across roles, and not through role definitions on paper that are poorly understood.