Introducing Flow — our scalable way of working with development in Oda
In this series of posts, we will introduce Flow — the latest iteration of our system for working in and across development teams to create value. We will also share how we have arrived at this version, and how we work to improve it going forward. We’re not just using Flow for product development, but for all development efforts such as logistics, growth, data, insights and infrastructure.
Introducing Flow
Building the world’s most effective retail system is not done in one go. We have an end-to-end approach to our customer experience and value chain, which we combine with continuous improvement, and collectively understanding and solving problems with all disciplines and perspectives present from day one.
Having defined, tested and improved our way of working with development over a couple of years, we finally felt we were ready to give it its own name as we enter 2021. We named it Flow, and it is a system alternating between focus and flexibility to provide rapid flow towards our goals.
Why Flow?
It’s what we create for our customers. As a noun, flow means “a steady, continuous stream or supply of something”. In psychology, flow state is “the mental state in which a person performing some activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity“. Finally, flow is a well known principle in lean manufacturing and product development, where flow is how work progresses through a system — with “good” flow moving steadily and predictably. All things we wish to achieve in our way of developing products, processes and technologies.
Flow is built upon the following beliefs and goals:
- Rooted in our culture: We are ambitious about the value we provide customers, always stretching beyond what is possible. We do this while caring genuinely about people — both customers and employees. We create effective processes, and the way we develop solutions is no exception, it enables us to move firmly towards our goals while adhering to our company behaviors.
- A tailored approach: Instead of using one popular methodology, we borrow elements with pride. We tailor our way of working to make sure we have something that fits our company, and to avoid jargon-war or confusion.
- Autonomous, but aligned: No challenge, context or team is the same. Hence, teams need autonomy to develop their solutions and “inner workings”. However, standardization of teams “outer workings” provides alignment between them across the company which unlocks the potential of joint efforts.
- Guided, not dictated: Autonomy is great, but we should still learn from each others experiences. Hence, we share guidelines and best practices across teams to have a good starting point, for example for understanding and defining a problem, effectively building and operating systems and for aligning on solutions.
- Open and inclusive: We believe in creating a culture where (a) people feel safe to involve themselves within and across teams, and where (b) transparency, sharing and great communication is second nature. We avoid over-detailed processes and strong control to align everything.
- Happy, not satisfied: Our way of working is, as everything else, subject to continuous improvement. Hence, it’s revised, adapted and improved regularly. Flow lives in collaborative documents, not a printed book.
The structure of Flow
Flow is a system for work. It includes standards each team must follow and optional guidelines each team can use when applicable. We set standards for how teams communicate important information and collaborate with other teams across the organization to achieve proper alignment. To avoid that every team has to reinvent the wheel on how to work, we provide optional guidelines each team can choose to adapt as they see fit.
Flow consists of two phases — Focus and Flex — that complement each other to create a sustainable and effective work rhythm. By separating Flow into two different phases we aim to strike the right balance between time spent on working towards our strategic goals (Focus) and time spent doing everything else (Flex).
Flow standards for all teams
Our standard Flow for all teams is illustrated below, and being a Norwegian-born company, we of course think of it as a mountain hike (as illustrated in grey below).
Ok, let’s play out the mountain hike analogy. First you agree on what top to climb (OKRs), find your route and plan your ascent. This is sometimes a bit fuzzy and needs flexibility in discussions and alignment with your surroundings. Then you start with focused rapid climbing. That’s our push towards our strategic goals. Our teams spend 6 weeks in this state of mind — researching, building, testing, shipping. Then we loosen up and flex again, just like you would do on a hike. You fix what needs to be fixed, find new clothes, chat with people, eat your chocolate, and agree on the next path upwards. Then you push towards your goals again.
For us, having such a predictable Flow alternating between Flex and Focus enables us to reach bigger goals faster and more consistently over time. It makes it easy for teams to know when and how they can more meaningfully collaborate and align with each other vs. remain focused on bigger achievements. Or as we like to say; we collectively go “out of our trenches to look around, align and recharge, before collectively diving back in”.
More concretely, to create great flow per team and collectively, we ask all teams to:
- 🎯 OKRs: Set Objectives & Key Results to define, align, commit, and communicate what the team aims to achieve every 4 month
- 💡 Focus: Focus 6 weeks on what’s strategically important to the team & company
- 💆♀️ Flex: Flex 2–3 weeks to resolve everything else that matters
- 🤝 Flow Meetings: Regularly meet key people outside the team to inform, discuss and/or decide
- 📬 Flow Updates: Share bi-weekly updates to keep people in the loop of plans, progress and problems
- 🎉 Flow Highlights: Share highlights (when relevant) of achievements, results or learnings with the company
- 👏 Flow Demos: Give short and low-key presentations of the work (and reflections) done in the Focus weeks (like this and this)
Finally, this has led us to have this shared calendar for 2021 across all teams:
Related standards for all teams
In addition to the Flow standards, we expect all cross-functional teams to:
- 🤼 Team setup: Define the team setup by articulating the teams mission, scope, members, stakeholders, etc
- ☑️ Task Force: Set up a task force (project mandate) for time-bound projects involving people across multiple teams
- 🧑🍳 Suggested recipe for product development during focus weeks: Work systematically with product development by starting with a general recipe and adapting it to fit the team’s needs
- 📝 Digital collaboration: Follow best practices for digital collaboration for all our teams
- 🚨 Resolving critical issues: Follow expectations and guidelines for how we resolve critical issues continuously
So, that’s Flow — our way of working for 2021. We will follow up this post with further posts diving into the various parts of Flow, like Focus and Flex weeks, our communication standards (meetings, updates etc.), and our suggested recipe for product development during focus weeks.
Ok, so how did we arrive at Flow?
In the last years we’ve been on a similar journey as many other scale-ups. We’ve gone from a founding team of 10 obsessed with developing our product and value chain (and they all still work here), to a bigger company with hundreds of people, a complex and massive operation, and close to 2 BNOK (192 MEURO) in annual revenue. Instead of giving you the entire journey, I’ll zoom in on our last 3 years to give you some flavor on the iterations leading up to Flow.
2018: Creating teams and aligning them on where we are heading
Entering 2018 we had hundreds of people in the fulfillment and delivery operation, but the “development side” consisted of 14 people in tech, 1 in product/UX and a handful of lean experts in the operation. They designed, built and improved everything. While they all were customer focused, had a systematic approach to solving problems, and worked cross-functionally and autonomously by default; we started to see a need to create a clearer team structure and better alignment in and across teams.
I wrote a bit about how we tackled alignment at that time here, but in 2018 we didn’t standardize a lot more in terms of how we worked across teams. The most important was to (a) get autonomous teams in place, (b) align on where we were heading using OKRs, (c) and improve day-to-day documentation and communication. Having this as the minimal shared framework for development, we had something to improve in the years to come.
2019: Controlled scaling, and learning what breaks when scaling up
With clearly defined team structures, complete cross-functional teams (e.g. introducing UX design, Data & insight and Product management into each team), and a company-wide way of working to set, align and communicate goals with OKRs, we used 2019 to scale up from 3 to 5 teams; growing from ca 20 to ca 40 across Product & Tech.
During this year, our way of working toolbox had evolved into:
- Clearly defined cross-functional teams with mission, responsibility, stakeholders, metrics etc.
- OKRs to set and align on goals — annually for company and per quarter on team level
- Two product reviews per quarter with key stakeholders for teams to discuss and decide on OKRs, team needs ++
- Short biweekly update written by each team and shared widely in the company
- Wide-scale use of Quip for documenting ideas, plans, learning etc., and to create “ambient awareness”, Github for code and Slack for ephemeral communication
We fine-tuned our way of working, but didn’t do major revisions. More importantly, we used the year to gain a lot of learning on how we could and should improve as we moved into 2020 as a much bigger team.
2020: Introducing a shared rhythm and expectations beyond goal-setting (while rapidly scaling)
While each team still had the need to find and solve problems in very different ways depending on their mission and goals, we started to experience some common challenges across teams as we scaled in 2019.
We typically want to wait with standardizing way of working across teams until we clearly see shared problems and a need for it, but as we entered 2020 — we saw common issues that needed to be resolved. For example:
- Going from OKRs to enablers was unclear, and teams struggled to find the best way to do this
- We had collaboration overhead when aligning on problem understanding and solutions across teams — as we often have to work with people outside the team to truly understand what problem to solve or to solve it well
- We saw that collaboration dependencies, increasing scope creep, unclear expectations and interruption overload led to a lot of work in progress, and we didn’t manage to ship value and learn as fast as we wanted
- It was unclear how and when decisions where made
Based upon these learnings, and with new inspiration from Basecamp’s Shape Up, we found two things we wanted to steal and introduce across teams: 1) a shared rhythm for how we not just set OKRs, but also for how we split our calendar into 6 weeks focused shaping/build-cycles followed by what we called 2–3 “fix up weeks”, and 2) improved guidelines for how to better articulate & commit to what opportunity or problem you want to explore or shape, and what solution you want to build (as written about here). Beyond this, we didn’t really take a lot more from Shape Up.
Furthermore, we factored in the learning on setting OKRs and reduced that to three times per year on team-level to better match the calendar-year and reduce planning overhead.
As we entered 2020, our system for how we worked with development consisted of
- Clearly defining cross-functional teams with mission, responsibility, stakeholders, metrics etc.
- Improved OKR cadence to set and align on goals — annually for company and per 4 month on team level (Feb — May, Jun — Sep, Oct — Jan)
- A new rhythm where each 4 month (e.g. Feb — May) was broken down into a shared calendar across all teams with 6 weeks build/shape, 2–3 weeks fix up, 6 weeks build/shape and 2–3 weeks fix up (in July we had 4 weeks fix up)
- New guidelines for how to define / shape what you want to build — before deciding on building it
- Two product reviews per quarter with key stakeholders for teams to discuss and decide on OKRs, team needs ++
- Short biweekly update written by each team and shared widely in the company
- A new demo at the end of each build-cycle
- Wide-scale use of Quip and added Miro for documenting ideas, plans, learning +++, and to create “ambient awareness”, and kept Github for code and Slack for ephemeral communication
Improving parts of and adding new elements to our shared way of working across all Product & Tech teams was far from the only thing we did in 2020. We handled record growth in customers, operational capacity, and team size. Here shown in a recent talk by one of our UX leads:
2020 brought a lot of new learning on how we should work effectively together across a 2–3x larger team, which we used to prepare ourselves for 2021 — and what we expect to be the most exciting year ever in our history. A key part of this preparation, as always, was to evaluate how we work and improve it: an effort that led up to us introducing Flow for 2021.
Future improvements
Equipped with Flow as our upgraded way of working we embark on what we find to be an extremely interesting year for us. In addition to everything we aim to accomplish and create of value, we will also expand our cross-functional teams to cover Product, Tech, Growth and Operations / Logistics which impose new needs and learning. In particular we expect to learn a lot about how to improve Flow in a growth and logistics setting. Maybe we’ll share stories about this experience later.
We know there is always a better way, so our team of volunteers across the organization will systematically capture feedback and improve Flow as we move forward. Then, as usual, we will do a proper review of Flow this fall and improve it once more ahead of 2022.
If you have comments or questions to our way of working with development, feel free to reach out! We are hiring (see vacancies), also in product management, in case you find us exciting and want to take part in future iterations!
