Engineering a People Process- How Software ate my world!

Can software engineering principles really work on a people process?

At Skyscanner we have implemented our own unique version of a Tribes and Squad model for our engineering function. However, for various reasons, we felt there was value in implementing the same methodologies to a people process.

As our business continues to go from strength to strength and grow at an extremely rapid pace, this places a similar demand upon our engineering recruitment. As such, we have spent the past year focused on not just attraction strategies but also how we actually process candidates and get them hired into the business at the pace required; an enormous challenge.

When running tests and applying principles like the Theory of Constraints we had to factor in people’s emotions, human behavior and sometimes people just changing their mind.

Here’s what we learned, as well as some of our failings along the way.

Theory of Constraints

This experience was one of the most interesting I have had, identifying a single bottleneck in a high volume people process with a huge number of stakeholders was extremely painful.

Even more challenging was explaining to our CTO and our PMO Director that if we put a candidate in a lane or assign a card, it’s not like software waiting to be tested, and humans don’t stay put until you get to them. Candidates will phone us, they will be interviewing at other companies, they will not respond to our calls or emails and sometimes they will just decide not to take an offer. All factors completely out with our control.

We identified our bottleneck was at interview stage — we didn’t have enough interviewers to cope with the demand of the people at the top of the funnel. We addressed this by increasing our interviewers and having pods in each location. We can now interview every day in each location, with capability like we have never had before.

Biggest learning- Theory of Constraints worked!

Biggest failure- Turns out explaining people processes to engineers is not as easy as it sounds and I sucked at it initially.

Engineering Recruitment Process

Using learnings from the TOC and with our Director of PMO’s help we had an in depth look at how work/tasks are split among engineering squads. We looked at how we could streamline the recruitment process and the roles within our team. We adopted a funnel based/specialism model where each team member would own a funnel/specialism and see the process from end to end. I like to think of it as trying to work towards having a full stack engineer. Our engineering recruitment process has changed twice this year and we are working on a further iteration. Throughout this time we have adopted some learnings from experimentation and have conducted our own A/B tests including with job adverts, positioning on certain job platforms, reverse ordering of stages to gage results.

Biggest Learning- Our Engineers are awesome and ownership allows for increased efficiency and better performance! Also iteration and improving even by 1% is a pretty smart way of approaching a problem.

Biggest failure- Expecting a solution to be a solution forever. The reality is Skyscanner is changing so rapidly that we need to be constantly adapting and scaling to the needs of the business.

Becoming a Squad

We took the leap and the impact this has had on the team and the work we do is extremely positive.

But are we really a squad?

· We do daily stand ups

· We run a Kanban system

· We migrated a huge chunk of the candidate workflow to a software platform our engineers use

· We apply lean thinking in almost every decisions we make

· We iterate, continuously improve and most importantly listen and have learned from our engineers

It could be argued that we don’t own our own process and that there are too many dependencies and that we can’t run actual sprints as we are not working on one problem at a time.

The irony is we are a service to the business and our product is people. Our microservices are chunks of the process and specialisms of people we want to hire and those are split up and carefully managed to ship the outcome of making the hire and closing the deal.

Biggest learning- Did I mention our engineers and leaders are awesome? What we have achieved in engineering with squadification is one of the most interesting things I’ve ever seen- we learned from our peers Spotify and adopting some of the thinking we have in this area has resulted in fundamental positive change.

Biggest failure- Typically people struggle with change and managing people’s expectations is difficult.

To answer my question- Can software engineering principles work on a people process?

The answer is YES with the caveat of the following:

· You have to think different and approach the problems you have always known in a different way

· You have to listen to extremely talented and technical people and try to establish a communication flow that works for all

· You have to manage expectations of all team members and stakeholders involved whilst admitting change is difficult, you will make many mistakes and iteration is key