What Makes a Good (Tech) Team Great
The Deliveroo Engineering team has come a long way incredibly fast and is growing even faster. Our Analytics team is undergoing similarly explosive growth, so I thought I’d talk to the newest members of that team and share why we’re so proud of our Engineering culture and how it’s grown with us. Here’s what we spoke about.
There are a huge number of things that affect how well a team works. So many of those things are deeply dependent on the number, experience and diversity of its members but as our Engineering team has grown there have been some constant themes which have formed the deep-rooted and often unspoken core of our culture.
The first of these, as I hope with teams of all types, is communication. Often this is the first thing to go when time is tight, but when there’s a need to move fast we’ve found that good communication - ensuring everyone knows how to find out what’s going on - is even more important.
Some of these can be hard to admit, but they’re important:
- There is too much to know for me to know everything. Any team with more than one person doing work achieves enough that no-one has enough hours in a day to keep abreast of all that’s going on.
- I am not always right. Not only do we all make mistakes but our viewpoints are based on our own experiences, which aren’t necessarily those of our customers.
- Others see things differently. A different perspective on a problem often highlights alternative solutions, some might be better.
We work hard to make sure that we can communicate clearly and easily, but without disrupting the time we need to be creative and focused.
Calling a meeting or visiting a colleague’s desk can be very useful, but as the amount of things that need to be communicated increases you eat into people’s working time. Having easily accessible, publicly visible announcements in well-known places means individuals can find what they need asynchronously.
We’ve found that communicating in “public” (company wide) is almost always the best way to do things. If these conversations are well organised you avoid missing people off email recipient lists, and the ubiquitous “Copying in Alex” emails that follow.
We classify “communication” as more than just what we say, it’s also the relevance and discoverability of what we’ve shared for others. Github pull requests are an excellent way to communicate about the style and structure of our code, as the next person to read it will have all the context they need to understand the discussion.
We’ve found Facebook Workplace is great for project announcements, Slack is fantastic for direct requests and, of course, Github excels at code-centric communication.
I believe that context is critical to everything in life. I’m sure there’s a book’s worth of advice on this alone, but we’ve found that it boils down to this:
- Two people will understand each other faster if they have a shared context.
- If there’s a mismatch in shared understanding a group is much more likely to make mistakes and false assumptions.
The only true way to build a shared context is to discuss things, often at length and sometimes without specific direction. Putting time aside to chat to your colleagues - from all over the business - will give you an idea of what’s important to them and how best to work with them.
“Naming things” is one of the two hardest problems in computer science, and naming them well is critical. One word can have many different meanings - some specific to our company - so when you commit words to lasting documentation or code make sure you choose your words carefully.
As engineers we spend a lot of time doing this, even in something as transient as short-lived script variable names. You never know when someone else, or an older you, will need to understand what you were trying to do.
Making code “self” documenting is, for us, frequently the best form of documentation. The further an explanation gets away from the thing it’s documenting the less likely it is to be ‘in-sync’, and the more work the reader has to do to figure out what was meant.
Self-documenting code is incredibly useful, but when it comes to “best practice” we’ve found that a set of separate, community maintained guidelines makes for a great space to both discuss and refer to the approaches we take to common problems.
We also structure our unit tests to demonstrate the specific cases we expect our code to be used in, and the expected outcome. This gives us a reliable shared basis for talking about our code.
We’ve found that talking face to face - especially over video while remote - is important to building foundations, well-written git commits and Pull Requests on Github are worth championing, and the Atlassian suite has no equal for tracking work in progress.
When we were smaller we often found that we didn’t take enough time to congratulate ourselves and each other on jobs well done. In the worst cases, over time, this can lead to becoming unhappy at work - another thing that deserves a book in its own right, and something we want to avoid individually and as a community.
Ensuring we put time aside to celebrate when we do well allow us - both consciously and subconsciously - to do the things that bring success more often and the things which don’t less. We’ve found that the work we feel most proud of is the work that has the fewest bugs, that gets completed the fastest and frequently lands best with our customers. Being proud of what we achieve is critical to our continued success.
We are, more than anywhere else I’ve worked, something of a family. Even the achievements of the most physically distant or least developed parts of our company are celebrated as much as the grand milestones. We feel motivated to work hard because our hard work is useful and is recognised.
On the flip side, admitting that we’ve made mistakes can be hard, but we will always make mistakes. There are two things we try to do when mistakes happen:
- Recognise the direct mistake, figure out why it happened and communicate what we find to any who might make the same mistake.
- Work to understand the wider situation and, if possible, help build safety mechanisms so that others can’t make the same mistake again.
It’s very difficult to feel pride without a sense of responsibility. They go hand in hand, but there are more benefits to fostering a sense of responsibility in everyone, from the battle-hardened team veteran, to the first-week new starter.
The more that responsibility clusters to only some parts of a community, the more that group becomes a bottleneck for decisions. In a fast-moving business the ability to make quick, informed decisions autonomously is critical, so allowing responsibility to spread wide lets us keep our agility, even as we grow.
Responsibility is often confused with ownership. A sense of ownership of a codebase, a project or process is what can lead to a bottleneck - all decisions about that thing going through one person. Responsibility is more than that; it’s talking to a different team and writing a pull request to improve a codebase when there’s a spare hour, it’s suggesting changes to process to team leadership when we recognise inefficiencies, it’s looking into the numbers & discussing when we have a gut feeling that something we’re working on may not be the most leveraged use of our time.
The hardest part of personal responsibility is being able to say “No”; to a good idea - because there are others that are better for today; to a request for help - because you’re already helping elsewhere. Saying “No” is important and important to get right.
Our company will always grow so that our teams are just under-staffed (we are passionate people, we stretch ourselves!) and because of this we have to be comfortable saying “No”. When we do, the most important thing about doing this is making sure that we explain why. A question that gets a “No” today will be asked again tomorrow, a question that gets a deeper answer will have that explanation propagated to others and will help build the shared context we need to communicate well.
In general, at Deliveroo, we like to give people the responsibility and freedom to make mistakes, but the support and tooling to be warned when something might go wrong (rather than create gates or checkpoints to do our jobs).
This allows us to act independently and very quickly to react to the changing needs of our customers, but it’s risky. We need to ensure we are communicating well, that we are learning from the successes and mistakes of our colleagues and that we are making decisions based in fact wherever possible.
Metrics allow us to carefully choose which aspects of the business can be improved, then tailor what we build to suit that. How we use and refer to metrics is of critical importance to how we plan the building of our product.
The way we communicate our metrics, plans and goals, the context behind each of these, the pride we take in their upward trends, and the responsibility we assume in their continued improvement are the reason why Deliveroo continues to excel.
About JP Hastings-Spital
I’m an incurable geek; always building things (often in code, sometimes in hackspaces, or both) and trying to make time for a bit of Lindy Hop.
If you’re hacking about with Nerves, pondering the future of the web or thinking of unusual projects with postcards then you should get in touch!