First On: Engineering with Pablo Castellanos García

My guest today is Pablo Castellanos Garcia. Pablo currently serves as the Director of Engineering for Wayve, an AI-powered autonomous driving company with a mission to bring true mobility to any urban environment on the planet (Fly VC portfolio). Engineering talent is the lifeblood of any tech startup, which makes the technical lead perhaps the single highest impact hire a founder can make. Our conversation walks through Pablo’s transition from academic to developer to founder to engineering leader and all the lessons he’s gather along the way. Pablo shares his perspective on managing through a team health lens, his uniquely strong opinions on org structure and the challenges he faces leading software and hardware teams in parallel. Hiring and inspiring engineering talent is now a prerequisite for startup success so whether you’re a current or aspiring founder, this interview is for you.

How have you built a career in engineering? What are the major chapters of your professional life?

I started in academia, specifically computer science and later mathematics. Academia was everything for me. At one point I was studying for a Masters in mathematics while also pursuing a PhD focused on control within computer science. It wasn’t until I was writing my PhD thesis that a friend reached out and asked me to give startups a try. Here I am, 14 years later.

We spent five years building a hotel search website using natural language processing and semantic search. We made all the mistakes that you can imagine; grew too fast, tried to monetise too quickly, had to downsize. Lots of ups and downs.

In 2013 we sold the company to Skyscanner which then started my transition into management. My scope at Skyscanner was far larger than what I had been doing previously. I needed to create a team around the autosuggest system that I had built for the startup - It had to support 30 languages instead of the original 2 and we had to manage 300 machines to support the huge amount of traffic. It was a very different phase. Skyscanner was divided into tribes and squads, similar to the Spotify model, and I ended up running the entire data tribe at some point, which was around 50 - 60 people. We led all-things-data across the company, which was a lot of volume, at some point 2 million messages per second. And that was my last 3 - 4 years there.  After 13 years I decided it was time for a new challenge. I knew that I wanted to go back to the startup world but not preseed; I wanted something a bit more solid. I also wanted to have more impact, which is what brought me to Wayve.

What was it about the Wayve pitch that got you over the line and made you say, “yeah, this is what I want to dedicate years to?”

First it was the contrarian approach. We’re not following a trend but instead trying something that if it works, it really works. At Skyscanner on the data team, I was the one with a contrarian approach compared to the rest and I made it successful, so I'm a sucker for that style.

The second thing was the tenets they held like staying lean, being smart about hiring, building a close knit group. We had everyone in a single location. They took the time to ensure that the drivers, hardware teams and software teams all worked in the same place. There are no classes between groups, everyone is equal. That was a big thing for me.

And then obviously the mission. They were trying to give true mobility to absolutely everyone and that was most important to me.

How do you define your role as director of engineering? What are you responsible for? What do you measure yourself?

Director of engineering in a company like Wayve is very different from what I was doing before. Here we have hardware, we have software, we have a lot of different skills, which requires a lot of coordination. One thing that I didn’t expect is how to coordinate agile software projects with hardware, which needs to be more rigid with lead times. That's taken much more time than I expected. 

My job is to frame where we are now and where we need to be in the future, in our case for Series B. I'm not going to tell the team, “this is how you need to do it”, but I need to explain what I believe needs to happen. Obviously there’s collaboration. I can’t just say, “this is exactly what needs to happen, go make it happen”. I need to understand what's feasible, because if you let me I'm going to go crazy with ideas. I have to provide a vision that people can follow. 

The role is also organizational. I need to ensure that people are in the right positions, understand what teams are under sourced or under utilized, understand where I need to hire and where to let people go. At the same time, giving them the space to identify how they need to work. One of the big things I did when I joined Wayve was to change the organization model because there was a lack of accountability. At the time, they were using a model where chapter leads didn't have the power to be accountable for their own projects but they did have all the context about what they were working on. So I flipped the matrix and placed the chapter leads on top of our org, we actually call them group leads, so it's a more vertical structure. Flat organizations don't work really because then there is a lack of accountability. What you need is an organization that has clear levels but the power gradient between them is as low as possible.  The way that I think about leading a team, and this cuts across Director of Engineering, VP, Group Lead, whatever, is that there are three big pillars that you need to think about: strategy, delivery and team health.

Could you give an overview of the tribes and squads model that you’ve mentioned? What's the methodology and intent? What are the limitations of that model?

I should say that at Wayve we don’t use “tribes” we use a “groups” and squad system, which is no different than business teams and business units. Squads hold the delivery of components of the company. For example, we have a Data Explorers squad, which is responsible for data pipelines, grading data sets, etc. We have a Machine Learning squad, which deals with infrastructure and model training.

Groups aren’t really necessarily until you get to a certain stage. Early on a group is kind of an oversized squad that provides some context and collaboration between teams. A group creates alignment by merging what squads are doing an isolation. We may not need the groups yet but I’ve estimated that our current model will support up to 200 people without having to change. Squads typically need to be 4-6 people so if you have 200 people you end up with 30 squads, which is too much to stay aligned. So at that point you would need to implement a few groups to fix that.

One thing that I have observed is that the collaboration inside the group, meaning between squads tends to be very good. But across groups is not very good because they work in isolation. So the key is to build groups that are relatively fine to be isolated from one another.

So how have you structured Wayve’s engineering function?

Right now, we have three groups. Driving Intelligence, which is pretty much all our research and development on the core neural network. We have Fleet Learning, which provides simulation validation, infrastructure, data and scaling through training and compute. And finally Embodied Autonomy, which covers the robot, fleet data capture and live testing on the street. We’ve named our Groups based on a human because of our thesis of trying to learn like a human; intelligence, learning and the body.

You seem to be quite aware of accountability and you’ve said that flat models don't really work. Minimal layers seems to be quite a desired model from a lot of founders so I’d like to know what drives this view. What have you learned about the failures of that flat org thinking?

With flat structures you create a shadow organization and don’t acknowledge the organization that actually exists. You can say everything is on the same level but in reality an organization will appear in the background. Some people will just know more about some stuff which creates influence and decision rights and power. It's better to make things explicit instead of making them implicit. 

If you have a Squad Lead and a Group Lead placed at the same level who is accountable for a project? It should be the Squad Lead but if these two people disagree then you hit an impasse. That's why you need to have a slight slope in power; just enough to enable dialogue and disagreement as peers, but enough to have clarity of who is responsible for a decision. 

One of the initiatives that I'm going to start doing is an open Q&A with each squad. Right now I don't have the time to talk to the 70+ people that we have on a weekly or even monthly basis. So I’m going to start holding sessions and allow the full company to ask me anything that they want, and I will try to answer to the best of my ability. This put me in trouble in past roles because I've been way too transparent, but I find that it's a good way of being real and not some mythical figure that leads engineering..

I've done a few of these conversations already and one theme that's come up is the risk of functional friction within an organization. You know, compliance vs. sales or marketing vs. sales, or maybe product vs. engineering. Obviously it’s extremely dependent on the company but I'm curious if you experienced any of that having gone through a few different iterations of engineering in your career?

Yeah, Product and Engineering is the classical one. Obviously, I'm coming with the perspective of an engineer so I'm biased on my response. My view is a Product Manager can make or break a team, there is no in between. I’ve had some great PMs and some very crappy ones, so I feel quite confident in that view.

They key is to not think of function dependencies as actual dependencies but instead as a common goal. I find this a more productive and positive mental model. In the end all that really matters are the responsibilities that everyone has towards that shared goal. Once you can align what the whole team is trying to achieve the conversation becomes much more clear. If you have a guiding principle, as a company, usually these problems resolve themselves. Skyscanner had very strong principles in always thinking about the user. Every conversation like this always came back to, “how are we making the user’s life easier?” 

Back to the org chart, if you don't have separate functional teams; for example a group that has 40 - 50 engineers and only two - three Product people, don’t make them outcasts. Make them part of the team. With Wayve this is kind of the norm because we have to deal with hardware, software, electronics, mechanical, etc. We have applied scientists, research scientists, IoT experts. It's easier because everyone just needs to collaborate. Of course you run into another risk, which is you have a lot of single points of failure...

When you have so many different disciplines and such a complex product, how do instill excellence? Obviously you can't do it yourself and you need to remove yourself from delivery as much as possible. What is your approach to making sure that that all fits?

This is a challenge because instilling excellence a lot is about how you reward excellence. It's how you get people to understand what good looks like. With smaller companies the budget you have is the budget you have. You have limited resources for raises or bonuses so how you deploy them is very important.

Being public about things is also important. Every two weeks we publish a newsletter inside the company with the achievements and metrics and in it we usually call out a “Super Surfer”, which is someone that has excelled at what they're working on. That helps because you are celebrating who has been more successful as you define it. 

One thing that we did that Skyscanner that I would like to implement was something called Sky High Awards. They were £50 Amazon vouchers and anyone could nominate anyone else for something a colleague did that was out of their scope or above and beyond. To be honest, £50 is way less than what we needed to pay for overtime but it meant something to people and it was public which compounds culture. 

And then you need to be smart about when you promote, give raises or increase equity. This actually brings me to another topic which I’ve been thinking a lot about lately. Wayve is about self-driving first and a startup second. Joining Wayve isn’t about joining a startup, it's about joining the  self-driving challenger to the rest of the industry. When you filter for that you reduce a lot of the compensation and limited resource challenges because you’ve filtered for the right people at the start.

One of the most frequently asked questions from the founders I reached out to in preparing for this interview was on the unique challenges that come from having both software and hardware experts. When you introduce a hardware element to a startup there are suddenly loads of new challenges. How do you now approach that?

So there are a few things here. I was talking with one of my hardware leads recently and I asked him, “what do you need from me really? What can I be doing better?” and he said, “Pablo, when I need to make a $1 million purchase decision I need to have the confidence that you are going to help me make the right choice.” That requires a level of knowledge that I may not have currently have but I need to. In order to support effectively I need that person to trust that I understand the decision at hand.

On hardware and software, I’ve had to learn that you can't roll back so easily in hardware. You need to make decisions much earlier. Lead times suck but they are what they are. Some things I’ve learned in software just don’t apply like, “don't put yourself in a corner, try something fast, prototype.” You can't really apply that hardware. If we find a solution and it’s going to take three months for us to get this hardware then go for it. If over the next month we discover something that makes the decision invalid, we just have to cancel the order and assume the cost. The cost of waiting is bigger than the cost of cancelling an order. 

So it's about aligning the two disciplines and understanding that software is always going to be faster than hardware. I mean there will always be delays in engineering. Never in my life have I seen a deadline that’s met exactly to what we plan. But in general, you don't want hardware waiting for software. Software can move faster and you just need to get comfortable with that cycle.

What makes a great VP or Director of Engineering major? Maybe that's personality or skill set or experience?

I tend to believe that I'm atypical on this because I tend to spend way too much time on team health and less on strategy. It depends on the circumstances but I think the biggest problem is ensuring that your people are doing their best work. The moment that a Squad Lead decides to leave the company because they are not happy or gets burnt out is when you suddenly have a massive setback. For early stage companies, having a good grasp on how people are feeling is the most critical thing that you, as a leader, can be doing. 

You really can’t afford to get detached from the day to day, but of course doing that means you will need to absorb a lot. I still don't know how I haven't gone crazy with the amount of setbacks that get dumped on me day in and day out. Usually people only come to me with problems and tackling all of them requires a lot of mental resilience.

And presumably because you naturally lean towards people stuff, you get even more. It's a self-reinforcing cycle in a way.

Yeah, true. It’s also important to understand that most people want empathy and not sympathy. Anytime that you're in a leadership position, don't tell your people, “It’s okay. This will pass. It will get better.” That’s not what they need. They want you to listen and they want you to empathize with them. They may not be even looking for advice. They just want to know that there is someone else that will listen to them. You don’t always need to offer solutions. Telling them it’s going to get better doesn't help at all, because that's an empty promise.

I find a lot of founders I work with really get caught up in the title game. And I feel like it creates a lot more mental drain than it probably should. How do you separate the responsibilities of Head of Engineering, VP of Engineering, CTO, etc.? Instinctively what separates those roles to you?

I tend to think that what you do is far more important than what you’re called. I’ve joked in the past that they can call me janitor if they want. When I got the offer to join Wayve it was for the Director of Engineering, because there was some uncertainty about my experience vs. the other candidates who had already held that title at big tech companies. In other words, they were more experienced than me. To be honest this title weighed on my mind and became the main sticking point for me accepting the role. That is until I realized that I'm going to do the same exciting things regardless of what my title was. Don't get me wrong, I would love to be called VP of Engineering, but in the end it doesn't matter much. 

Engineers are typically the first hires that any founder has to bring on and most are excited about that because they love working with engineers. At a certain point, founders need to hire more of an Engineering lead, ignoring title for a moment, to pick up a lot of the managerial burden. That seems to create a lot of resistance. What do you think that most get wrong about hiring an Engineering Leads? 

I very much prefer promoting from within vs. bringing in someone from the outside. Cultural fit is critical and while we have brought in external hires, I believe that trust is more important than skill to an extent. 

If you have to bring someone from the outside you need to not drop them in the deep end right away. With a couple recent engineers I’ve given a technical project at the start. I’d tell them, “focus on this, don't focus on management. Once you’ve been here two to three months and you've built some relationships, we can think about what’s next.” In general I think a leader needs to lead with trust and if you put them in a position where they need to start challenging people right away it’s not good. This happened to me when I joined Wayve. The first weeks and months people were a bit like, “Who is this person? What are they going to do? Why are they here?” 

So because you operate with this “ramp up” methodology, when is the right time to bring in a new lead or management layer?

When you realize that you're not enjoying what you're doing. If you're a founder you should be enjoying every single minute of your time, because frankly you need to if you're going to make the thing succeed. If you don’t you’ll fail, it’s as simple as that. The moment that you realize that you’re being asked to have conversations or solve problems or whatever and you don't want to, you need to get someone in. Usually this happens when you expand beyond the core group of people that you hire over the first year. Before that you probably don't need any layers because everyone is super invested in what they're doing. 

For bigger startups it’s probably driven by critical mass. Whenever you realize that the teams that should be three people now are now seven and still need to grow. When you start thinking about splitting teams to be more effective. 

I wanted to end with a hiring speed round. I'll give a trade off and you give me your immediate, reaction is. So in terms of hiring, where do you stand on:

• Experience vs. Ability?

  • Ability

• Hiring for immediate pain or predicted issues in 12 months?

  • Immediate pain

• Hiring for software and hardware engineers?

  • It's more difficult to assess practical ability with hardware. You need to lean a lot more on their previous experience.

• Best hacks for hiring?

  • When someone has a very short experience but they have been promoted very quickly that means that that person is potentially a very good learner. You may find that they were just playing political games, but you can find out very quickly in an interview process. If they were not playing political games and in three years they rose from an intern to senior software engineer that’s someone that you want to interview because potentially they’re very good. The opposite applies too. If someone is a senior software engineer after 20 years in the industry, they may be strong but chances are they don't have that growth potential that you’ll need.

---

First On is an attempt to uncover functional greatness by asking the experts themselves. I hope you enjoy the mini-series and with enough interest I may extend this into a more ongoing effort. If you have any functions / roles you’d like covered or have ideas for future guests please let me know.