 Alright, it's a great honor to have Julian here with us. Julian has been a long friend if I can call him, more like a mentor. Met him first at the Selenium conference in 2014 and we've been in touch since. We're hopefully getting to do some interesting work together as well. But Julian has been doing some really fascinating stuff in the pandemic to help companies hire thousands of engineers globally. And I thought that's a very interesting topic that a lot of us would be interested to kind of learn how Julian is able to do that because I'm struggling to hire 10 engineers. So it's something that will be fascinating. So with that I wanted to kind of welcome Julian to share his experience trying to onboard thousands of engineers. Thank you, Narek. Have you been prepared? Yep, we can see your slide. We can see me yet. Not you, Narek. No, it's hopefully you can see me now. Yes, we can see you. Excellent, right. Let's get going then. So the first thing is 90. There's an excellent book aimed at managers and people joining companies at senior levels called The First 90 Days. And the argument in this book is that new people have got 90 days to prove themselves in a company. And that includes understanding what the company is doing, its health, what its needs are, make the human relationships, etc., etc. The challenge was that the company I was helping actually took 90 days just to onboard engineers until they became net positive in the company. And 90 days was costing the company a lot of time and energy, particularly as they wanted to grow very rapidly. They wanted to double the engineering team from around 2,000 engineers to 4,000 engineers in their main regional location. There was another challenge. People were coming from over 60 countries. We estimated at 66 different countries and flying into Berlin, which is the capital of Germany and Europe. And the first challenge is the language is German, not English. So although it worked, everyone spoke English, people had to arrive into this country, get used to the climate, whether they're coming from India, Brazil, wherever in the world, and settle into this often with their families. And meanwhile, they had to learn how to be good software engineers. I'm going to clarify one thing that Nuresh said. This work was done before the COVID. So we had people arriving in person and the work was in person. I'll touch a little bit on some more recent work towards the end of the talk. So like many companies, they had a big challenge. They wanted to make good software quickly. And they realized that onboarding people slowed the teams down as well as the new hires. Now, just like all of us, we've joined different companies at different levels of our expertise. And I have probably joined 40 or 50 companies so far in my career. And every time I do so, there's things that I have to learn and that's understood. But also because I joined, I started asking questions. I need things from other people. And ultimately, that slows down the velocity of a team. And for this company, they were looking to double the team. So that meant that there was always new people joining each of the teams. And the drag was absolutely incredible. So we wanted to find a way to essentially keep the flywheel spinning, keep moving as we hired new people. We also had a bunch of challenges it turned out in the company. So for instance, the dev environments took weeks to establish on their machines. And there wasn't a centralized onboarding for the technology team. We actually need to solve three concurrent challenges. We need to solve the cultural ones. As we may know from companies such as Google and Facebook, the culture is all important. People joined a mindset and approach and a way of doing things. And one of the challenges for companies, particularly when they're growing rapidly, is how to preserve the good bits of the culture of the company. Because new people know little or nothing about the culture. And they dilute the culture just by being there. So we need to make positive efforts to improve the culture. Of course, we needed to deal with the technical aspects. So there's particular company, the core coders in PHP, very large PHP user, but also they have mobile apps and other technologies, databases, data warehouses. So anyone joining had to understand the tech stack and how we did things in the company. And finally, behavioral, again, with people coming from more than 60 different countries, lots of different ranges of experience and background and ages, et cetera, et cetera, dealing with the behavioral aspects of people was all important, because poor behavior undoes just about everything else. So people aren't on board and engage and understanding how they work with others. And remember that people are coming with speaking perhaps another 50 different native tongues, as well as the English they're communicating in a German environment. There's lots of complexity that we need to address. So the first thing is we did a sort of equivalent of a sprint zero, which was research. And this involves me going over to the HQ, which is in the US. And there I met one of the co founders who run the engineering team, got to understand the business, which is actually selling e commerce, selling furnishings. And they're one of the largest people in the world in doing so. And understanding whether business comes from and the fact that trucking fleets helps to understand what the software ultimately had to do because some of the software was running the trucks, for instance, I joined the new onboarding program in both locations. So first in the US and then in Berlin, and went through a week in the life of a new hire, which involves getting a new laptop, trying to get my account set up, trying to work out a VPN was going to be running doing all sorts of problems and challenges, meeting people throughout the organization from brand new hires, through the people who come through onboarding programs, CEO, directors, vice presidents, HR, really trying to get an idea of everyone in the company, and then evaluating the current onboarding programs in both locations. And then in the Berlin office also moved on to designing a pilot program. So I'll touch on some of the key findings. The first was the business was truly highly invested. And for many of us, we know when we joined companies, they may say one thing, but you watch their practices, and they do another. So they may say, of course, we invest in our people, and then you realize the laptop they've given you is four years out of date, or they want people to be contributing on day one, even when they're all sorts of problems. This company was willing to invest up to three months for an onboarding program, even six months, if they thought they would get the business value from it, very, very unusual in the industry. They had a three month bootcamp, which worked quite well. And that was to hire people who came from non traditional programming backgrounds, who grew up in boot camps, and there's plenty of them in the USA. I think quite a few in Europe and certainly in India as well. So people come from all sorts of backgrounds without computer science, learn how to do some basic programming, web front end, etc. And then this company joined the bootcamp and worked on real code bases with supervision over a three month period to get them up to speed. I was talking to some of the directors of the company, and this was level six in the company. So senior people, normal 20 plus years experience. And they didn't see code at all, because they had to deal with other problems, except on the red days. And the red days were peak holiday seasons, for instance. So in the US Black Friday, just have to Thanksgiving, for instance. And they had to sign off when the rest of the code was under lockdown, because no one wants to change production. The trouble was they didn't actually look at the code until the critical day. And many of them said, look, it'd be wonderful if you actually understood how the code worked, and we'd at least worked on ourselves and built something simple. So they were poorly served by the current onboarding program. We also discovered that some of the engineers had created their own micro learning and it was working really well, and grown the grassroots level from one team to hundreds and hundreds of engineers going through these programs to learn technologies they thought were relevant. And we also realized that the engineering globally needed a practical hands on for the skills in context. And this means in the context of the company and the company's code base, the company at a time is about 15 years old, and some of the code was nearly that old. So there's a lot of technical debt, and people actually need to be able to work productively in that environment. So then moving on to the outcomes, we agreed we designed an MVP, a minimum viable product equivalent of a pilot. Meanwhile, and in parallel, we've designed a structured hands on program, which include the basics of building the code, testing the code and deploying the code. Now, some of you who are listening may be working for big companies with 10,000 50,000 engineers. But in this case, most of the people that we hired came from tiny companies, companies with maybe five people, 10 people, 20 people working with the code. And to come into an environment where 1000 people worked on some aspects of the code base, were several orders of magnitude beyond what they were used to. It wasn't one continuous build server, they had to get to know, they had to get to know hundreds of them. They had to work at how all the different databases worked. And there were 10s and 10s of databases for specific purposes, like marketing, for instance, again, with a test, they had to understand how to run the tests, productively, how to make sure that their tests integrated well. And then finally, they had to go through all the deployment stages. So we wanted to make sure that people understood these things. Because we were software engineers and technologies working on this, we realized the importance of incorporating feedback from the new hires, building analytics to the learning and applying agile practices. So with that said, sprint one was the pilot. We realized that we had to push ourselves as quickly as we could, because in a month, potentially we'd hired another 200 engineers at this point. It was actually Christmas time. So the hiring was a little bit lower than that. But nonetheless, we really wanted to get something up and running within a couple of weeks. So we bootstrapped with a pilot very early on by building on some of the elements we found in the company. So we have these micro learning sessions that came from this peer based group in the States. And they come up with this model, which was that it was, I would say peer led, it was very practical learning. There was always some code involved. They did both mob and pair exercises in small groups of between four and six. And we need an even number because of the pairing side of it. They realized that conference rooms are hard to get hold of, but that's the sort of place where you can fit four to six people. And also as at least a computer there with a keyboard. So the learning was going to be web based. So they could use the computer equipment in any of the meeting rooms, rather than having to bring a laptop with them across from one building to another, etc. Because of meetings and the rest of it, they wanted to learn to last 45 minutes or less. It was easy to book a meeting room for that period. And they built in immediate reviews. There are three stages now go into those stages next. So for each of the topics and someone prepared the content. And as I mentioned, they designed the courses to last within 45 minutes. And they basically looked online for things like YouTube materials, online learning, code on the Git live GitHub, etc. And then designed the program so that it could be used by other teams. Then one of the team somewhere in the company would prepare the session. And they would work through the prerequisites, get their colleagues involved, prepare the meeting room, etc, etc. And then finally, one of the peers would lead the session. And the group would work all together at first, doing mob programming, and then in pairs. And finally, they regroup at the end of the session and decide, for instance, have we learned enough about this topic? And let's say it's no JS, or do we want to learn something else? So they made immediate decisions on what to do next. Each topic was structured. And here the dark blue is what goes around it. And in white is the actual live 45 minute session. So we're using some of the concepts such as missions and charter to make sure that the four or six people together knew what they were learning. They typically watch a short video of a couple of minutes between about two and five minutes. I mentioned they do the group exercise and the pair programming. Sometimes we were able to practice individually if they brought the laptops and we had time. And then we did the review and the triage. And as I mentioned, there's a bunch of preparation by the session leader, and we built analytics in this so we got the feedback. We ran our pilot program on the 19th and 20th of December in Berlin. And it started, this is actually a copy of the menu of the two days. So the head of engineering Berlin met the team. This many new hires was a revelation to actually meet one of the people who was involved engineering at senior level. So they got to know him personally. And then the next thing they learned to do is set up their virtual machine and test it. And again, for those of us who use Docker, this may be obvious on our own machine, we had company that often permission to deal with and set up and can't please all need to be addressed. So here we're making sure that new hires on the first morning would be able to do something useful with their computers. They had a good lunch, provided by the company. And the afternoon, they went through one of the peer learning groups. In this case, they were learning JavaScript arrays. Now the topic was less important than the practices. So learning to work as a group was more important than what they were learning. And that's what we were trying to focus on, trying to inculcate the company culture right from the outset. On the next day, they learned PHP storm, the standard editor, made sure that VPN access was working. And we had the IT and networking support people in the room, so they could deal with any of the problems while the people were sitting there basically. So we knew that by the end of the session, their VPN was working or tickets were raised if there were bigger problems. And then after that, they learned about an internal tool and which databases were which. And the database they'd need to know for their daily jobs. We had a Slack channel, so they could ask for help. And we had named individuals. Essentially the pilot went really, really well. And some of the existing employees decided they liked it so much, they got involved in designing sessions. We also learned that collaboration really helped. So we had this concept of mob programming. We onboarded in cohorts, which means the people who were hired in December then helped out with the hiring of the next group we joined in January, etc, etc. And again, people came from all sorts of backgrounds. So we got them to use their experience and expertise to help others get up to speed rather than sitting twiddling their thumbs because for them it was obvious how to use PHP storm within five years. So instead of them sitting their board, they helped their colleagues who were new to this stuff. Just over a year later, I reviewed the progress of the engineering teams and they then implemented a five-day program where the first two days were corporate onboarding, learning about the company and the business, getting to meet the co-founders, etc, etc. And then on the Wednesday they focus on building the code base, Thursday all the automated tests and how to run them, and on Friday deployment. So that meant that everyone from a senior director being hired to a new grad had actually worked with the code base and deployed something into production by the end of the week. And we have people shepherding to make sure that the deployments are actually useful and not going to damage production. And we had a very positive feedback. For some of you who are familiar with marketing, there's this concept of net motorscore. It's used by Netflix for a lot, for instance. And we got a very positive feedback from everyone who participated in the new hires. So moving on then to this strange world that we all live in now, where we do virtually everything remotely, both this company and another major billion dollar company in Europe are actually looking at distributors remote hiring, onboarding and working. And we're essentially comparing notes across the companies and organisations on what works well and what doesn't work well. And this includes, for instance, shipping a laptop to new engineers in, let's say Brazil or in Cuba. And as you probably know in India, sometimes you're shipping it across states. You have problems with customs and getting permissions and delays. So we have similar problems shipping laptops into these different countries where the local authorities want taxes, they delay things. So how to deal with all the logistics of this is really important. And also for new hires, getting to know their team is absolutely vital. And they may never actually meet their team in person physically for months or even years at a time. So it's a very new world order. And we're actively looking at ways to improve how we do so. And one thing I'm going to encourage you is for those of you who would like to be involved in this sort of work, please get in touch with me afterwards. And I'd love to hear about your experiences. I will mention another example is in early COVID period, so back in April in the UK, we had someone joining a project team for a week. And it's doing something called the coronavirus tech handbook that was started by a bunch of people in the UK and then countries around the world came onto it. And we got money to pay for a developer to help with some of the code base for a week. And we actually designed a micro scale onboarding for that new hire. He lived in another country and we found ways to get him involved in the code base up to speed quickly and able to productive and contribute code within the week and found to be really effective. So I'm wrapping up now. If you'd like to learn more, then please get in touch with me. It's julienhearty at gmail.com. You'll find me online. You can also find a research paper that I published a few months ago on this case study and it's free download. It's available from a group called the ACM. If you search the title, I hope you'll find it. So with that, I'll hand over for any Q&A. All right, thanks julien. That was very insightful. I think again just the designing of the whole onboarding process and how you went through seems kind of quite interesting. So thanks for sharing this. I think the slides in the video will be available. We recorded it. We'll put it up. Are there any questions from the audience? First of all, can you guys all give a thumbs up if you if you were able to follow through and like the topic? There we go. Some thumbs up and a hand. See someone even showing raising the hand. So if you have any questions I would request you to please go to the Q&A section and add your question and I will have julien respond to it please. So while we wait, maybe julien I'll start with the first question. So you said that right now you've got them down to a five day after 13 months you've got them to five days of the onboarding. First two days is for corporate and then the next three days is to actually take an idea, build it out and actually put it into production. Yeah, it actually that happened within four months. So it happened a month after the pilot and it's then been refined. So we're looking at it essentially a year after that is in. Okay and is there a fear in the other employees who've been there saying you know what if this breaks something you know like when someone's new trying to push something to production in three days of exposure is that is that fear common and how do you deal with that? I don't believe the fear exists and it's similar to Facebook. So Facebook have a very well known bootcamp and similarly they try to get new highest to contribute code into production into real code bases within the first few days and all that code has to be code reviewed. So the code reviews is done by the more experienced engineers and they're able to stop something stupid going in. So it's not that the normal engineering practices don't occur it's more that this is integrated as part of an expected. Okay and is this only one time you know onboarding or is there like you explained is an iterative process so you do this every so often over a period of time? So for the new hires the people who onboard they go through this once as far as I know and the company ends up hiring I think it's about 1500 engineers in the 12 months after I was involved. So quite good growth in terms of that. They're doing other work to help the engineers which includes quite a few of the ones who joined in the last year to help them learn collectively. Okay cool. All right Julian thanks a lot for joining us today and I appreciate you sharing your experience onboarding people thank you. Okay thank you Naresh.