Building great teams at Onfido

Published in

Onfido Product and Tech

5 min readJul 20, 2018

Every day, our engineers, product managers, researchers and designers work together to ship great new features — like this one — iterate on our products, and keep everything running smoothly 👨‍🔧

At Onfido, a large part of my job is to help make our engineering division awesome — to put the foundations in place for clever people to do great work (and then get out of their way!). Over the last few years, we’ve thought a lot about how to make our engineering teams successful — a big part of that is how we’re organised.

Teams are cross-functional and mission-driven 🚀

We work in small, inter-disciplinary squads, organised around a specific mission. This way of working reduces communication overhead, fosters team cohesion and promotes shared ownership. Here’s a typical team at Onfido:

A team’s mission might relate to a particular product line, a cross-cutting concern or a broad theme; most importantly, it’s a problem to solve and a goal that the team can aspire to hit. A good mission generates impact and value for our customers or other teams at Onfido.

Loosely coupled, highly cohesive

We design our teams and their missions so that they can ship independently. If teams have few hard dependencies on each other, they don’t need to spend effort aligning with each other — and their features don’t require complex queueing and negotiation to ship.

You can think of it a little bit like object-oriented design: if classes are tightly coupled, then they’re more difficult to change.

Who leads a team?

Each team at Onfido has two different leaders: a product manager and a team lead. We think this partnership model works really well! It’s also a source of creative tension, as we seek to balance market and technical concerns:

the product manager focuses on the “why” — what problem are we trying to solve, and why does it matter? 🤔
Together, the team decide “what” they work on — balancing input from customers, other internal teams and the wider market — with the team’s own vision, data and intuition 📈
a team lead focuses on “how” and “who” — given our product priorities, how do we achieve them with the right pace, rigour and scalability? 🏗 And how do we guide, encourage and develop our engineer’s skills and help them tackle these challenges?

Our engineering leads manage engineers within their teams. We believe that combining people and execution management into one role gives that leader more leverage to actively support their team’s development, wellbeing and growth “on the ground”. That said, it can be a big role, and as we continue to grow, we might need to introduce different types of leadership roles.

We focus on sustainable pace 🏃

Speed is always a competitive advantage for a startup. You don’t need to be first to market — or even second — but how fast you can iterate and make decisions will play a big part in your ultimate success. Our engineering organisation — small, autonomous teams — is geared toward shipping quickly and regularly.

Speed isn’t everything though — and doesn’t come at the expense of building robust, elegant software or our long-term health. Speed means short feedback cycles and quick decision-making — it doesn’t mean cutting corners, doing sloppy work or burning the midnight oil.

Teams are long-lived 🐘

Our teams at Onfido are long-lived — we don’t form a team unless we’re pretty sure it’s going to be around for >9 months. It takes time for a new group to hit their stride — here’s a useful mental model for that process — as team members gel and norm behaviour. We try to move teams to problems: if a team has hit their mission, then that team is much better placed to pick up a new problem, rather than scattering its members to the winds.

A team may even outlive its original members, as we encourage engineers to move between teams regularly — 18 months is a good rule-of-thumb — both to learn new skills, see new challenges, and to introduce fresh energy into a team. The flip-side of long-lived teams is that sometimes, they need to be shaken up a bit 😅

Teams run their own services 🌀

Like Netflix, we expect teams to be “full cycle”: design, build, test and operate the features that they deliver. On the operations side, our Platform team builds, runs and promotes tools to make this possible — such as Kubernetes clusters, scripted infrastructure with Terraform, Jenkins Pipeline and Datadog — and then each team uses those tools to run their services smoothly.

This approach has a few crucial advantages:

Tight, optimisable feedback loop between development and production
Avoids a “throw it over the wall” attitude to operations (this just makes everyone’s life hell)
Increased confidence debugging infrastructure or operational issues in application teams, as well as better overall systems architecture

Taking the on-call pager at Onfido is optional, but we have engineers from across many teams volunteering to take part in our rotations — a subject for another post!

It’s all about trust 🙌

Scaling teams as a company grows requires trust. It’s not possible to micro-manage everyone or control everything — and it’s pretty unlikely you’re making good, quick decisions if you try that approach 😉

Teams move best if they’re autonomous — in control of their priorities and how to deliver on them — but to be truly autonomous, they need to know that they’re trusted to get on with the job. A big part of putting together new teams, with new leaders, is building reciprocal trust and respect, in three directions:

between the team lead and their manager (me, in this case), through weekly 1:1s and being clear about responsibilities and expectations
between the team, other teams at Onfido, and the wider company
and within the team, particularly if they haven’t worked together before

This approach to team organisation has played a huge part in our success so far — it’s seen us through a pivot, new markets, a single service to hundreds, and from 10 engineers to a tech team of 80 — long may it continue!