Drone software and cognitively diverse remote teams with Eric Hauser of Drone Deploy

Ledge: Eric, good to have you. Thanks for joining us.

Eric: Thank you. Happy to be here.

Ledge: Can you give your quick biography in a couple of minutes on you and your work, let the listeners get to know you a little bit?

Eric: Sure thing. I’ve been doing software engineering my entire career. Started out as a developer and built some full stack applications and backend applications. Was doing that for the first part of my career, and then jumped into the engineering management realm. Always was jumping back and forth and, about seven or eight years ago, I went into management full time and had an opportunity to work for a few great companies since then.

I’ve worked for a company called ExactTarget, which was probably the first marketing cloud company that existed. We IPO’d in maybe about 2012. They got acquired by Salesforce. I spent a number of years at Salesforce running their IoT engineering initiatives where I had an opportunity to work with some really great people there.

Then a couple of years ago I took over engineering at a company called DroneDeploy, which is a Series C startup here in San Francisco focused on bringing intelligence to job sites through the use of drones and aerial imagery and other assets.

I’ve had an opportunity to do a lot of engineering and really enjoy the space, enjoy working with people and enjoy building cool things.

Ledge: Talk about the IoT stuff. I’m just interested, I’m sure everybody wants to know, what’s the actual stack that goes into the whole drone business? I think everybody a couple of years ago for Christmas wanted to get into drones, and then commercial really started to take off over the last 15 months maybe.

I’m curious what that looks like. What’s the full stack and the technology deployment look like to make that actually work on a commercial scale?

Eric: The drone hardware has really come along very quickly over the course of the last couple of years. When DJI released the original Phantom 2, that was the first quadcopter that was really available and could be used on a mass market scale. Since then, DJI has continued to enhance the drones in the space. To the point now to where you can get a drone that can be used commercially for relatively inexpensive. I think the Phantom 4 Pro runs about $1,500 now, and you can buy them at Best Buy and all these other places.

At DroneDeploy we’ve been lucky. The company really started on a strategy where they basically saw that the opportunity in the drone space was in software and not in hardware. There were a number of early startups in the space, such Airware and 3DR, that were also focused a lot on the hardware side. DroneDeploy always saw the opportunity as more of a traditional SaaS business in the drone space. We were lucky to have a great partner in DJI that we work with to deliver a really great end-to-end experience. We also process imagery from other drones as well.

Generally speaking, kind of the stack and the way the we think about the drone space is, there’s really three steps; the flight aspect, processing the data and then analysis of the data. In the analysis side you think about reporting and analytics and all those general things.

To do all of those things is actually a fairly complicated tech stack, which was one of the things I learned when I arrived at DroneDeploy. We have a mobile application for both iOS and Android that we support for basically flight out in the field, that allows pilots to go out. Effectively, the way that it works is, you walk out into a field and you draw a box around an area and you hit a button, and then the drone does all magic. It takes off, grabs its assets, it comes back and lands at your feet. Anybody can effectively capture data with DroneDeploy.

We process a ton of imagery. I think we’re somewhere in the range of approximately about 8 to 10 million drone images a month. So when you think about each one of those images, generally like a 20 megapixel camera it’s about 7.5 megs – the photo would be. We have in the range of about 4 petabytes worth of drone data today.

We process all of that data in order to make maps. When somebody will send us anywhere from 50 to up to 10,000 of those images, and we actually stitch all those together into a map where we create 2D models, 3D models, digital train models, digital service models and a ton of other interesting assets that we can create from that data.

That also requires a lot of processing horsepower to do that, and so we can have a whole entire discussion about that.

That’s kind of the general overview of the stack. We can dive deeper into some of the technical details as interesting.

Ledge: You’ve got the onboard camera. Is it wireless or no? You have to take the media out of the drone, or how does all that work?

Eric: There’s actually two ways that that works. We offer an edge computing map generation. One of the things that we can do is we can actually capture the data live from the drone. While the drone’s in the air, it comes over a radio signal. You can capture up to 1080p imagery from the drone off of that – which is a much lower resolution than what you could get with the actual photos that are captured because the photos, they have cameras… The standard camera is generally about a 20 megapixel camera. Those get saved onto the SD card on the drone, and then when the drone lands we can wirelessly take the data from the SD card, transfer it to your phone and then upload it to the cloud – which works for a smaller number of images.

If you are running a mission where you’re trying to capture in the range of thousands of images, it’s going to be faster for you to take that SD card home and upload it over your home internet connection.

We call it Live Map, is the name of the edge mapping solution we have. It’s great for getting the data there in real time in the field and you can see that. But for people who are looking for very accurate representations, like measurements and things like that if you’re trying to measure the volume of a stockpile for instance, that’s where the server side processing that we do to process those maps is more accurate.

Ledge: You use public cloud on the backside when you’re doing the server processing?

Eric: We do. We work with both AWS and Google Cloud. Both of those providers have some characteristics that we like, and some strengths in certain areas. DroneDeploy has always been a very heavy Kubernetes shop even before I arrived here, and we process somewhere in the range of about 150,000 Kubernetes jobs a month. For that workload, we run that on top of GCP in Google Kubernetes Engine.

We’ve been really impressed with where GKE is at versus the rest of the marketplace. We run an autoscaling cluster in GKE to manage all of those jobs that are creating constantly spinning up and tearing down nodes. Have been running that on GKE this entire year with a lot of success and not a lot of maintenance from our DevOps team, which has been phenomenal for us.

We’re having a pretty hot ratio of engineers to DevOps. It’s about a 15:1 ratio on engineer to DevOps, which is a hard ratio to manage but we really would prefer to have our engineering team building features for our customers as opposed to building internal Ops tooling.

We’ve been lucky that some of the managed services from the cloud providers have come a long way in the past few years, and we’ve been able to adopt and use those as a strategic advantage for us.

Ledge: Any serverless needs or workloads that you’re dealing with? That image recognition, anything of that sort?

Eric: We do have a few serverless workloads that we’ve deployed. I think serverless as a technology has a ton of promise for certain use cases, but other use cases I don’t think serverless is quite there yet.

Ledge: So you mentioned you’ve got 50 engineers, maybe half of which are remote. Tips and tricks and things that matter to you from a remote workforce standpoint?

Eric: Yeah. Remote’s been interesting. It’s been a key strategy that I’ve been able to apply as I manage some teams in the Bay Area.

One, I think one of the great things about introducing remote people into your team is, you really have the capability to go out there and get the best. It doesn’t really matter where that person is geographically located. I’ve had an opportunity to find engineers who work in the most amazing random places that you could find, and I think that’s the key, that talent is really everywhere.

For me, one of the great things that also too with , I talk a lot about diversity with my team, and I think traditionally when people talk about diversity in tech they’re really talking about what are your diversity metrics. How is your team in person.

Really the thing that I preach to my team is cognitive diversity. We really don’t want a bunch of people on the team who are all thinking the exact same way and have the same hive minded approach to problem because our users aren’t like that. Our users are diverse. We have users in construction and agriculture and mining, and who come from all varieties of backgrounds.

It just so happens also that, when you need cognitive diversity it really helps if you actually have diversity in other areas such as ethnic and gender diversity and stuff like that because that also makes up your users.

Really, it’s about making sure that we’re not thinking the same way and that we’re designing software for all users. That’s something that we talk about.

The remote team I think is phenomenal. We try to bring the remote team here four times a year to work with the entire team. We call it an onsite week. Every single person on the engineering team says that’s their favorite week of the quarter, every quarter, because we’re able to get everybody in here working together. We do a bunch of events when everybody’s here. We start to do some planning for the next quarter. It’s really worked out well for our team.

Obviously, the downsides with remote engineering is that you miss what everybody calls the water cooler conversations, where you just happen to be walking around. So we try to do a lot of things around collaboration there where we share things and Slack and have more discussions there.

I do think that there are some challenges with Slack that the industry will eventually come around to. Slack can also be a distraction. If you’re constantly expected to be online and responding to people’s Slack chats, then it’s going to distract you from the work that you’re trying to do.

I actually found a huge benefit to my personal productivity when I turned off all Slack notifications earlier this year – something that I’ve been suggesting to a lot of people. It’s pretty rare somebody will send you a Slack message and it needs to be responded to right away. If you start to think about Slack more like email, asynchronous workflow as opposed to real time, it actually starts to work out pretty well. But then you’re still going to have that information sharing aspect that you get with it and you can read it on your own time.

Ledge: It comes down to often going, I’m going to do Slack during these blocks of time and otherwise close it and answer all your messages and all your reminders. It ultimately isn’t that different than the way you really should discipline your time management, regardless of tool. You could sit there all day and reply to messages, but you wouldn’t get anything done.

Eric: Exactly. I turned off all notifications and I actually hide my toolbar on my Mac so that I can’t see when I have any that have come in either. It’s worked out really well from an avoiding an interruption standpoint.

Ledge: I ask everybody. Obviously, we’re in the business of evaluating and bringing on the very best software engineers, like you said regardless of geography – although it does skew very heavily in the US. We have a really rigorous system. All levels of interviews and tests and reviews and reference checks. Yet we know there are a lot of heuristics out there.

I like to ask all the tech leads that we have on, what are your heuristics? How do you guys evaluate the very best engineers that you want to add to your team?

Eric: For me, when you’re interviewing somebody, the simplest way that you can figure out if somebody’s going to be good at their job is to give them an opportunity to do that job and see how well they do. Obviously, there’s a huge demand for engineering talent and so you can’t just bring somebody in for a week and let him work in your environment – although I’m sure some people try to do that. It’s generally pretty hard because most people have jobs.

So, we generally do a take-home test as the first step, and we try to make that take-home test to be fairly lightweight. Maybe you invest about an hour to two worth of time in that. That next step in that process is that we’ll bring somebody in and we’ll just do some pair programming with them.

We try to avoid any sort of whiteboarding type interviews. We bring in some students from Hack Reactor type programs to DroneDeploy and we help train them for whiteboard interviews, because we want to do something good for the community. We are not fans of whiteboard interviews but a lot of companies are doing them, so we’re trying to help those people out so that they can go out and be successful when they do interview.

Through that take-home test process and the pair programming, it lets people do the things that they would normally do when they’re coding. Which is, look up stuff on Stack Overflow, which I’m doing all the time when I’m programming, and that doesn’t mean that I’m not a successful programmer.

I think through that process we’ve been fairly effective in finding candidates who fit our workflow and those initial steps. Then obviously we do the standard normal person-to-person interviews after those steps.

Really the take-home test and the pair exercise have really been keys to us finding good people.

Ledge: It’s not all about the technical, I imagine. What are the soft skills and such that you’re looking for in that process that you’re going to bring out?

Eric: I always tell people, the most important thing about when you’re working through some sort of problem is not necessarily that you immediately come to the right answer, it’s talking about how you’re actually coming to your conclusions. There are some engineers who will go and get a problem and they’ll think for five minutes and not say a word, and then just write down the perfect solution. That’s great. That’s okay. There are very few of us who can actually do that. I would not to include myself as one of those. Basically, what you’re try to do is you work through that.

We preach a lot of soft skills here. We’ve gone through a few cycles of growth here as we kind of ramped up to about 50 engineers. My team at Salesforce was much larger than that in the size of a 3500 person organization.

The thing that you really learn is things like collaboration and alignment and stuff become very important. Can you take some semi-critical feedback on a PR and turn it into a positive discussion? Those are the types of things that you’re looking for there. Really, through that pair process, you get to see some of those things; how this person thinks, and can they describe to you what the next steps as they go to figure out a problem?

We definitely look for those things. We have some internal scoring criteria that we use to judge that.

Ledge: I talked to another CTO that, one of their steps in this process is they issue a PR to the candidate in order to see how they will react, and give the feedback for what is obviously wrong in the PR.

Eric: We’ve done that too, and I think generally the only issue there is what happens is all of your take-home tests become public – unless you want to give somebody access to a private temporarily, and then you have to keep writing more take-home tests. So we’ve stopped doing that. We’ve used other tools. That’s would be one of the best ways to do it, for sure.

Ledge: Awesome. Well, Eric, good spending time with you. Appreciate your insights today.

Eric: Yeah, great. Happy to talk to you.