How We Work in GoustoTech — Part 1 — Team Structure

After joining Gousto as Head of Engineering in September 2017 I’ve spent a lot of time interviewing candidates as we look to scale out our engineering team. One of the most common questions I’m asked is how we structure the team here at Gousto. This is the first in a series of posts looking at ‘how’ (and most importantly ‘why’) we structure our engineering team this way.

At Gousto we actually split our Data Science team from our Software Engineering team, but work amazing closely. I’ve included both in this article so you can see how they fit together. At the current time our combined team is around 30 people but this is likely to grow up to around 50 by the end of 2018. This is the first part of our growth as we continue to scale the company and expect this only to continue into 2019.

Current Structure

When I joined Gousto I inherited a team with a clear structure in place. This structure was great for the current size of the team, but needed to go through some small changes in order to suit a team double the size. Gousto has always taken on-board best practices from other companies — it’s part of our ownership principles to “Be curious, learn and grow”. It should come as no surprise that industry best practices around team structures are normally heavily based on the Spotify model (as it seems to have become known).

At 30 people, the team currently consists of five ‘squads’, each consisting of a multi-disciplinary team with 3–6 engineers and a Product Manager from our Digital Product team. In 2017 these squads were aligned to business KPIs (such as acquisition and retention) but the ownership of our code was often shared across teams. In fact, another structure was in place called COGs (Component Ownership Groups) that owned each component in our platform. Ensuring that squads could own their code was the first area we felt needed changing and one we would look to address in our new structure.

Leadership in the teams was achieved by having a ‘Squad Lead’ who was responsible for delivery, technical excellence and people leadership. Just watching these squad leads they were struggling to juggle all of these roles as they were also expected to be a contributing member of the team to our velocity.

As a food-based company, all of our squads are named after vegetables, you’ll often hear people talking about our Mobile Mushrooms, Reactive Radishes, Coding Carrots, Hacking Haricots, Algorithmic Artichokes and our Problem Solving Potatoes team. In fact this caught on so much that our IT team has now rebranded as the Tooling Truffles.

Target Structure

After spending some time with the team it was clear that some squads had more in common than others. For example, two of our squads predominantly focussed on aspects of our main customer facing website. To support the growth we expected in 2018 we decided to create four ‘tribes’, each of which had a core focus and ownership. Each tribe would consist of multiple squads, each of which could take ownership of certain technical components.

Our four tribes were as follows:

• Web Tribe — responsible for ownership of the main customer facing website including a number of APIs
• Core Tools and Capabilities Tribe — responsible for ownership of a number of core capabilities such as Orders, Deliveries and Content Management. This tribe also owns the integration of our main custom-build website to our off-the-shelf ERP and Warehouse Management System.
• Mobile Tribe — responsible for both our iOS and Android apps.
• Data Science — responsible for developing, supporting and maintaining the algorithms that support our business such as forecasting and box picking.

Alongside these four tribes we also have a small two-person platform squad that is responsible for maintaining our underlying AWS platform. This is not a traditional infrastructure team but a team who develop a fully automated platform using Ansible and CloudFormation. We don’t yet consider this team a tribe, but as it grows we will continue to monitor this.

We decided to keep the Mobile Tribe separate at the moment as the whole tribe are fairly new and are currently working well together. As we continue to grow we will continue to monitor this to ensure it still gives us the best value. The major downside to this current arrangement is that the mobile tribe are often left dependent on other teams for APIs to be developed.

Leadership

The hybrid role of ‘Squad Lead’ in our previous model was really stretching people in too many different directions. I am a firm believer that all teams needs three main aspects of leadership:

• People Leadership — to ensure that team members are happy, supported and challenged to progress further
• Technical Leadership — to ensure that Gousto maintains constant technical excellence. We constantly strive to improve our technology and each other.
• Delivery Leadership — to ensure that we continue to focus on delivery and stakeholder management. This is especially important for a business selling fresh produce and committed to low food waste. Delays to technical projects can lead to problems ordering or wasting our produce.

In order to address this it was decided to create two roles within each tribe to provide all of these three aspects. We also looked to redefine the Squad Lead role to Lead Engineer. The new roles also provided our more senior engineers with a progression path to ensure we can provide growth and development to everyone in the team.

The two new roles we created were:

• Engineering Manager — responsible for overall delivery and people leadership in the tribe. Ensures that stakeholders are well managed and Product Managers have the necessary technical support. Will not directly line manage everyone in the tribe.
• Technical Architect — responsible for overall technical direction of the tribe. Ensuring that the tribe’s vision matches that of the overall GoustoTech team. Not a contributing member of a squad but someone who can support squads with their delivery. With other architects, maintains the long term technical vision of Gousto.

Some people may question the need for an Architect given that agile squads should be totally independent. We have found that an Architect focussed on a longer term vision nicely supports a Lead Engineer who mainly focuses on the shorter term (3–6 sprints) vision for their squad.

Squads

The major change in 2018 is to align our squads to features rather than to high level metrics. An example of this is one of our squads owning the picking recipes feature, rather than a high-level business KPI such as acquisition or retention.

At the end of 2018 our biggest tribe will have three squads. Each squad contains a Lead Engineer and a number of engineers at Junior, Mid and Senior levels. We focus heavily on squads being multidisciplinary. We aim for full-stack engineers, but accept that most people have a speciality and area of interest. Full-stack or t-shaped engineers help teams to focus on delivery as more people can pick up each story for development. This speeds up our delivery time. We don’t currently employ QA members as we feel that promoting a culture of quality across the whole squad is more important at this moment in time.

The Lead Engineer role is now able to be much more focussed around being a strong technical lead within one squad. For some Lead Engineers this may include line management but this is not a requirement for the role. Lead Engineers are keen allies of the Engineering Manager and help them understand and manage our delivery. They also work closely with Technical Architects to ensure that the current short term delivery matches the longer term vision maintained by the Architect.

Code Ownership

In GoustoTech we execute a ‘You build it, you run it’ model. This model heavily dictates how we create ownership for our code.

We assign ownership of all of our components to a squad. Ownership is managed by an internal open-source model. Anyone is able to make changes to code, but this must be reviewed by the squad who own that component. This ensures openness and transparency across everything we develop. It also allows us to focus each squad on not only developing new features, but also supporting and maintaining their code in production.

Guilds

Now that we had the structure of tribes and squads we also looked at how we could promote cross-squad initiatives. Just as with the Spotify model we introduced the idea of Guilds. Guilds are a self-organising group of people with a common interests. We currently have three Guilds, a Front-End Guild, a Back-End Guild and a Mobile Guild, but already see the potential for others. Guilds are very much in their infancy and I’m sure we’ll do much to improve them over the coming months.

We’re Hiring

Given the amount of growth we’re going through this year it should come as no surprise we’re currently hiring. If you like what you’ve read about the team please get in touch workintech@gousto.co.uk (no agencies please). You can view a list of our current open positions on our jobs site.

That’s all for the first part of this series of posts. In the next post I’ll look further at the inner workings of a squad and how our agile process works.

Ben Brown
Head of Engineering

Originally published at techbrunch.gousto.co.uk on February 1, 2018.