While autonomy fuels your startup, the perfect balance of alignment and autonomy will define your impact as a scaleup (Spotify has famously shared their view on this). However, getting this balance right without being killed by process or chaos is really hard. At Kolonial.no we have doubled down on a small set of solutions for alignment, and in this post I’ll deep dive into how we align on strategy through OKRs and execution through Quip.
First; an introduction
Kolonial.no has been one of the fastest growing tech startups in the Nordics since we started to rethink online groceries in Norway back in 2013. In the early startup days of Kolonial.no alignment wasn’t really an issue. Like in any other startup, the small founding team sat together, ate together and fought all battles together. Unless the founding team is distributed or dysfunctional as a team, alignment just happens. Everybody knows where they’re heading and what’s being done.
With scale comes complexity, and in our case, an enormous complexity. Not just in our product offering, but in people and teams needed to handle thousands of orders with perishable goods per day — while building for the future at the same time. As we scale, impact towards our vision is a result of alignment across all kinds of teams. Not just within product and tech, but also across marketing, category management, warehouse logistics, distribution logistics and more.
Joining as the product lead for Kolonial.no in the start of 2018 the alignment issues were both clear and near to me. During my first month I met with about 45+ employees all over the company to learn what was working well, and not so well. It was clear that 4+ years with rapid growth and autonomous execution had started to create silos. Autonomy worked well. Alignment not so much, which is a recipe for a chaotic culture. In particular, we needed to align better on:
- Where we are heading as a company or team (strategy and focus)
- What we think, plan, do and learn as we move fast (execution)
One of the key responsibilities for product leads is to create alignment, autonomy and an optimal combination of those two at all time, so it felt important for me to address the alignment issue first thing. Having been through a wide range of literature and tried a bunch of processes, frameworks and tools first hand, I knew there were tons of pitfalls, but we had to try.
It was particularly important for us to avoid killing autonomy in our quest for alignment. Hence, we favoured a step-by-step approach with a minimal set of new tools and processes; starting in some parts of the company and organically and patiently scaling to everyone. Let’s dive into two of the critical alignment issues we tackled.
Where we are heading (strategy and focus)
In the early days of Kolonial.no the mission was clear to everyone — namely to revolutionise the grocery industry in Norway. The team’s plan was to create a great online shopping experience for groceries, with pick up points for delivery. The first of these assumptions was correct, but the second turned out not to be. Instead, home delivery turned out to be critical to achieve product/market fit. When that offering was nailed, scale and growth in users was the next big common challenge.
Whenever the team had to refocus and push towards new “must win battles”, aligning the team was simply done over lunch or in short weekly meetings. However, 4–5 years down the line, with 400 employees and close to a billion NOK annual run rate in revenue, aligning teams on where to go and what to focus on as a company is a very different game.
All of a sudden a more systematic approach to strategy, goals and focus became crucial to realise all the potential as a team of many teams. However, as any entrepreneurial culture, we feared being slowed down by processes or less ambitious goals.
We landed on OKRs (read more about OKRs here or here). While there are numerous ways to articulate goals and focus in a company, we landed on Objectives and Key Results (OKRs) — like most other tech companies. Hoshin Planning could also be natural for a lean-focused operational company like ours, or we could invent our own like Spotify’s Rhythm. However, as we like to use well-proven solutions if we can, we didn’t see a need to think about this too much and instead start by testing out something we know works and iterate from there. We’re very particular about how we use our innovation tokens as Dan McKinley talks about — and not just in choice of technology.
Having an extremely wide and deep set of challenges to solve and opportunities ahead of us, one of the key things for us to nail is focus. Not just within one team, but across many teams. Customer focus, business acumen, operational excellence and tech & data magic all are key ingredients in almost every change and innovation we embark on. Hence, a tool to align on common focus is key.
Secondly, we’re aiming to be the world’s best at what we do. Nothing less. Since we don’t know up front how to achieve it, we have to iterate to get there. Hence, stretch goals in combination with a bias for outcome over output is what matter for us.
OKRs are great at providing focus while preserving stretch & agility. And here is how we have ended up implementing it:
- We set annual OKRs on a company level to align everyone on what matters in the coming year; then each team sets their own OKRs every quarter to signal what they focus on, stretch towards and aim to achieve.
- One of our company values is “team of teams”, so we do not care much for individual OKRs. Impact is a team effort.
- All OKRs are open and transparent across the company. While we don’t standardise how each team creates their OKRs, we have clear expectations on how they are shared and reviewed, in a transparent manner.
- We introduced OKRs by setting annual OKRs for our entire company last year. Then we took an iterative approach to rolling it out to each team — team by team. Allowing each team to iterate on how to do it well. One year later, we’re still iterating, learning and adapting. This is not a quick fix.
What we think, plan, do and learn as we execute
Alignment on where we are heading (goals and focus through OKRs) is a good starting point, but it is the execution that leads to impact (or not). In particular, it’s crucial for us to align across people, functions and teams on problem analysis, solution planning, testing, roll out and learning on improvement efforts, but we don’t want such alignment work to compromise too much on execution speed.
Within a well-functioning team, alignment during execution is normally not a problem. It’s typically solved by team meetings, over lunch, a Slack-channel, a whiteboard or a Trello board, pull requests on GitHub, or some joint collaborative documents in G Suite or similar.
However, a team among many teams in a larger scaleup can never reach its full potential without collaboration with other teams. Like it or not, the team will be affected by the decisions and actions of other teams, and could do better by getting insight into what other teams think, plan, do and learn. Ideas, plans, discussion notes, analysis, learning, decisions, designs, code etc. should float freely. You want everyone in all teams to become aware of what’s relevant for them, but you don’t want more meetings, Slack channels or Wikis. The challenge then is to hit the right balance of information sharing and discussion in and between teams vs. autonomous execution in isolation.
To solve this we want ambient awareness of what’s happening as we move fast forward. Cyborg Anthropology defines ambient awareness well:
“Ambient awareness is a way of describing the idea of being “ambiently aware” of another’s actions, thoughts and experiences without having to be near them physically, and without specifically requesting such information.”
Being a product manager tooled with team and stakeholder meetings, collaborative documents in G-Suite, Slack, Trello or similar, I’ve been jealous of software engineers and their GitHub for a long period of time. GitHub lets everyone build directly on top of everyone’s effort without meeting up or spending a lot of time on figuring out what has changed.
Then I found Quip.
Quip is our second solution crucial for alignment as we scale up. Just like there are alternatives to OKRs, there are of course alternatives to Quip (like Notion.so). However, more than choosing the perfect tool, we believe that choosing one tool and being great at using it at scale is what matters most.
Quip is a tool for document collaboration with one truly unique feature that sets it apart from other collaboration tools (maybe except Notion.so). Where Trello has built their product around tasks, Google has built G-Suite around fully formatted documents, slides or spreadsheets and Slack has built their platform around ephemeral messages; Quip has built its entire system around the updates / changelog of very simple, yet powerful documents.
This means that for every document created, modified or commented on, the entire organisation sees a stream of what’s new. Just like how Slack brought IRC into the hands of non-engineers, Quip brings some of the power of GitHub to everyone. Like GitHub empowers developers to commit code changes and automagically stay updated on what others do, Quip makes it seamless for anyone in the organisation to see the changes in any document.
We use Quip (with some homemade templates) to write up, share and discuss OKRs, meeting notes, decisions, problem understanding, analysis, plans, to do lists, guidelines, experiment plans, learning, and so much more. And when we do, all of these thoughts, plans, action points and learnings are spread transparently throughout the organisation — change by change, and in an asynchronous and distributed manner.
While we also have meetings, all hands, workshops, casual hangout by the coffee machine, video calls, Slack discussions and more; the bite-sized updates from collaborative documents in Quip are fundamental to ambient awareness across our teams as we execute with high velocity.
Caveat: The tools are not what matters the most
It would be great if the solution to all our alignment problems was just some methodologies or tools like OKRs and Quip. That’s far from the truth. Having spent 10+ years in product management I’ve tried most processes, frameworks and tools; and there is no perfect selection.
Instead, the answer lies in your culture, and how the entire organisation is capable of testing, choosing, implementing, improving and rethinking shared solutions for alignment. This is really the number one success factor. Not your specific process or tool of choice. That’s short term happiness. I’m sure we will change from OKRs, Quip, or one of our other current solutions for alignment one day in Kolonial.no. That’s not the question. The question is how we do it.
When adding a solution for alignment (or any other change) I find it helpful to take a page from product development. Namely; nail before you scale. Try the solution on some early adopters in your company and evaluate for wanted effect. Once you feel confident it’s the solution you look for; scale it.
When scaling the solution to each corner of your company, show, don’t tell. Allow for adoption to happen properly. Don’t assume on-boarding is easy. Instead, help each new team to get on board. And make sure everyone gets on board with your solution. Once everyone is on board, remove all traces of old solutions so you don’t end up with “alignment debt”.
Finally, continuously improve how good you are at the selected solutions, e.g. through retrospectives, coaching and sharing pro-tips. And once you feel it’s no longer working or needed, rethink it. Never launch and leave.
To make all teams in our scaleup aligned, as ambiently aware as possible and with minimal loss of autonomy, we (among other things):
- Use transparent OKRs to define and communicate where we’re heading and what’s in (and out of) focus
- Bring ideas, analyses, plans, actions and learning during execution into the consciousness of everyone through Quip
This solves two major alignment problems for us. We have also put in place solutions to align on employee engagement (Peakon), as well as how to carry out well-established processes and routines in an efficient manner (standard operating procedures), but this has to be the topic of another post.
Finally — we have a saying in Kolonial.no: “Happy, but not satisfied”. This means that while we’re happy with our current choices, we continuously want to improve and are open to rethink this completely if needed. If you happen to have comments or ideas on improvement or alternatives, please share!
Notice: Neither I nor Kolonial.no are paid by Quip (or Peakon) for name dropping them here. There are many good alternatives, I’m sure, but I felt like providing the real examples we currently use.