One of the best engineers I know once told me “looking after software engineers is like a tending a bee-hive. Give them the right environment and they will make lots of honey”. This has stuck with me ever since. In the past 12 months we have replaced a mostly contract engineering team at ONZO with a fully permanent group of engineers. We are moving from start-up to scale-up, which means that quality and speed of execution are both really important for us. In turn this means setting a high bar of talent and experience as we add people to the team. This article is a distillation of my decade’s experience in hiring plus what we’ve learnt as a team at ONZO.

Find The Right People

It goes without saying that without the right engineers you don’t have a team (and the wrong engineers can be worse than no team). So if you’re starting from zero, how do you go about building a new team?

Identify the right skills — Our platform is primarily built around AWS, Kubernetes, Scala and Python (see our StackShare page for more details). This means looking for three distinct skill-sets around DevOps, Scala and Python in order to be able to build, release and care for new features. As we’ve started talking with candidates, we care much more about solid language fundamentals and good practices than framework experience. You can learn a new framework or technology fairly quickly but core skills take much longer to accrue.

— Our platform is primarily built around AWS, Kubernetes, Scala and Python (see our StackShare page for more details). This means looking for three distinct skill-sets around DevOps, Scala and Python in order to be able to build, release and care for new features. As we’ve started talking with candidates, we care much more about solid language fundamentals and good practices than framework experience. You can learn a new framework or technology fairly quickly but core skills take much longer to accrue. Know your budget & market — We always prefer to invest in permanent team members which has led to creating a team of Scala, Python and DevOps engineers. The ratio of team members is determined by the skill sets we identified above and the capacity we need in each part of our stack. The markets we operate in are really competitive for each of these skillsets, so we’ve also needed to give some thought as to how we attract the right talent!

— We always prefer to invest in permanent team members which has led to creating a team of Scala, Python and DevOps engineers. The ratio of team members is determined by the skill sets we identified above and the capacity we need in each part of our stack. The markets we operate in are really competitive for each of these skillsets, so we’ve also needed to give some thought as to how we attract the right talent! Talent vs experience — To quote John Wooden “I’d rather have a lot of talent and a little experience than a lot of experience and a little talent”. We’re always looking for talented individuals… If you combine this with the ability to learn quickly from mistakes then you’re on to a winner! . As mentioned above we have spent the past year looking for people that are both talented and have accrued experience. At this stage in ONZO’s development we are asking to have our cake and eat it.

— To quote John Wooden “I’d rather have a lot of talent and a little experience than a lot of experience and a little talent”. We’re always looking for talented individuals… If you combine this with the ability to learn quickly from mistakes then you’re on to a winner! . As mentioned above we have spent the past year looking for people that are both talented and have accrued experience. At this stage in ONZO’s development we are asking to have our cake and eat it. How do you spot talent? — I’ve been asked this before and I don’t have an empirical answer unfortunately. The first step is to be more promiscuous with the number of candidates you talk to. If I see a hint that someone is a star in their CV I’d like a conversation. This can come in a number of forms.

— I’ve been asked this before and I don’t have an empirical answer unfortunately. The first step is to be more promiscuous with the number of candidates you talk to. If I see a hint that someone is a star in their CV I’d like a conversation. This can come in a number of forms. Has the candidate progressed quickly?

Do their achievements push outside the boundaries of their job role?

Have they mastered complex technologies?

Have they worked in the engineering function of a company you particularly respect?

Once you start talking it’s much easier to get a sense of someone’s communication style and thought processes. Hindsight being a wonderful thing, the most talented individuals we’ve found are able to work from first principles to solving intricate problems really quite quickly. They also tend to really enjoy their work. One reason I don’t have an empirical answer to this is that I rely partly on evidence and partly on instinct during the early stages of getting to know someone.

By considering what you want in terms of team composition, budget, hiring market and talent / experience you’re ready to get out there and hiring! Once you start there are four key stages to get the right people into the team.

Job Advert — This is your dating profile and its entire purpose in life is to get you a first date! It needs to get across how funny, exciting and good looking you are so that people will want to send you a message and have a chat. Parallels drawn… This needs to get across why you enjoy working for the company you’re in, what the product’s like and what the technology is like. Where do you want to go in the future? Also, don’t lie… Or those first few dates will not be very successful. 45 minute Phone Screen — During this we give a brief background to the company and where technology fits the bigger picture. Personally, I also try to convey what excites me about working for ONZO. This is a two-sided process… It’s about a candidate finding the right role and company for them as much as it is us finding the right candidate. I also try and get across where ONZO is trying to improve. This gives people a sense of where they can add value immediately. We then talk through the candidates background, go through some lightweight screening questions and give the candidate chance to ask questions of us (once again, this is a two way process). Face to Face Interview — We start this off by getting straight into a more detailed technical conversation based on someone’s area of expertise. This takes around 30 minutes, at which stage we may stop the interview if it’s obviously not going to work out for both parties. Then, let’s not forget we’re hiring an engineer… My favourite part of the interview is to sit and do some pair programming for 90 minutes. During the pair programming I’m looking at; how well do you communicate? How easily do you bootstrap the basics? How is your test automation? Is your solution kept simple? How do you react when faced with the inevitable problem & time pressure? In order to facilitate this you should have a kata ready to go. Here’s the one we used last year: https://github.com/onzo-com/coding-challenges/blob/master/1-extract-and-compute/README.md. Don’t let this get out in the wild, if you do you will have to write another! The kata should be simple enough as to be achievable in 90 minutes but not so simple as to be trivial. The last stage of our face to face is a 30 minute wash-up that includes both candidate led questions and any final follow ups that we may have. Team Dynamic — So you’ve gone through the core of the interview process and have someone that ticks most of the boxes? Don’t forget we’re all human. How will this new person fit in with the existing team? Can you see personality clashes on the horizon? Will they provide a nice counter-balance to existing team members? Will they fill a niche that in the team? We use a quick personality profile here to give us a sense of how things might play out. This final conversation is typically with our CTO (Chris Fleck) and also gives our candidate a chance to ask those last few questions that ensures ONZO is the right place for them.

Once you’ve found those perfect individuals to join the team and gone through the remainder of the hiring process there are two final pieces are super important;

Joining The Team — As you join a new company you rarely notice a smooth on-boarding process. But you really notice if it takes two weeks to even get your hands on a laptop or access to Git. As someone joins our team the first day consists of laptop, access to all systems, pull the code for a repository, get it building and push a small change. The idea here is to make it as frictionless as possible to let someone start adding value. We also have someone volunteer as buddy for the first couple of weeks so new starters don’t feel guilty with questions. We then carry out induction sessions for each key area in the business and use a bunch of launch pages to get people started in Confluence.

— As you join a new company you rarely notice a smooth on-boarding process. But you really notice if it takes two weeks to even get your hands on a laptop or access to Git. As someone joins our team the first day consists of laptop, access to all systems, pull the code for a repository, get it building and push a small change. The idea here is to make it as frictionless as possible to let someone start adding value. We also have someone volunteer as buddy for the first couple of weeks so new starters don’t feel guilty with questions. We then carry out induction sessions for each key area in the business and use a bunch of launch pages to get people started in Confluence. Culture & Engineering Manifesto — We really care about the team’s joint set of values and culture at ONZO. These are the values of the team and are arrived at democratically. They are not pushed on the team from the outside. There is a whole future blog post on this topic. A couple of examples are “Don’t Sacrifice Quality” as it will only slow you down in the long run and “If it is difficult, do it more often, earlier and automate it”

— We really care about the team’s joint set of values and culture at ONZO. These are the values of the team and are arrived at democratically. They are not pushed on the team from the outside. There is a whole future blog post on this topic. A couple of examples are “Don’t Sacrifice Quality” as it will only slow you down in the long run and “If it is difficult, do it more often, earlier and automate it” Team Cohesion — As you put a new team together they are always going to go through the classic cycle of forming, storming, norming and hopefully on to performing. We’ve got a few ways to help ease this process but there is no real short-cut. We ask each new person to the team to drop an email to everyone in the company introducing themself (where they’ve come from, what they do and a little of them outside of work). Each time a new person joins they choose the venue and the company gets lunch for everyone (Persian food is a sure-fire winner here). The most important thing is to nurture a psychologically safe environment for the team and the broader organisation. John Cutler has a couple of excellent articles on this here and here. The TL;DR is you want to create a high trust / high safety environment that empowers the team to rise to difficult challenges

Summary

We don’t pretend to have all the answers and this is just a brief summary of some of the things that are working well for us when hiring engineers at ONZO. By applying these ideas you should end up with a well balanced team that knows its own identity. I also mentioned early on that we have focussed on building a team of both talent & experience so far. As the company grows we are also looking for people with talent but not so much experience (I smell a blog post here in a year’s time). If there are other areas you think are important for forming great engineering teams then please drop in the comments at the bottom and lets discuss.

Once you’ve got some great engineers in the team the next step is to build valuable working software. With this in mind, my next blog post is likely to focus on the value stream. What is it? Why is it important? What can you do if it’s less of a stream and more of a puddle?