OKRs@carwow : 3 months on
Our CTO, David wrote an article a few months back about an organisational change that we planned for the carwow product team here. We’ve recently wrapped up our first quarter under this new system and it’s worth taking a look back at what’s worked, what hasn’t worked and some of the lessons we’ve learned along the way.
looking back: what changed?
As a recap, here’s a quick diagram of how our team was structured before the change:
A pretty standard structure; one that served us well when we were starting out and had a smaller team. but as the number of each ‘group’ grew, we started to explore ways to create smaller, more autonomous teams.
We formed the teams around 3 self-contained sections of our user journey.
User Acquisition
- How can we get visitors to carwow
- How can we turn visitors into signed up users
User Conversion
- How can we convert a signed up user into a user who has successfully purchased a car through carwow
Product Supply
- how can we improve the quality and availability of dealers/cars on the platform
- how can we help increase the efficiency/effectiveness of our account managers
Every team has its own product owner and people with a mix of skills (design, data analysis, data science, software development etc) appropriate to their needs as well as clear knowledge of relevant stakeholders/domain experts in the business tied to the teams objectives.
The idea is that each team is a ‘mini-company’, with the autonomy and skills to make decisions and implement features.
OKRs
At the same time, we were looking at ways to create more focus across the business and a way to keep all teams working towards the same shared direction. We settled on introducing Objectives and Key Results, or OKRs for short (you can find the details in David’s earlier post). The general idea was that James (our CEO), set a few overall company objectives. Each team is then responsible for coming up with their own objectives (and key results) that will contribute towards one or more of the company objectives (not all objectives are relevant to all teams).
where are we now?
So here we are, 3 months on and we’ve completed our first quarter under this new structure. Let’s look back at some of the lessons we’ve learned.
the good
focus
Product focus is one of the key traits we look for when hiring for our product team. We are still a young company, and in a phase where we are trying to define what ‘carwow’ as a product is. So while we’re looking for people who build things right, we also want people that make sure they build the right thing.
This new structure has definitely helped us emphasise this even more. Each product team is now united around a set of shared business objectives, which creates an anchor around which the team goes about its daily work.
This is also tied to our company mantra:
the new structure helped us identify what ‘it’ is. is this going to help contribute to out OKRs? if not, then maybe it’s not a priority right now.
OKRs stop at the team level
I’ve experienced OKRs (or something very similar, under the banner of a different name) earlier in my career at another company. However there they trickled down all the way to a personal level; i.e. every person would identify Objectives and measurable Key Results for their own development for the quarter. They would then be used a measurement of your growth.
I think this is a bad idea, so I’m glad to say we didn’t follow this pattern at carwow.
The biggest value with OKRs in my mind is setting a shared direction and focus for a team. They are not a way to measure performance (personal or otherwise) and they are not linked to rewards/compensation. Personal development and growth is something that is handled outside of the OKR structure.
smaller teams
At carwow, we believe in the power of small, autonomous teams. As more people joined the product team over time the pressure started to build. It was becoming difficult to manage the workload for one team of this size. As the codebase grew it also led to developers becoming spread thin; it became difficult to maintain a strong grip over such a large system.
Breaking down into these smaller teams introduced a number of benefits:
- Each team has a more narrow focus
- Easier to manage workloads/processes for smaller teams
- Set ourselves a clearer path for growing the company and the product team. As we hire more and grow, we’ll identify another area of focus and build a 4th product team.
- Limits scope for the team making it easier for team members to understand their priorities
- Made it a lot clearer for other people in the business to know where to go when they wanted to talk to someone from product
the 50/30/20 rule
It was clear to us from the start that the OKRs would not (and should not) account for 100% of our work. the OKRs represent a very high level direction and highlight the major areas of focus for the team. In addition to that there will always be smaller, equally essential work that needs to be done and there will always be requests from other teams that require product support that we need to accommodate.
We also like to keep 20% of dev time free for technical improvements and personal learning (you can learn more about this on my earlier post “backlog free Fridays”)
With this in mind, the 50/30/20 rule was introduced:
(We’re not particularly happy with the term “ad-hoc” to represent the non-OKR work, but it is what we ended up using)
The basic idea was that expect to spend around 50% of your time on OKR related cards, 30% on “ad-hoc” work and the remaining 20% on technical excellence/dev happiness etc work — and plan the iterations accordingly.
tech lunch
This is something that we already had in place, but became even more important/useful after the split.
In order to help boost communication with developers spread across different teams we have a company-sponsored lunch every Tuesday. We use this as an opportunity to share anything that’s happened over the week from a dev perspective that you feel is useful information for the other developers.
- anything interesting you’ve worked on over the past week
- share any gotchas/questions you’ve had over the past week
- suggestions you may have about how we implement certain features
- etc
the bad
Some of what I wrote above was aspirational, and the reality didn’t always match up. Here are some of the learnings we’ve taken away and are actively trying to address this quarter.
too many OKRs
This seems like the number one mistake that everyone makes, and is one that we were warned about many times. It’s also a mistake that we definitely made, so my warning to anyone out there attempting this for the first time is the same as the warning that was given to us — you’re probably gonna end up with too many OKRs the first time around.
I guess it is kind of understandable, it’s difficult to judge how much a team can achieve in a quarter without any previous experience of evidence to base the decision on. Combine this with the fact that OKRs should be stretch goals and quite ambitious, and you’ve a recipe for over-committal.
I guess we need to accept this and learn from it. Don’t be deterred and give up; instead tell yourself that this was inevitable, and ensure you use your new-found experience and knowledge to have a more appropriate OKR choice for your second attempt.
spread too thin
A direct consequence of the above meant that teams ended up being spread too thin at times. We ended up doing many things shallow instead of doing few things more deeply. This can impact satisfaction, as you’re not able to get to the ‘meatier’ parts of a problem, and also reduces your ability to achieve large gains by solving the heart of some issues.
the 50/30/20 rule
This didn’t exactly work out as planned and the reality of most iterations looked more like so:
We overcommitted on the OKR work, and seeing how that is that the thing that we were most focussed on this had a knock-on effect on the rest. We ended up de-prioritising the ad-hoc work which I’m sure was frustrating for other people.
We tried as much as possible to keep the backlog-free Fridays going (by physically going around the teams and telling them to work on ‘Friday tasks’).
“ad-hoc”
This doesn’t mean we should work on anything that is asked of us. It should still go through the same prioritisation process and we should pick things that will have impact. In hindsight the term ad-hoc was not the best, perhaps non-OKR work would make more sense? Ultimately ad-hoc tasks should still be essential and impactful work, it is not just 30% of time to fill with any old work.
communication overhead
While the smaller teams can help communication within the teams it also introduces an additional communication overhead. It is now also necessary to ensure effective communication across the three product owners and teams to ensure that we’re building a consistent product. It’s something we could have done better, and to help us do just that (and other things) we’ve started hiring for a Product Director to join the team.
Where to from here?
Having this structure isn’t a magic bullet; nothing ever is. Effort and hard work is still required to avoid some of the problems you’re trying to fix. A prime example is communication. While having smaller teams creates an environment that can make communication smoother, it doesn’t happen for free and still requires thought and effort.
With that in mind there are a number of changes that we’re implementing this time around, mostly to address the downsides that I mentioned above.
Overall I think that we’re heading in the right direction, and the philosophy of small, autonomous teams, united around shared objectives and direction is the right way to go. All we need to do is tweak and learn from our mistakes along the journey.
Interested in making an Impact? Join the carwow-team!
Feeling social? Connect with us on Twitter and LinkedIn :-)
