Discovery Week - a collaborative and engaging way to prioritise team’s OKRs
What is a Discovery Week here at Gousto?
In Data Engineering at Gousto, we introduced Discovery Week as a new approach to involve an entire team in the planning activities. The idea was to have a discovery phase where together we discover our Objectives and Key Results (OKR). Essentially prioritising what we’ll be working on for the next 3 months.
With so many candidates on our roadmap, we felt like it was essential to take the time early to decide what we’ll take into our workload. In that week we wanted to:
- Collaboratively review our OKRs
- Pick the most viable project candidates, reject the low value / high effort work
- Discover / research each project, map out the work, possibly create a demo
- Share the results and recommendations
Think of it as a week-long hackathon-style planning session (engineers love building things — it would be a waste of their time to just architect solutions).
Background
Our engineers wanted to be more involved in planning and prioritisation of our work. This came up during our health check surveys. People wanted more context on upcoming work and to input in terms of what type of project they get assigned to. To accommodate that, our Product Manager came up with an idea to plan our work together, with a “Discovery Week”. This was going to be a week spent on analysing and researching potential candidates to put forward recommendations to the final review.
The idea was that engineers assign themselves to the projects they are interested in, then share their expertise on it early in the planning process. Having an entire engineering team involved in making decisions could bring a lot of valuable feedback, comments, but how can we do it so that we don’t spend too much time on constant iterations, endless feedback loops etc.?
How, Format, Ways of working
We started with a kick off meeting where everyone was able to assign themselves to one of the three Main Objectives (working groups). That was the exciting part where you could either pick an area where you feel comfortable (something you’ve worked on before), or choose something completely different to get out of your comfort zone and get to know a different area of the wider team.
As part of the Foundations tribe at Gousto we had three main OKRs and below you can see what we’ve decided to do in each.
System observability & reliability:
- Regression testing
- Monitoring and reporting — for Spark metrics will most likely be Cloudwatch + Grafana
Trust in our data products:
- Deprecating unused dbt models, migration work
- Building Snowplow Data Models for some of our tribes
- Dbt modelling training ran by our Analytics Engineers for our BI & Analysts
Collaboration & Self Serve on our data products:
- Moving our Redshift database over to Datalake so that our analysts can query it using Databricks SQL
- Enabling search capabilities using Amundsen
- Leveraging MLOps for our Data Science teams
In each there were candidates for Data Engineers & Analytics Engineers so that they can work together.
Rules & Expectations, Desired Outcomes
After assigning ourselves to the objectives we had to put some rules & expectations in place to make sure we were all doing the relevant work.
- measurable outcomes addressing our key areas such us: self-serve levels, NPS score, limiting data issues, usage levels, collaboration and data accessibility.
- understand value, feasibility, usability as early as possible.
Our Desired outcome at the end of the week was to have a plan on how to tackle each objective and suggest project candidates / solutions. Many teams chose Miro Board (at Gousto we love Miro!), Google Slides, Wiki Page, One-Pager doc as their tool to present the findings.
By the end of day 1–2 you should have prioritised your list of candidates to the ones that will make the difference and contribute towards the OKRs the most. The remaining days (3–4–5) should be around determining feasibility of the solutions and potentially building a rough demo to prove it will work for us. Lead Engineers were there to ensure that any blockers get removed and we stay efficient.
Admin and Planning
To get the most out of the planned discovery days:
- Plan and communicate with the rest of the business ahead of time, so you can clear everyone’s calendars to allow them to focus
- Change your slack status to do not disturb, responses may be delayed. Same for email
- Schedule a morning kick off meeting, as well as regular check-ins and team-wide design sessions where needed
In order to make sure people were all comfortable in their groups and able to freely contribute ideas as part of the kick off we recommend organising some team activities or games (team knowledge quiz or similar).
Final Results
One of the teams presented a working demo of a search tool Amundsen, another created a fairly comprehensive Miro board with an architecture design. Third team explored monitoring tools such as Data Dog and others, coming back with one final candidate meeting our criterias.
A Week later we all met and signed off consolidated OKRs, discussed final teams structure and considered carry over work from the previous quarter. We also used this opportunity to change the schedule of our rituals like standup, frequency of retrospective meetings and others.
Learnings for the next time
Even though the feedback was overwhelmingly positive, not everything was gold, here are the things we’ve learned for our next Discovery Week:
- Some people felt like we didn’t need all 5 days. For our second discovery week in Q3 we’ll most likely compress it to 3.
- Don’t split into groups too early and make sure there is no overlap in work between the teams.
- Make sure you have enough time scheduled at the end of the Week to share the results. It’s everyone’s time to shine! You could also vote on the best presentation in areas: (i) presentation skills (ii) due diligence done on the topic (iii) technical assessment, architecture (iv) comprehensiveness.
- Don’t try to achieve too much during one week. Discount the candidates that bring minimal value (or spend little time on it), decide early on what’s the big win and focus there.
- Attempt mixing the skills of team members (analytical with engineering etc.) Try and create a holistic hackathon-like cross-functional team.
Summary
Together, we ended up with a list of projects that will contribute towards our main objectives. Thanks to a greater ownership our team of Engineers felt engaged, motivated and heard. Prioritising work is a task that used to be handled by the Lead Engineers. Instead, with a strong upfront contribution of our engineers, we have managed to get a better picture of what’s ahead of us. We also listen to the individual problems and end up with a much better scoped plan.
One could argue that both approaches get you to the same place, but at Gousto we believe that the journey is as important as the destination. In the end having a motivated and engaged team is one of our priorities, as it’s also important to embrace everyone’s working style, this Discovery Week has proven to give the best of both worlds.
