BACKGROUND

In 2011 Lonely Planet moved its digital business from Melbourne to a new Headquarters in London. With only 6 of the original 75+ team transferring to London, an orderly transition of the business without impacting the operations of a website that attracted 10m unique visitors a month was going to be a challenge. One of the major risks of rebuilding the team in London was recruitment of a technology team – in Melbourne the technology team had built up a brand cache, had extensive networks, and could move quickly. In London, it was time to start afresh.

KEY BUSINESS CHALLENGES FACED BY THE RECRUITMENT TEAM

1. Risk – moving the digital business closer to customers, and into a lower cost environment in the UK was a bold strategy, and as such had the focus of the most senior BBCW and LP executives as stakeholders, let alone the Digital Managers who needed an A-Team to work with in London. A lot was riding on making this transition a success.
2. Timing – from the announcement of the move to London in May, it was planned for the group to be up and running by mid-September 2011. Yet UK employment notice periods were realised to be up to 3 months for a software developer!
3. Proven recruitment process – Lonely Planet had developed a fairly lengthy process of selecting team members over the previous 4 years. Based on similar hurdles to Thoughtworks’ hiring in Australia, recruitment was a multi-step process involving up to 6 people who review, tech test and interview candidates. This was not about to be abandoned lightly!
4. Resourcing – with the dramatic down-sizing of the team in Melbourne, the load of recruitment work (resume reviews, supervising tech tests, interviewing), which was normally spread across many IT professionals fell on the same few people who were working on the transition of the applications development group to London.
5. Time-zone differences – to run the process from Melbourne required the leader responsible to shift his work hours significantly- to engage UK-based candidates meant working UK hours in the evening. The sheer logistics of skype interviews and scheduling was significant, even when supported by an HR professional on the ground in London.
6. The new IT team urgently required a wide range of test, UX and operations roles, plus 4 Ruby/Java developers. These would all need to agree to working in agile fashion in a multi-disciplinary team, using DevOps techniques to ensure end to end ownership of the applications and a steady flow of features to the products on the website. This is not an easy team to recruit in the market.
7. The Lonely Planet website is very large scale and complex global platform – containing ecommerce, advertising, pure content pages, bookings and transactions, single sign-in, and online community applications. This complexity would raise the time to competence for any new starter.
8. The new team structure would depend very much on the talent that was attracted – as each new hire came on board, the Manager planned to adjust the remaining hires to complement the skills that came with a person of the right attitude. Thus there was an incremental element to the strategy.
9. Attention span – the executives managing the project had a lot on their plate – and despite receiving a detailed email each day of progress through the employment funnel of the many candidates, as often happens with executive in-boxes, the communication level was perceived as insufficient.
10. Recruitment takes time – even in the best of times, the LP technology team took on average two months to recruit the right candidate for a role, with activity in Melbourne’s  IT user groups, online, at conferences and through personal networks. Candidates, on the other hand, go ‘cold’ quite quickly – and often have multiple offers. Yield from the Lonely Planet hiring process averages 2 hires per 100 resumes received.

AGILE AND LEAN SOLUTIONS IMPLEMENTED BY THE TEAM

Initially the hiring process was managed ‘online’ using the standard Lonely Planet recruitment management system and a large A3 spreadsheet showing the gradual transition to London of the key roles. But as often happens with online systems, spreadsheets, and emails, there can be a big gap in visibility to stakeholders. As time progressed, some stakeholders expressed that they were concerned that nothing appeared to be happening with developer recruitment.

The most notable components of systems thinking, lean and agile that were implemented to improve the situation included:

1. Genchi Genbutsu (go to the place of the event)– Ed Cortis, the Lonely Planet CIO in Melbourne, stepped into the role of on-the-ground co-ordination in London. Having the logistics of premises and basic technology in place proved vital to the speed of ramping up of new arrivals. A human face from the technology team for recruiters and applicants to meet was a distinct advantage.
2. Visualisation of the work – Jay Hyett (pictured above), managing the Melbourne end of the process set up an agile board in a highly visible location that executive stakeholders would walk by daily. Each candidate was on a card, with cards coloured differently for the main roles. The daily email report was still retained, to help cover the communication gaps that might arise working across a 20,000km gap.
3. Effective, simple board design – a left to right flow through multiple steps, with visual signoff of candidates’ resumes in column 2 (see photo above) by all reviewers, daily standups, and retrospective-type thinking on what was working from the sourcing point to employment contract finalization.
4. Daily standups ensured the process kept moving and any blockers in the system were addressed promptly.
5. Focus on flow of candidates – not obsessing with the filling of the recruitment funnel but maximizing the speed with which they could pass through the process. Many recruitment processes reward success as being the number of candidates into the top of the funnel.
6. Prioritisation of candidates needing attention – not just on the order they came into the process, but on the nature of their situation, competing offers etc.
7. Focus on learning and adapting – being a new market for hiring developers for Lonely Planet, close attention was paid to data collected on the most effective sources, efficient recruitment partners, social media campaign performance and cost. Data showed that the tech test, standard in Australia, was proving a barrier to developers completing the process in the UK, and so the hiring team modified it.

There was initial tension over the privacy of candidates’ information with their name appearing on an agile card in the open workplace in Digital at Lonely Planet. It took several debates and good use of the ‘5 Why’ technique for everyone to be comfortable that this was the right approach.

Recruitment is plain hard work - but having a great system is half the battle. Here are the 'done' columns for this agile board.

The most important column may well have been the ‘not successful’ column, on the very right of the photo above. This immediately painted the picture of the immense amount of effort that was going into managing the system, far more effectively than the daily email.

The core agility of this case study is with the team’s obsession with learning and adapting to the changing conditions faced by the team on the project. Recruitment is a field normally dominated by scientific management thinking – mass production of candidates, automation of hiring and standardised testing processes, eliminating variation, and minimizing cost per candidate.

With the Lonely Planet technology team’s recruitment process now visibly under control, attention was able to be put onto the cultural aspects of building the new team in London, ensuring the core agile habits were retained and that the team took the opportunity of a cold restart to make their best of their opportunity to live and work in London.

For further information on this case study, contact Nigel Dalton at nigel.dalton@lunatractor.com