 So hi everyone, I'm Michelle. I'm the VPP pull at 5a I if you've not heard of us We're a UK tech company taking on one of the biggest challenges in engineering and research of our time, which is autonomous vehicles So we are hiring shameless plug But if anyone out there is looking to go involved in autonomous vehicles, please come and say hi afterwards But the privilege that is completely mine this morning. I've got Dan and Otto Two of the the greatest team builders in Europe in my opinion. They scale teams fast and they scale them safely So if you'd like to introduce yourselves Sure, so Yeah, I've been a programmer for around about 20 years Been in doing all kinds of web stuff. I Join Twitter I was around about the hundred hundred twenty employees. So this is sort of Early on at the height of the fail whale, which is which is fun And grew as a manager in that company around the web team there And sort of saw that past IPO and then went on to join Deliveroo as VP of engineering and like the intro I said that team grew enormously. It was an amazing ride. We went from 12 engineers to 230 I believe Recently though, I left Deliveroo and I'm spending some time advising Companies and small startups on how to grow their engineering teams Welcome, Otto. All right. So my name is Otto Hill scum the chief product officer at smartly IO Which is one of the fastest growing B2B SaaS startups in Europe We're in the performance marketing space working with some of the biggest e-commerce companies in the world My background is I'm a developer. I started writing code when I was something like 12 Started my first company as soon as I was legally allowed to do that in Finland, which is at the age of 18 And then my previous company flow dock raised money from Silicon Valley. We sold the rally software Worked a lot with American companies in the history But now back here building the team at smartly to which I had first invested in and then I figured a little more hands-on approach Join them Nice. So we treat. I think between us. We've probably well, we've worked in investor-backed companies. We've probably hired Fired as well, maybe but certainly nurtured thousands of engineers and product teams So to keep this simple because I think we could talk about this all day I just want to sort of start off with the hiring process And then move into the transition that teams go through when you're very very small And there's a lot of founders here that when you're just starting out You've got those tiny teams pizza-sized teams and how you take that transition through To actually having a scale up with like you have done a couple of hundred people And then finally we'll wrap up with how you nurture those teams into high-performing Engineering teams. I don't know how we're gonna fit this all then we've got 23 minutes left So let's get this started Before you put your add-out before you get going What advice would you give people? Before you've even picked up the phone and spoken to an engineer. What's what's your kind of top tips for getting cracking? I'd say it's really really important to be prepared ahead of time Especially at the early start-up stage an interview can be quite a piecemeal experience I could tell tales of really really funny interview experiences with startups, but It's the candidate experience in an interview is really really important one of the things that you have on your side As a small company that really does help you recruit great people is your reputation in the industry You want everyone to who speaks to you to have a great experience for everything to be joined up for you to give them Decisions and feedback in a timely way and really have a directed Interview experience, so it's it's pretty much the day one thing that I'll do when I join a team I know that it needs to grow. I I look at what process there is for hiring all you know all of the way through from sourcing to first week in the job and You know revise that and make sure that everyone has a job their job that they need to do and the candidates experience is great Because everyone understands their part the role that they're playing almost It's all pre-organized so the candidate is just given that white glove service all the way through. Yeah, absolutely I mean you don't need to be Polished to the point that you're not showing the character of your company because that's also really important, but It's those important things like getting timely feedback Not having a candidate chase you for a yes or no answer or leaving them for days and days all of these kinds of things like be be very much Ready with with all of that and be timely is is the big thing. I think okay, okay Yeah, maybe my take would be that first of all when you're starting a company You probably don't know what you're gonna be doing as a company. You might not have a product market fit We need a team. That's going to be quite flexible You're gonna want to hire generalists without putting them to two specific boxes of roles and kind of what they're supposed to be doing Also developer hiring is extremely difficult and most likely if you're an early-stage company You are not going to be able to attract the best people right away because there's numerous things that developers are interested in like working with the best people and and working on a great technologies and also of course on the purpose of the company, but In the beginning you don't have much of that So it is going to be the founder most certainly selling the vision and and talking to to those developers Even if you might not be the expert in developer hiring You just have to get out there because it's not going to be anyone else who's going to be able to do it for you in the in the early days Also, you have to kind of take the approach of constantly trying to improve and I'm going to kind of raise the bar so Most likely you don't want to Appoint the first developer you meet as your CTO you most likely want to kind of start hiring developers constantly expand the teams Expertise kind of improve the skill set and then you'll start to see where where the biggest demand is Where do you want those specialized roles and so on that that flexibility and trying to detect that in your interview process is Really important because yeah, like you say it's you don't really know what you're going to be concentrating on and in the early days of a company you need the people to follow you there and One question that I've oh my god. I'm giving this away if I interview more people now One question that I really rely on to to to get that kind of information is I'll always ask a candidate What is the proudest? Achievement that they've done in their career so far and what I'm looking for there again I'm I can't use this question again kind of well But what I'm looking for there is for people to be, you know, genuinely interested in the impact that they're making for the business and not tell me about how they Refactored something or got to use the latest technology that that's fun But if if that's the only thing that an engineer is going to be motivated by then an Early-stage start-up is probably not going to be the right place for them So yeah, but it's a it's a huge thing and in those really early stages where you're you're You have constraints you've got both time and money constraints How much time would you spend on actually hiring and what advice would you give to founders and early-stage tech leaders? In terms of organizing their time Yeah, the team. Yeah, yes It's kind of a cliche that you should be spending half of your time on recruiting But I literally checked my calendar and I had spent 30 hours a week On hiring at some stages when we were really growing fast So and especially in the early days since I was running most of the recruiting process myself including kind of Getting the prospects in and validating their skills and everything else. So that did take a lot of time Of course now we have a lot of people and the team helping on that But yeah, it's a time sink it's The I think you need to apply the same Thinking that you apply for two other things about it like yes If you if you walk into a team and you know that it has to expand massively then that's where your priority is a leader of that Team should be however, I Really would rather put all of my effort into you know scaling that as an activity just like I would You know put my effort into building tools and platforms that help us scale further and so You know, it's all about getting those processes in place finding the right people Making sure all of your staff have interview training and are capable of doing interviews So you're not the one You know like anything is when you when you're a leader you you do not want to be the bottleneck. So That kind of thing is really important up front another reason why I'd say this is a thing that I a mistake that I've made now that I retrospectively of would never do again I think it's really important to to hire your managers or Or nurture your managers from the team up front because at the end of the day They're the people that you know help you scale that sort of human side of the team So that leaves me on to my next question is at what point in the team's growth Do you bring in a manager or do you home grow a manager? Yeah, well There's definitely different approaches to this at smartly. We always talked about the flat organization and everything that brings it with it Even to a point where it started to be harmful because people got too attached to the kind of flat hierarchy And not the benefits of it, which is of course that people are able to make the decisions themselves You get to talk directly and solve problems directly with anyone So we actually went quite far without any team leads or managers I think I had the 30 direct reports at the point where we established the team leads So we went pretty far But then again that again kind of goes with the same principle of building the flexibility in in the early days And we actually had a team that was able to work on almost any area of the code base and any area of the product And when you have a lot of these generalists from the early days and then you start scaling Then you have the knowledge already within the teams and then So for it's a lot easier for someone to come in as a new team lead for that So we it took quite a long for us But I think now we can all agree that it was a necessary change and and we we support this kind of a structure where someone is there to help you and And mentor you I want to come back to a point in a minute, but before we move on and Dan just touched on onboarding and making sure that things were set up, right? So you've spent all of this time kind of getting people into the funnel pulling them through an assessment process You make the offer They they agree at what point Do you do you think onboarding for small startups really important to get right and and what's great minimum viable onboarding experience? I think minimum viable is the is the key. I think with like with everything with startups you It's not appropriate to bring the kitchen sink of processes And I suppose that's another thing that you see quite a lot Someone will arrive from a larger company and they'll go okay And now we will set up all of the scaffolding of a giant company There is no need to do that But at the same time it it is really important to to get that that initial experience, right? Because I think the you know that that very first initial experience especially the first week and and you know going on past that Really sets the context under which you know that person really understands how the company works You know and we all know it can be an escape of scary experience of dropping into a new company especially one that's Moving relatively fast and especially a small one where you know You can make these kind of earth crushing mistakes because they don't have the checks and balances of a larger company and so you know really Working out what that means for your companies Really important and really watch that get feedback Something that we did a delivery is we quite regularly have a sort of on-boarding retro and get people in who've done the Done recently gone through the on-boarding experience listen to their feedback make changes and Evolve the process as we go That's cool, and it's not just swag on your desk and having a machine Well a machine and a chair. It's it's about being a productive engineer for right from the get-go and Otto you have An incredible culture Hamburg on your website and could you talk us through on boarding? At smartly and how does that how does that go? Yeah, the on-boarding at smartly is getting more and more intense all the time since we are kind of we keep Adding stuff actually the culture code is written by Siri who's here here in the front row and she did a great job in stealing Instilling kind of that taking what we had and putting it into great Quotes and kind of a practical example of what it actually means and and kind of writing it down Which of course we did quite a bit later Not in the early days then we had some black and white prints from the office printer about kind of core values But now we have a culture handbook that we talk about and that we share publicly People have often read that before they even apply so and that has been even a great source of candidates for us But really the whole on-boarding is something that It's not about as you said getting your laptop or getting the keys to the office but I would say the first two months which is when you should start to become more of a kind of productive in your role and For that first of all every role is a bit different every team is a bit different So you're gonna need a customized approach So we have a smartly buddy who's helping you in all of the Test and someone that you know that you can always ask from That said we always try to focus on the fact that you can ask from anyone But people just don't so it's it makes it easier if you assign someone specifically for that And then we just go through a lot of the different background of why we're approaching things like this What's the history of the company? What what what is the vision? What's behind it? We talk about the culture and the values and so on but then of course it's not about just Bringing in to the culture, but then you kind of reinforce that by your actions and how you kind of live it in the daily and weekly routines There's one thing I never thought I'd be saying this but Delivery we brought in Facebook for work. Is that what the product is called now? the private Facebook instance for for the company and And I personally thought it would be a terrible idea it turned out especially for onboarding to be a really useful tool because I found myself Directing everyone who joined the company to just like spend a day digging around this thing because Something that is really important for a new employee to really understand is the context like where where we How we got where we are now and and how that informs those decisions and and also the style of communication and all of that kind of thing and actually having Everyone brows all of the conversation about everything which is all in the open as well You know in which is a great thing Just allow people to sort of get up to speed and feel really comfortable being part of conversations and much more quickly So yeah, that was an unexpected lesson for me there And there you know there are lots of similar tools, but but that was great other tools are available. We use slack pin everything slack slack is harder to Read through the history of which was why we tend to use that for timely stuff, but the longer form Conversation or where it went on on Facebook, which is good. I Think my final question is around nurturing that early team those generalists that you hired Actually have a lot of the end-to-end Architecture and they know all the dark corners of your code base possibly better than you may How do you keep them when you're constantly onboarding new engineers every single week? What what kind of people processes would you suggest that early stage founders set up? And when should they be thinking about that to retain those early hires all the way through to 300? Do you well it depends do you want to I? Mean if you've got if you've got a gnarly gatekeeper of some code. I mean I think the When you identify That situation Those people are either gonna you know you put them in a position where they they eliminate their own bus factor and And either they thrive and are great at onboarding people Writing documentation and and getting people up to speed or they don't and I think if they don't you need to solve that problem really quickly because those things if left alone can get very ugly and You do not want to be in a position where you're having to you know Offer this that you know the the gnarly gatekeeper of the dark corner of the code An enormous amounts of money you know pre some giant funding round later on down the line It's really worth. Yeah, like don't have that situation Yeah, I would say for retaining developers of course the keys that your work should have a purpose you should Understand that what you're building affects the outcome of the company and you shouldn't see that actual people are using what you're building So we bring developers very close to customers We invite all of our biggest customers to visit us in Helsinki So every couple of weeks or every week we have someone who's spending two days workshops meeting each of the development teams And with that kind of things when you actually see that what you just built It actually has an impact and someone's actually someone's Work just got a lot better because of what you did In our case of a B2B software I think that that's one of the key drivers then of course there's things that make you lose developers Which is if you do stupid things like you limit people's ability to solve problems by putting them to specific roles that Don't allow them to make some decisions and so on or kind of have lots of control on who gets to make those decisions So one of our core principles has been always to empower the teams to make all of the decisions The teams maintain their own road maps They have a higher level goal and based on that they built their road maps and kind of decide how to balance that work So by giving that flexibility the teams have the freedom to improve Their work all the time then of course still keeping the hiring bar high because at some point if you realize that I'm working with people that I don't Want to work with you're gonna be out pretty soon Yeah, absolutely, and I think a lot of people you know when when you talk about keeping the hiring bar high You know you would imagine you get better and better and more technical people but in a in a way I would value raising the hiring bar in terms of people skills Is as more you know more highly really because as the as the team gets bigger The the more their job everyone's job is going to involve working with people And and it and I think it takes of Sometimes it can take a different kind of person to thrive in a you know a 10 person team and it can in a hundred person team And you know like that that's fine But it's worth it's worth sort of watching out for and understanding that Quick question because I'm just conscious of time at what point do you introduce career paths and Career ladders for your engineers is that with the flat hierarchy up to 30 and then Through the next phase of growth at what point did you introduce that kind of formal structure? I Think it's really worth having an idea of what that might be at the start and the reason I think that's important is Not because you want to go and tell everyone in your 10 person team exactly kind of what their title is but because I Suppose my my personal philosophy with with compensation is I like to think at any point in the company You know if I threw everyone's salaries and and benefits up on a on a board for everyone to see can I Explain to everyone, you know exactly why they fit where where they fit So I think from from that point of view. It's really good to understand where you're going Both so you can you know have have some plan going forward for compensation As the as the team grows and also so you can let people know that there is Opportunities for them and they don't have to jump it into a different company to to continue progression They don't have to jump into management to continue progress progression like So yeah, there's a few things there, but again, it's one of those things where I don't bring the kitchen sink and you know have a 72-point hierarchy of everyone in the company and all that kind of thing Okay, so Yeah, yeah, I would kind of go back to the original approach of Keeping it really flexible and simple in the early days as long as you can We don't have any Titles with developers everyone's a software engineer. That's it For making salaries transparent. We do have a leveling system nowadays We just introduced this year. So that's a relatively new thing But I think instead of thinking of development as this one-dimensional Thing I would rather see people focusing on what can I do to develop my learning and what are all the dimensions? Where I can work on that and I can take ownership of big projects Like I could be leading the project that ends up building half of the company's revenue That would be a great accomplishment. I'm sure that would be rewarded There's other ways of how can I improve the engineering team's ways of working? How can I help in recruiting? There's so many of these dimensions where you can help and be proactive and I think focusing on this seniority Label is is counterproductive to that Yeah, absolutely. I think it's all about impact on the on the on the success of the company in whichever way is and Different engineers. I've seen impact the company in really different ways Some some engineers have a huge impact because they're the life of the team and they and and they're the Person that everyone goes to to you know answer questions or some people are huge Have a huge influence on hiring and all kinds of things. There's lots of different ways But it's like it's impact that should be rewarded It's the best piece of advice you've been given in your own careers So a long time ago when I was at Twitter and when it was quite small dick Costolo who was CEO at the time used to run Management courses for all of the new managers personally And this isn't strictly about recruiting But one thing that he said to me which has stuck with me all the time is whenever you're having a difficult conversation with someone You need to optimize for clarity not for them leaving the room feeling better And I I think that that piece of advice sort of is Influenced me massively. That's awesome. And then my final question to you or so is if you could go back ten years What would you say to it to yourself back then? Yeah, so I was actually in the audience of slush ten years ago in the first first event So I would say one thing I really learned about running companies not necessarily just about building engineering teams It's all about the speed of execution and mostly startups just run out of time And if you spend all this time kind of trying to come up with processes for whatever Compensation what all kinds of other things you are going to be spending that time while your focus should be on your Customers and there's many ways you can execute faster. You can learn from others. You can get great mentors And so on and and and that can be a great short cut That helps you move move a lot faster and because otherwise the company will eventually just run out of money when you Don't reach enough to All the iterations that you would have needed. That's great. So it's a wrap-up. I've got a long shopping list here But code your culture early And make sure that you do have a hiring process. It won't slow you down It's actually there's a reason why we have hiring process on board really well to get engineers productive as quickly as possible keep the bar really high throughout the years of building the team and Keep empowering them and make and taking care of their careers Thanks, everyone. I think that's a wrap