In my current employment as Delivery Manager at a software company I oversee the design and development teams (aka 'Engineering') that are building a brand new property management software-as-a-service platform. In 2016 we were acquired through a private investment consortium and given an injection of funding in order to 'go faster'. This blog series is a summary of the lessons I learned from tripling an engineering team in six months.

Part Three: Setting up for Success

If you haven't already please read the preceding articles in this series:

Part One: The Background Story which gives the overview of what happened in 2016 that led us to need to scale at such pace; and
Part Two: Planning to Scale where I dove deep into the actual plan we drew up and how we verified its feasibility

And now for Part Three: Setting up for Success. This is all still focused on what happens before the hiring. Here I focus completely on what we did after we had drawn up the plan but before we started recruiting. Why have I devoted an entire article to this innocuous part of the process? Because it's THAT important.

I think most people would skip or, at the very least, rush this step. But armed with what the end state looks like it is important to work on two key sets of definitions/documents before you jump head first into the murky swamp that is recruitment at scale.

These two areas are: the recruitment process and the candidate supplementary materials.

The Recruitment process

I bet I know what you're thinking right now….Well durr Zac. Of course you need to know what your recruitment process is. But we already have one defined so we can just skip that.

Nope nope nope. Or, for other fans of The Oatmeal and/or Exploding Kittens

I'll just say this straight out. Your current recruitment process does not apply here. It was not built to scale to this level. Maybe, MAYBE, you've hired a couple of people at the same time. But 40-50 over a few months? Nope.

As an example, at our peak of recruitment we had 10 people start on a single day. Ten! Imagine if we had tried to have ten 1-on-1 pairing sessions or done ten 1-on-1 office inductions. It just wouldn't work.

When you are planning to scale your staff numbers you also need to plan to scale your processes, and the recruitment process is the first cab off the rank.

Step one is to draw up your ideal recruitment process. I'm talking drawing each step and defining who is responsible. I like to actually draw it up like a flowchart as it helps to visualise for the next step.

Here is one iteration we did:

Looks reasonable. But if you read part two on planning to scale then you know I'm not one to just assume a nicely drawn plan will actually work. I like to try to break it first. And so we started diving in to and asking questions like:

Does this cover absolutely EVERY possible step in the process?
What happens if a key stakeholder is away?
Are there any potential bottlenecks?
Which steps are mandatory?
Which steps are optional?
How will we know what good looks like at every step?
How will we track candidates?
How will we know when someone is 'stuck in the process?
What are the minimum/maximum times we want each step to take?

I could go on. But basically this exercise was here to build a common understanding of the process and ensure anyone involved knew how to keep the recruitment pipeline flowing. When you are recruiting one, or maybe a handful, of roles at once the process can be inefficient without much problem. But when you are seeing hundreds of applications every week you need the process to run smoothly.

As an example, at some point along the way we tweaked the ordering of our process to remove a bottleneck - me.

Previously I was the organiser and main stakeholder in the recruitment process. I took full responsibility for my team and any new hires that may join us. As such my general rule of thumb was to have a 15 minute phonecall first and then conduct a 1-on-1 (or similar) interview before even getting candidates to meet tech leads. When we were a team of 10-15 my mindset had been that I could do the initial team/culture fit filtering and then leave the in depth technical assessment until the end. And this process did work. It had worked for us for over 12 months.

But it wasn't working at scale so we changed it. First we decided the initial phonecall and interview could be 'anyone' from our leadership team - CTO, Architect, Delivery Manager - and this helped but it wasn't enough. Ultimately we had to empower our (newly created) Engineering Practice Leads to make these decisions. We flipped the process around and led off with the technical interview and only followed up with a HR/Leadership interview if they made it through. This little change is an example of what enabled us to hire 40+ individuals across ~6 skillset streams without bottlenecks.

But I digress. Let's get back on track. Right now we had just nutted out our recruitment process. It's time to start hammering those job ads right? Ummm not quite. First we need to work on our supplementary materials.

Supplementary Materials

There are things you just don't want to do over and over. Having the exact same conversation with 100's of candidates about the company strategy, technology stack, team size and structure, and go to market plan are all examples of these.

When you are recruiting one position it is perfectly fine to not have any of this documented, or even ready to share with candidates. It's quite acceptable to just give the sleect few candidates you meet the verbal run down of all these things. In fact at that (lack of scale) it's probably a more effective use of time to do that rather than prepare a bunch of documents.

But not when you are recruiting at scale. That's when you need to be prepared. Here is the list of supplementary materials we prepared before we starting recruiting in anger:

Position descriptions

This is a no brainer really. People want some idea of what they are getting themselves in to and what is expected of them. And if you are hiring someone you really should have some idea of what the role entails. If you can't write it down succintly then you're not ready to hire.

Position type breakdown graph

This was a pet idea of mine to create a visual representation of how much time each role spends on things like solution design, actual coding, peer reviews, people management etc.

This was the first cut. Broadly speaking the blue tasks are technology centric and the green tasks are people centric.

Having this defined was useful for everyone to understand their role but it was absolutely crucial to have before we hired newly created roles.

Team structure

Similar to how the above two documents help people understand their role, knowing the team structure helps people understand how they will fit in to the greater team. For some teams/companies this could just be an organisational structure diagram. For us, it was the tribe & squad diagram that I've shown already in part one and two of this blog series.

Technology stack

To help people understand our technology stack and to pre-empt questions, our solution architect whipped up a pretty one-pager graphic that showed our technology choices.

This was a fantastic document to include as it allowed candidates to tailor their response to suit our technologies, as well as arm them with information to ask us some tricky questions.

We also used this to talk to people at developer conferences and it generated a lot of interest and active conversations.

Technology Charter

We already had a great team culture in our engineering team and it was imperative that we didn't ruin it so we documented what it was and what it meant to us and then shared it with all incoming candidates. If they weren't ready to buy in to what it meant to be part of our team (especially our 'No jerks' policy) then they weren't the right person for us.

Company and product strategy/blurb/pitch

This was very important. Most good candidates wanted to know both the product AND company strategy. In fact I was skeptical of anyone who didn't show an interest in this.

How to find us, check in, prepare for interview

This sounds so simple because it is, but when you are hring at scale this is a time saver. Having all the standard information like this consistent and readily available saves bucketloads of time. It's not hard to do so there is no excuse.

There is also where I give a shout out to Teradigital - a specialist technology recruitment company we partnered with to help during this massive scaling up process. We chose them because we had worked with them before and they understood our culture intimately. They knew how we were different to most companies in Brisbane and they knew how to help us achieve our goals. It was their idea to collate all this material into a single candidate pack. This was a fantastic idea because it meant candidates either self selected out of the process or they came primed, excited, and ready to have detailed conversations with us.

It is also amazing how having this information defined and readily available made a big difference to me as a the main recruitment driver. Just going through the tasks of getting all this ready help me identify my values, set my personal framework for making decisions, and reinforce the benefits of being prepared.

Example: The case for being prepared

A prime example was a potential candidate we had from one of the biggest tech companies in Silicon Valley who was looking to move back to Australia. Having worked 5 years at tech-giant-super-mega-company naturally gave this candidate a halo effect but he was definitely worth talking to. I met him and we talked and, like dating, we both decided this was relationship worth pursuing. Except there was one problem. I wasn't ready to hire him.

He had arrived on the scene just a little early. We hadn't quite finalised the deal (covered in Part One) but more importantly I hadn't yet defined all the roles needed. I knew I needed some new roles like Engineering Practice Leads and Solution Leads but I just didn't know what they were yet. I didn't have a PD for them and I certainly didn't have a nice pretty graph shown above to demonstrate how I saw the role breakdown occurring.

So when I talked to this guy I couldn't talk in specifics and until I could I wasn't going to be able to make an offer.

The result? While we were still working on defining all those things this candidate took a senior leadership position elsewhere. Fair enough. I wasn't ready and I wasn't going to rush and this guy was flush with offers.

I'm not even sure he was going to pass the technical test (probably) but I was happy I resisted the pressure of hiring to uphold my values. You can't hire until you are prepared and you aren't prepared until you have it defined. When you are trying to scale you will be tempted to cut corners in order to hit the targets but you need to do the opposite.

In order to hire well you need to prepare well.

Thus ends Part Three. Please keep an eye out for Part Four: Hiring (finally!).

Below are the links to all posts in this series. You can sign up to email list to get alerted for new content and if you have any questions or want to get in touch you can email meor shout out on twitter.

Tripling an Engineering Team in Six Months - Part Three: Setting up for Success