Building Global Engineering Teams with Will Kessler

[MUSIC] >> Okay, so hey, everyone, and welcome back to a NASA episode of Default Global. This is where we connect with Global First Entrepreneurs and remote work experts from all around the world to share their experiences. Our guest today is Will Kassler, former product and engineering leader at Sidecar. Will, thanks for joining us today. >> Thank you, Will. Pleasure being here. >> Sure. Well, you've had remarkable journey from building the engineering team at Udacity, the leading product development at Sidecar. Could you give us a brief overview of this journey? >> Sure, sure thing. I think I could start off by talking about minting one of the jobs I had about 10 years ago. Minted was an e-commerce company that was just getting started. So when I came on board, it was just the two founders, no product, no team at all. And so what I needed to do was quickly build a product and build a team against a pretty tight timeline. And the founders were used to an agency where they could just immediately surge a lot of engineers onto the team. But we didn't have an agency. So I think at the time I was pretty seduced by the latest RRM, the latest web building technologies. And I was pretty convinced that I could build this product mostly myself at the same time, higher engineers. And that was a big mistake I made because it takes a lot of time and energy to hire good engineers. As a result, we shipped late. And we were five weeks late. And I think the lesson I took away from that was you really shouldn't do both. As a leader, you should focus on building the team and get that team going. And remember, it takes time for your team to interview, even after you hire a few people to interview new people. So you've got to fix that in. If you're open to hiring remotely, you might be able to accelerate this process. So that's something to consider. And I didn't think about that back then. From minted, I worked at another company you may have heard of called CrunchBase. And CrunchBase at the time had a team existing, but it didn't have very good team management. And there was a deadline for CrunchBase 2.0 that already slipped by six months. So they brought me in to try to better manage the team and bring this product to market. So the first thing I did was talk to every single engineer and figure out, maybe we needed to reassign a couple of engineers to another group. Maybe a couple of them were just bad apples or not. We're pulling their way. They were pulling down Team Moral. And so in that case, we did a little bit of cleaning house. And then I brought the remaining team together in a room for six weeks with a deadline where we were going to demonstrate the new version of CrunchBase to the president of ALL. And just having that figure head there waiting for a live demo was really motivated to the team, bonded the team together. We even put these big postings on the wall on a calendar where they could physically pull off their tasks as they did them and the whole team could see them doing that. And that was a great motivation. So the lesson there was you need to make sure that your team is bonding well, is well connected and is communicating well and supporting each other. I also worked at a company called Power Reviews. And Power Reviews was a great fun company to work for. The much larger team, I was overseeing four different teams. The engineers loved it there. It was very chill atmosphere. It was very relaxed place. But they still shipped, which was good. Their problem was poaching. So a lot of people there had good solid degrees for computer science from great universities. They could easily go work at Google or Facebook. But they liked it at Power Reviews. They just liked the atmosphere there and the culture. But the coaching was happening a lot. So a lesson I learned there from my boss was you need to take one on one with your engineers really frequently and don't let that lapse. You need to listen to them. It takes about six months before you really get a rapport with an engineer and they trust you to open up. Sometimes they're there because they like working there, but they also have a side project or a side hustle that they're excited about. And you need to be supportive of that. Otherwise you'll just lose engineers to the big fan companies. And in fact, you need to be hiring constantly. Even if your team is fully filled out, just assume that people are going to leave. This is the tech world people come and go. And you should always be interviewing and always be preparing. So they had an extra budget just allocated for a little more than the staff they actually had. And I think that's another case where if you could augment your team in some way to buffer for those losses to thing, I think that's really valuable. And I guess the last experience I wanted to share with you was at a company called Cloud Labs, which had a product called Terminal.com. And this is another case where I was brought in into an existing team. But this team was pretty dysfunctional. They were very talented. They were all rock stars. And imagine a team of 12 all rock stars. They don't get along very well because they all think they're the best. And they shouted each other down during meetings. They would interrupt each other. There was a ton of sexism going on as well. The female engineers in the room were never even going to get a chance to finish their sentence, but what they were trying to say. And so I was brought in to try to fix this dysfunction. And some of the things I tried there is to set some ground rules. For example, you have to raise your hand like in kindergarten when it's time to talk in a meeting. You can't cut anybody off. And again, look if see if there's any engineers there that are creating kind of a bad feeling in the company and let them go. And then finally, celebrate with Rins. What did you ship? Did it work? Or are people using it? Get the engineers in touch with the customers and less squabbling amongst themselves. At the same time, focus on product market fit. So this is a company with a great product or great technology, but they didn't exactly know how to sell it or who to sell it to. So I spent a lot of time working on that as well. So the engineers can begin to connect with why they're building something, not just what they're building or how they're building it. And so that was an important lesson to us to make sure the engineers are connected to why you're building something what the market wants. So it seems to me that you have a lot of experience with, let's call the expansion of the engineering teams in different companies. So under your leadership, it was significant with each of companies that you mentioned. So how did you initially approach the challenge of integrating team members, especially I'm interested in those cases where you had like a distributed teams, maybe different cultures, different time zones. Can you talk more about that? For sure, yeah. Yeah, at the first time, I really got a lot of exposure to that challenge of distributed teams with that Udacity. So Udacity is an ed tech company that's based in Mountain View, California, but it has offices all over the world. There were engineers in South America, engineers in China, and a lot of challenging time zone issues to overcome cultural barriers, communication challenges. And so that was a case where I worked at Udacity because Udacity actually purchased cloud labs. So I took the 10 engineers that I still had at cloud labs and integrated them into this very distributed, fairly remote set of teams that Udacity had. And that was tricky because they had their own technology at cloud labs and their own processes of the product. And now you're putting them into a group of engineers, a 55 engineers, that also have their own technologies and how do you get them to mesh and get long and accept that their technology isn't necessarily the best. It's just a solution. So first off, it meant you needed the engineers to get to know each other. And a lot of social functions helped. For example, we would do brown bag lunches every week or every other week. And those were presentations where the engineer would bring some cool technology or hobby or something to the team and share it with the group. And that just was just to get people to chat more casually rather than always in a situation where it was work related. The other thing is to do a fair number of retrospectives and demo days and have the engineers just show off what they were working on more frequently. And that really helps too because you get into a situation where people are remote and they just work, they ship, they put their PR in and then they go out of the next thing and they don't get any acknowledgement from their teammates that, hey, I built something and this is how it works and I'm proud of it or maybe I need your feedback. And so that is another way you can get engineers to begin to come together and bond more. Another thing I think that's important is the design team is a valuable resource you can leverage for bringing these remote teams together because the design team very often will work on a design that sort of hand you the spec and Figma and then engineers just go and build it and they get frustrated and they get disconnected and you have one engineer in China, one engineer in Brazil, another engineer here in the States and they're all working on different pieces. They don't feel at unity but the end product has to feel holistically unified. The customer doesn't care where your engineers are or what they did to build it. They just want to feel like it's one product that works in sync together. And so your designers can help because your designers can enter into a conversation with the engineers and the product managers to really help the engineers engage in design, engage in product discovery and design. That whole process of figuring out what makes customers get their job done and what their job is to be done and then how you're going to do it is a big part of the process you don't want engineers at the tail end just executing. You want them to be involved from the beginning. We did a lot to engage the engineers that way. That was very helpful I think. And now to think the last thing I would say is when you have distributed teams the time zones are really challenging. At for example, my latest venture side car we had an engineer in India and several engineers in South America getting a stand up or scrum time that works for everybody is really challenging. And sometimes you have to bend over backwards to make sure that California engineers or East Coast engineers can come to the scrum. It's really important. If you don't then you end up with siloed teams you'll have your South American team working on one chunk of their own whole product and then maybe your Asia team working on a whole other product chunk and they don't work together. And a lot of technologists will say, oh well we'll solve that all with microservices and contracts and whatnot. That's true technically but it's not true from a product perspective. From a product perspective it shouldn't seem like I'm going to a completely different website or completely different app if I just want to get something done. So I think that's another thing you can do and I think lastly hackathons are great. This sounds a little bit silly and old school but hackathons are great where you basically say okay we're going to spend a whole weekend cranking out a prototype of something that's been plaguing the company forever like an internal control panel or a cron job process that's way too slow. Whatever it might be get the engineers from different locales working together that way and it's amazing how quickly they'll begin to mesh and bond. Yeah that's true and let's go back to Udacity for a sec. So Udacity is global first company right as Glacier mentioned there are a bunch of people all around the world that work there. So was there a particular project or maybe product at Udacity where the global team's input was essential to its success maybe from the product point of view or from the engineering point of view. Certainly so the challenges Udacity being a learning company the challenges are in creating courseware and a learning environment that works for these different cultures is very valuable. So for instance you can't just take a course that's written in English and recorded in English and translate to Chinese and expect that to just work. You can't just slap subtitles on there and think it's going to be great because the way Chinese students learn and what they're used to in their system could be considerably different from the United States systems. We saw that in the case of India as well. We had a team in India and in India there was a mentoring product that we had. The mentoring product would bring mentors together with students but in India there's a cultural difference in the way you interact with a teacher and that is to say you might need information on something but you ask for information that's totally unrelated that you may already know just to establish a rapport with a teacher. And so they'll ask three or four questions to which they know the answers are ready and they get the answers back from the mentor. The mentor thinks I'm doing great. I'm answering all these questions without realizing that's just a preamble. So your system needs to factor that into it's a cultural difference. You need to factor that in and say all right well we can't just allow one minute per question in India maybe we need to allow a minute and a half or two minutes because the real need is not coming up until the student feels comfortable enough. And so you need to be aware of those having local teams for example the India team was able to share this with us and say hey this is the way Indian students learn. And in China too, hey they need more extra more written exercises or they need their use to a grading system that's different we need to modify the product. So those remote teams can give you that feedback on your product that's really valuable. And sidecar you were in charge of building an engineering team right and that's basically where we met as it was to help sidecar to find engineers in all the time. Exactly. Was that in mind what was the initial motivation behind expanding your team to a Tom? Yes, that's a great question. So at sidecar again there was no team at all when I started just a couple of founders in the CFO and I learned from minted first of all that if we were going to keep to the timeline that they wanted the founders wanted we would need staffers right away. Fortunately I had a friend with a small consulting agency on a few engineers that would immediately start while we did the process of hiring. I also took this lesson away that hey I need to focus on full timers and hiring for full timers. And so the team that was the contract team was able to get started on the product for the first four or five months get something built that we could get into the hands of customers with starting feedback while I focused 100% on hiring. At some point though we realized that the full timers in the US were taking a very long time to hire still. And what we needed we needed senior engineers and there are great senior engineers as your team is provided to us. There are great senior engineers in remote locales that are reasonable as far as cost that are very talented that speak English well that are used to working for US companies that are available more rapidly than the US-based engineers. So that's where I think Latin America engineers became attractive. Also the other thing is important is this time zone like I mentioned before. So we did have a couple engineers through the contract agency in India and that 15 hour difference was quite difficult for them. They can't sustain that for that long where they're working on US time. For a certain point they have families and commitments and they need to sleep when it's dark. And so you get into these disconnects that's difficult with those time zone differences. Whereas with Latin America the worst case for California is five hours difference. The engineers can make that work. And then there are some advantages as well that I hadn't considered when we started hiring which is that once your product is up and live and running then you need probably some kind of on call system where engineers can be available to fix any problems that come up. The great thing about using engineers in Latin America is that they can take that morning shift without sweating at all. And then the US engineers can come in nine or 10 a.m. there at time and the South American engineers can go offline. So that you get more coverage especially for a fintech where the business needs to start at 6 a.m. Pacific. Right? Because on East Coast that's nine a.m. And that was really a hidden value that I hadn't seen. Yeah, and speaking about the recruitment and hiring itself. So can you talk more about your hiring strategy in Latin America? Was it different in terms of maybe requirements or process compared to your hiring process in the US? Did you adapt this process somehow? Little bit. I think we also did a few more checks that we might have done for US engineers. The communications, like for example, our process was to start with an initial interview that I would have run and then my director of engineering would run a secondary interview which was more hands on. But that first interview was a culture check and a communications check. And I'd give them a little problem just to talk through an engineering problem and I was looking for communication skills. And I don't just mean that they spoke English well enough, but that they were listening to the problem. They were asking questions about the problem and clarifying them. And this is more of a cultural thing, maybe than a command of English thing. If they don't feel comfortable asking questions, maybe pushing back a little bit, maybe saying, hey, what's the most important thing for us to build on this problem? Then that's not going to work very well. And what I noticed with Latin American engineers, and how now having worked with them for a while via your firm, is that they have, they can sometimes be a little bit on the macho side where they're just going to work it and do it no matter what takes a never-complain. And that's great if you're on a deadline. But for a long term sustainability, that's not so great, right? You want your engineer to say, hey, this needs, this is kind of hard. I need help and raise their hand and not just keep on battling and battling all by themselves. So I saw that more with Latin American engineers than I've seen in other countries. And it was just something to adjust for. I would check in more frequently with them on this front and just say, hey, you've been working on KYC for six months now. Are you burning out? Are you, do you want another engineer to pair with you on this? And a lot of times at first, no, I'm fine. It's great. I got this. I'm, I can handle this. And eventually they start to open up again and say, okay, you know what? I could, I could use a change. And speaking about that. So aligning and motivating teams across different like time zone, geography, cultures is a complex task. I know this for sure because I have teams in seven different countries and we are in 22 different countries for our clients, right? So what specific leadership technique have you found most effective in your role at sidecar? Can you, can you clarify the question, like what, what sort of leadership technique in terms of managing the engineers specifically or the different teams? Yeah, I mean, like you should put this team kind of together, right? You should maintain your international team harmony and focus. So did you use any specific practices or you have some own techniques for it to do so? Sure. Yeah, absolutely. So one of the things is that in today's very remote world, people are working from home and here I am, my home, it's pretty isolating. It's very valuable to bring engineers together. Now, at the Audacity, the CEO at one point said, hey, we need to bring everybody back into the office because that's where the magic happens in the hallways. I don't believe that that's necessarily true. I think it's great that our companies today are more distributed and that people can work from home if they want to. But it is isolating. You do get lonely. And if you're in a remote locale and the company's headquarters are far away, you can also feel like your FOMO feeling. Like I don't know what's going on. And once you get really invested in your company, then that you're working for, then that feeling can be very destructive to your morale. So what I'd like to do is bring the engineers together physically. So we've, we've, at sidecar, we had at least twice a year a get together where all the engineers, initially when the company was younger, we could bring all that, all that in place together. But after a while it was just engineering and product, bringing them together in a physical locale. We were going to do one for example in Mexico City. We did a couple in the US. We were thinking of doing it in South America as well. And either fly US engineers to where the Latin Americans are or vice versa. And I think that even bringing them together for a week is hugely valuable. Just a handshake, getting a room, have a couple of drinks, talk, look at code together. That's very important because people feel a lot less isolated once you do that. The other thing I would say is that, you know, you have to be sensitive again to just a harp on this time zone thing. A lot of times I think US companies will just say, hey, we're going to do our, our stand-up, the first thing in the morning, 9 AM without realizing that's already 2 PM for an engineer in Brazil perhaps. And so that engineer's halfway through their day. They don't even, they're reporting on what they've already worked on. They're not reporting on what they're going to do. And so you have that disconnect. It's pretty important to figure out what's going to work. Maybe you can flip back and forth, do some late day stand-ups, some early day stand-ups. Maybe you can do some of the stand-up in an asynchronous way with a Slack channel. But you need to work through that and figure out how do you support those remote teams better. And another thing I'd say too is that it can happen that the remote team, once you hire enough people in a remote locale, they will start to act like a unified team. And if they act like a unified team, you want to avoid any kind of turf force that could happen where it's, oh, the Latin America team was working on this service and they just own it. And we don't know what they're doing. Because now you've got the opposite effect where US engineers can feel like, oh, I don't, I don't know what they're doing, but I don't like it. I don't know who to talk to. And so I think it's important to potentially fly your engineering manager to the remote locale for a week or to consider hiring an engineering manager in the remote locale who can work tightly with your US PM and your US EM. Yeah, it totally makes sense. In terms of international recruitment, what have you learned from your partnership with it was global, it was international talent acquisition agents who let's put it like that. And something that could be maybe valuable for other tech startups and global first companies. Can you share something? Sure. I think one thing to consider is how many engineers or people you're going to hire in the remote locale and just be aware of conditions and constraints in that country. If you're going to hire more than a few, then you'll have to consider oyster or deal or go below, it has a service that helps support their employment. And you should also be aware that they may need insurance coverage, they may need some other kinds of coverage that adds to the cost. So it might feel like, oh, I'm getting a great, a great deal here in terms of the cost of these engineers given their skill levels. And you got to factor in that overhead that you'll need to consider, especially some companies have a high tech level. Now it's also possible that if you just have one or two engineers and they're willing to take things in US dollars, they have a US bank account, you potentially pay them that way. But eventually that may run afoul of some rules that that remote country has in place. So you should be aware of that, I think. And not take risks, like work with Go Globie, work with your recruiter to make sure you're covered there. Another thing I think that's important is to think about how remote engineers look at US-based companies as employers. Right now we're in a tight economy. There's been a lot of layoffs in tech. So I guarantee you that these engineers working in foreign countries, non-US countries, are worried about layoffs. They're worried because the first thing to go is contractors and oftentimes US companies will make the first fires, first layoffs in the remote locales just because it's easier and cheaper for them. So they're nervous about that and if you want to get the best result out of these engineers, you need to motivate them and make them feel secure. So one of the things that I did at SiteCAR was offer them some equity. So not only pay them the salary that they're requesting, but also offer them something that they can work towards so that even if there's a layoff, they've at least earned some equity in this company that will benefit them in the future. And we also look carefully at other things that we're offering to US engineers, whether it's paternity leave or maternity leave, whether it's bonuses, whether it's special trips and many junkets if you will where they meet with the engineers, but we also spend a little bit to show them San Francisco or show them New Orleans. Something that makes it more interesting and exciting to work for the US company than just a job where they're just paying me and they can lay me off at any time. I think those are important to think about. And you want to check in often with those remote engineers. It's easy to forget about them because they're on different time zones and they just just check in, they do their work and they're doing a great job remotely. You can lose track and I think that's very important. You don't do that. Treat your remote engineers exactly the way you treat your US engineers with some potential differences on logistics and pay and how you handle insurance, but really there should be just an extension of your US team. Jessica, a question. Did you use CARTA to manage those equities with those contractors or did you use those too? No, no. Cycar actually competes with CARTA so we would never use CARTA. But no, so the Cycar has its own legal team and can handle all of that. The car transmission is just that to handle investment rounds and so we are very easily able to create whatever the documentation is needed for the remote engineers. Yeah, got it. Okay, cool. So then another question for leaders who are just maybe starting to manage global teams. What is the one piece of a device would you consider most crucial for them? I think probably what's most crucial is communication. This is so fundamental and it sounds kind of obvious and trite, but it's really difficult. If your remote engineer is having difficulty understanding what the engineers here are saying or vice versa, then you're going to spend a lot of time and create a lot of frustration. So I think in the interview process, it's really important to make sure that you're not just testing how well can they code, but how well do they understand what you're saying, what your engineers are saying. Now, I'm not saying, I'm not saying, oh, they shouldn't have an accent or they shouldn't have a limited command of English. You should have a very deep command of English. That's not strictly necessary. Sidecar, we had an engineer in Mexico who spoke English perfectly, with a perfect American accent. We had an engineer in Argentina who had a very thick accent and didn't speak English that well. They're both great engineers on the team. They both contribute really, really well because they're both listening, they're paying attention, they're asking questions and they are making sure that people understand what they're saying. If they have to try to explain it six different ways, they have the patience to do that. That's what matters. And we're, it's a global economy now and everybody comes from a different culture. Command of English varies widely and that's not as important as just can they communicate clearly. I think that's the number one thing. Yeah, that's a good one. Okay, it's been insightful to hear about your global team building journey and your experience with global hiring. So thanks a lot. Thanks a lot for your time, Will, and we wish you all the best in your journey. Thank you, we eat. It's a pleasure talking to you this morning.