Swoop Tech Setup

Overview

The setup of Swoop Tech squads has taken inspiration from successful tech companies like Spotify and Wise and the approach they use in delivering their customers value; a concept we’ve taken and evolved to focus on exactly that, effectively delivering value, which means understanding the processes that generate value and organising our squads to focus and own those key areas. This process is in itself a glimpse into the cultural values we hold at Swoop, which is based on a number of core values that we cover in-depth here

Squad

A squad refers to a multi-disciplinary team that is highly motivated, encourages challenges and always solves customer/product challenges. A typical Swoop squad would include:

• Product Manager
• Product Designers
• Engineers
• Product Champion

Each of the squad has its own OKR (Objective Key Result) to solve and these OKRs are well thought and aligned with Swoop’s product strategy. To help make this happen we will serve and support squads that are:

Autonomous

Squads own their decisions. They decide how to evolve Swoop by solid evidence and user research. Squads invite challenges by others in the company on their decisions but eventually they are the final decision makers. Squads pick what they want to work on but everything they work on has to drive their respective OKR.

Independent

Squads make their own way. While there will be times when a squad may need help from another squad to get something done(lobbying), we aim to minimise these. This should also make people extend their knowledge to be successful. Squads do their own testing, releases, support and can always reach out to the devOps team who will be responsible for streamlining the operational overhead for the engineering team.

Operating with weak code ownership

In order for independent squads to minimise dependencies on other squads, we will follow the weak code ownership principle. In this setup, every part of the code is owned by a squad but a squad is allowed to change any part of other squad’s code. In a similar way to how open-source projects work, the owning squad sets the rules, maintains custom decision logs that other squads have to follow to play in their codebase. There are certain coding practices followed within our engineering department and we strive to keep it up to date.

Squad Induction/Coaching

For spinning up any new squad and with new hires, it is essential that each of the members understand the culture and process of the squad journey towards product engineering, product management. The aim is to observe, learn and shape up the coaching program for future squads

• The new squad members for the new squad will be part of any of the existing squads
• The squad lead of the existing squad will act as a squad lead for the new squad.
• Product Managers can be part of multiple squads for defining and solving the product problem.
• The new squad members will take part in all of the action as regular squad members while they stay within the squad. They can start contributing to the product, ranging from small bug fixes to the feature definition contribution.

We believe that the above approach should give members about the squad methodology, culture and process. 

Squad Leader

The squad leader role was evolved as a part of our growth journey. We created this role to champion the technical delivery of the squad, technical leadership, facilitating the squads day-to-day work, breaking down the problems into milestones. It is a natural progression of any engineering lead to be the squad leader, however we carefully take the decision with evidence to place the right people.

Here is our current squad engineering journey and it is expected to evolve as we grow.