Subscribe
Share
Share
Embed
Honest conversations with the engineering leaders, CTOs, founders, and engineers building real software with real teams. No fluff, no hype — just the messy, human side of getting great products out the door.
Zhenya Rozinskiy - Mirigos (00:06)
Randall, thank you so much for joining us in this episode of Built by Humans. It's a podcast that we started recording several months ago. The idea we talk about what it takes to build great products. A lot of podcasts out there talk about technology. They talk about tools. They talk about the best ways to get stuff done. We, on the other hand, focus on people. It takes teams. It takes teamwork. It takes communication. It takes really good hiring.
And that's what we focus on. The idea is how do you manage, how do you communicate within your team, outside your team, up, down, sideways, et cetera. My background, I actually spent about 30 years managing engineering teams before I started running a company, Mirigas. We're a service provider company. We help clients hire engineering talent in Latin America and Europe.
not doing outsourcing services, not doing any project related work, but really focusing on getting the right people to join teams. And thus all this, how do you do that right is the topic of the conversation. That's that I'm gonna turn it over to you. Tell us a little bit about yourself.
Randall Hand (01:11)
Sure, and glad for having me here today. I'm Randall Hand. I'm currently a chief software engineer for a dental robotics company based out of South Florida called Neosys that has a robotics platform called Yomi that dental surgeons can use for robotic implant placement and other dental procedures. But I've been leading teams similar to yourself for 15, maybe 20 years.
straight out of school, got my first opportunity with a small startup called ZCAT, which became Mako Surgical before it IPO'd and then got bought by Striker. It was a total knee replacement, ⁓ robotic assisted surgical system again. Went from there to join the Department of Defense where I led a visualization lab for the DoD super computing program for about eight years. Staffed up a team to become lab director there.
And then what most people recognize me for is I did nine and a half years starting as a founder behind Magic Leap, which was a consumer electronics product of an augmented reality wearable system. ⁓ After we launched the Magic Leap 1 and got a good ways into Magic Leap 2, I left to go back to the startup game.
Zhenya Rozinskiy - Mirigos (02:16)
Right.
Randall Hand (02:25)
Because by that point, Magic Leap had grown up to around 2,000 people. My team had grown to 100 or more people. And have done a couple of short stints helping engineering teams get back on track through eMed, a telehealth services company, Aptronic, which is a humanoid robotics company located out in Austin and now with Neosys.
Zhenya Rozinskiy - Mirigos (02:44)
You know, before we even jump into people, I want to talk about something completely different. And that's the whole idea of hardware robotics, stuff you're talking about is like, it's impressive, right? For us as a normal human, human being. And you see this, you know about this, but you don't touch it. Robotics, new replacement, robotic dental surgery. And yet you see this on TV as like, But the question that I have were the thought that I have today, we're all
building online apps, be it a SaaS or even a mobile app.
You know, I started over 30 years ago, almost 35 years ago, we built shrink wrap software. We burned it on actual, you know, desks, you know, three and a quarter of, well, three and a half, right? It was five and a quarter, but you know, when I started, already had three and a half and then CDs came and then DVDs came, right? It was so interesting. The cost of mistake was enormous because if you shipped a product to
Randall Hand (03:26)
three and a half.
Zhenya Rozinskiy - Mirigos (03:42)
millions of customers, that was wrong. You now had to ship another product to all the same millions of customers. And now with online, the cost is still high, but okay, let's go fix it. in a matter of minutes, if not hours, everybody's got the update. But when you deal with robotics, when you deal with hardware, you don't have that luxury. You have software, you have hardware, any hardware problem is very expensive. Software problem, you could push it.
but sometimes maybe you have to go and actually be there and touch that robot. So I wanna hear your point of view having been in software but on the hardware side. Like, how do you do this? How do you keep it going?
Randall Hand (04:20)
It's an evolving discipline ⁓ throughout many industries. I have experience doing it in medical fields, consumer electronics, robotics fields, and they each have their nuances. People have gotten used to the concept of over-the-air updates for consumer electronics. Your TV gets software updates, your phone, your coffee machine needs a firmware update, all of these kinds of things. People have kind of gotten used to the concept.
Zhenya Rozinskiy - Mirigos (04:43)
Mm-hmm.
Randall Hand (04:47)
They complain about it, but everyone's kind of gotten used to it. And from the software engineer side, it allows the two teams to, in many ways, run in parallel without having to coordinate their efforts too much. Hardware teams can go off and iterate on hardware. Software teams just have to know, like, okay, we're switching to this new processor, so now you have 32 gigs of RAM instead of 16, or something like
so they can change their software. And the only place things get really complicated is when you start having to manage things like compatibility matrices. So, you know, take a popular cell phone like an iPhone or something out there, or we even had this at Magic Leap with the Magic Leap 1. You've got 10 versions of software that have been shipped out into the field and three versions of hardware. And which upgrade paths have you
tested and are compatible and that you know work? ⁓ And which ones is like, OK, you can't go from version one to seven. You've to go from one to three and three to six, and then you go from six to seven. And how do you resolve all these complexities when all of a sudden the software is not just an app, it's the full operating system with the modem code and IMU firmware and all these other integrated systems.
Zhenya Rozinskiy - Mirigos (05:42)
Right.
Randall Hand (06:05)
It gets to be very complicated and in the field of consumer electronics, the penalty for getting it wrong is an angry user, but usually, we're sorry, we bricked your phone, come into an Apple store, we'll give you a new phone. But when you're dealing with medical devices or even some of the new larger scale robotics that are in use in warehouse environments and stuff, if you get that wrong, you could have things like patient harm or
You could have a robot all of a sudden, you know, crashes a forklift or drops a piece of heavy equipment or violates a safety protocol and people can get hurt. So we're seeing a lot of new emphasis on safety protocols, safety technology systems, safety requirements. I think the IEEE is working on a new humanoid robotics standard.
because you've got all these Tesla optimists and the unitree and the Aptronic, Apollo's, all these things, but there's no definition of what is considered a safe humanoid that people can agree upon. So it's like all the organizations are getting together to try and figure out, if you're going to put humanoid robots in a warehouse working alongside people, what's considered safe? So it's a very evolving discipline.
Zhenya Rozinskiy - Mirigos (06:57)
Bye.
We
have a lot to figure out for sure with all the AI and robotics and what we accept. Even all the conversations with self-driving cars, right? If it gets an accident, whose fault is that? Is that a driver? Is that a Tesla or whatever the company is? There's a lot of questions that will have to be answered. You bring up memories, right? You said you have to test all these different combinations of hardware, software. I remember back in the shrink-grab days, you release version
3.0 or whatever, 5.0 and okay, so you've tested it and now you're spending three times as long. Does that great from 1.0 work from 2.0 or from 2.2 from 2.3 like every path does, will it still work or what do we do? Yeah. Good thing. Most of us don't have to worry about that these days.
Randall Hand (08:01)
Yeah, and it's also changed the game from being able to use your users as beta testers now, where in the old day you couldn't do that. It was bullet hardened before it got shipped out the door.
Zhenya Rozinskiy - Mirigos (08:06)
Absolutely. You're going to do that for sure.
Yeah. And you're in a space where you can't do that, right? You're dealing with human health, life at times. So I want to switch to hiring and building teams. It's got to be very unique when you're approaching your hired decisions, because not only, again, right, you're dealing with hardwoods and this, but it's highly regulated environment and it's very mission critical.
I mean, literally mission critical, right? You don't want that robot to take out a wrong tooth or whatever, or make a mistake that's going to cost somebody else. How do you approach it? And is there anything specific that you have to pay attention to when you're hiring for roles, for this type of roles?
Randall Hand (08:52)
So one thing I've learned a long time ago when you're trying to hire into a healthcare space is that you need people, engineers, that are willing to move at a slow deterministic pace. Because there's a lot of people that are really excited about going to work at
a Google or even at a startup where it's a new challenge every day. There's something exciting. They can constantly bounce between projects and all these things. But in the health care space, it's more about OK, you know, we need you to add a feature that when this happens, this light turns red. It sounds really simple, but now it's a matter of you've got to test it in all these different conditions. You've got to, you know.
produce all this documentation that goes along with it because there's FDA quality control procedures and documentation guidelines. it's, you need engineers that are willing to do more than just sit down and punch out code or just sit down and draw a diagram of this is how we're gonna wire it up. Now they've got to sit down and okay, now we've got to come up with this full QMS qualified requirements document.
and a set of design inputs and design outputs and testing criteria, and you've got to test it, and you've got to design the testing protocols, and how do you review the protocol? There's all this framework that comes up around just the do the work. So it becomes very much about interviewing people that are willing to learn all of that, because most people, most software engineers have never experienced that.
unless they've worked in a healthcare industry before. So you need somebody who's willing to come in and learn that and frankly deal with the frustration that comes from all that when you see a bug in the system and it's like, this would be a 30 second fix. And it's like, yeah, but you can't make that fix right now. Cause we've got to go through this whole process and we can get that fix out in the wild 60 days from
Zhenya Rozinskiy - Mirigos (10:40)
Yeah.
I used to work for a company and our clients were all top 10 US credit card issuers. every time, and we were a third party company, they used our service. We weren't even embedded with them or anything. was a third party service, but we had a contract. it was one of those where we had their logo, right? So it was done, company X and their logo on it. So they applied obviously their quality standards.
It was the same thing. Guys, we can have this fixed by tomorrow. Sure, have it fixed by tomorrow and then it'll take us 60 days to test. And yeah, so when I was doing hiring and I spent a lot of time, most of my career I spent working in startups and I learned two things. You don't wanna hire for an early stage startup, somebody who spent their entire career in the bank, let's say. They're just not used to the pace.
And at the same time, you don't want to hire somebody for a bank who spent their entire career in startups because they won't be happy, they won't be able to slow down. That's not their pace, that's not how they work. So it takes very different skill sets and exactly what you're saying.
Randall Hand (11:54)
Yeah,
very much at the smaller stage startup, you're looking for people that thrive in chaos because if there are requirements, they're probably changing by the day. Every time they talk to an investor or a customer, there's new requirements and changes in what has to happen. One thing that I learned early on was at least among engineers, there are starters and there are finishers. And it's very difficult.
Zhenya Rozinskiy - Mirigos (12:11)
you
Mm-hmm.
Randall Hand (12:19)
to find the unicorn that can be both. And in early stage startups, you're really looking for starters that can dive in and build a prototype, just hammer up prototype after prototype. And when it comes to regulated industries or later stage, you're really looking for finishers that can sit down and polish every single screw for the hours and hours and hours that it's going to take to get all the testing and documentation and
legalese and your patent documentation and your license compliance, know, all these things put together.
Zhenya Rozinskiy - Mirigos (12:52)
Yeah, you actually touched on something. Have you ever heard of Colby? Colby index, Colby testing? No? OK, you have. OK, perfect. So that's exactly what you're saying, right? Follow through, quick start. Like, I am nine in a quick start. Don't expect me to finish things. Like, I just want. I've got people on my team that are, Johnny, you need to do this, this, and this. Like, OK, yeah, yeah, yeah. Remind me 25 times, and I'll get to it.
Randall Hand (12:58)
Yes. Yes.
Zhenya Rozinskiy - Mirigos (13:16)
But at the same time I go, well, we talked about it yesterday. How come it's not done? We didn't get to it. What do mean didn't get to it? Like I'm a nine, right? Just the idea is in my head. I'm moving, I'm running. So yeah, very much so. We do a lot of, as part of our service, we screen all the candidates that we present to clients and we screen them for technical, but more importantly, we screen them, is it the right fit? Is it the right type of person for the company that we're working with? And it's not.
Are they the right person for us? Are they the right person for you? And we get a question a lot from clients. How do you screen for that? What kind of questions do you ask? What do you do? And people don't believe it. We have questions and we have the process been doing this for over 10 years, but most information we get in terms of is this person the right fit? What kind of questions they ask us? Not what the answers are, but what the questions are.
Somebody comes in and it's a large company and they start asking about, can I move this really quickly? Can I do that? Like, you're not gonna fit. You're just not gonna happen. It's just not gonna work. Or you talk to somebody for startup. We have a client, very early stage startup and people come in and they go, do they have written documents? What's their plan for next year?
We're done. It doesn't matter what you say. It doesn't matter what your technical knowledge is. You're just not going to fit this environment.
Let's talk a little bit about hiring or specifically remote. A lot of people today are remote. Most, obviously all of our clients have at least partial remote team because that's what we do, but most companies today are at least partially remote. How does it work for you? How does it work for robotics? How does it work for where there's hardware involved? Does remote work? Is it a combination?
Randall Hand (14:54)
So what I've had the most success with is a hybrid approach. Because when you're building humanoid robots or large scale dental robots like the Mako or the Yomi, we can't really ship those to every engineer's house for them to have a test bed on site. So anybody who needs to do anything that requires hands-on equipment, they kind of have to come to a central location.
Zhenya Rozinskiy - Mirigos (15:08)
Of
Randall Hand (15:16)
At Aptronic and NeoSys, that happens to be company headquarters. At Magic Leap, when we were in the early stages of prototypes and either they were too fragile for us to ship out or considered too sensitive, we had multiple offices across the world, actually, where people would congregate to come and work. And then they could go back to their home location to work on whatever they learned.
At Magic Leap and even at some of the robotics companies, there's always an emphasis, at least in the engineering teams, to try and enable more successful remote work by, if it's a consumer electronics thing, then is there a consumer electronics equivalent that can be used as a proxy for whatever's trying to be built? Or is there a software simulator that can be used instead?
So companies like Nvidia and Google and others have built lots of humanoid robotics simulators. Some of those same simulators are successful working on medical robotics as well. So there's a lot that can be done using the software properly connected to a robotic simulator. And you do as much work as you can there and then bring people on site once a
or once a release or whatever that cadence is so that everybody can do final system integration and testing on real hardware.
That's the cadence that I've generally found to be more successful. We've tried to set up things in the past where it was people are fully remote and then they do like a tech transfer handoff to somebody who's local to put hands on keyboard and hands on robot. And that almost inevitably winds up hitting a brick wall because whoever is actually using the robot doesn't necessarily feel that they have the ownership of whatever's being done.
compared to the person who wrote it in the first place. So you get into a bit of a game of telephone where they're both pointing fingers at each other and it's not really a recipe for success.
Zhenya Rozinskiy - Mirigos (17:05)
No, Very interesting. I think I'm gonna end with something a little more lighthearted. Let's say you're building a brand new robotics company and you can only hire people that you've worked in the past before. What roles would be the hardest to fill?
Randall Hand (17:19)
hardest to fill. I have, and prior to Magic Leap, this was a role that I did not appreciate, but systems engineering. ⁓ Systems engineering was a role that I did not appreciate until I got to work at Magic Leap. And over the course of developing that product, we realized we had a software team that was building the software, an electrical team doing PCB layout and such.
Zhenya Rozinskiy - Mirigos (17:29)
Okay.
Randall Hand (17:44)
We had a mechanical team doing housing, but then we also had an audio team doing microphones and speakers, an optics team doing projectors and waveguides, an ID team that's trying to make it all look nice and feel good, marketing teams and legal teams and all these different groups. And they each spoke a different language, and none of them were an expert really outside their own discipline. So, you know, the...
software team would go up to the legal team and be like, you told us we have to be compliant with this CCPA regulation. So like, what do we need to do? And then the legal team basically just reads the law to you. And the software people are like, what does that mean? What are we supposed to do? And meanings would go nowhere. having a good systems team that could sit in the middle of all of those and help broker those conversations.
Zhenya Rozinskiy - Mirigos (18:17)
Mm-hmm.
Randall Hand (18:34)
and coordinate activities between the different teams was really the key to success of bringing the Magic Leap One to life at the end of the day. Each team did amazing work in their own little vertical, but trying to bring all that together into a shipping product took a team of people in itself just to coordinate all the other teams.
Zhenya Rozinskiy - Mirigos (18:46)
All right, bring it all together.
I actually think it's a problem in all the teams, right? It's the problem everywhere.
It sort of brings up, remember the movie office space, but what do you do? I bring requirements from this person to this person. People don't understand how important it is to speak the language of both and understand what it means. I need this to comply with this law. Okay. How like, what does it mean? I had a startup years ago in, healthcare. It wasn't, wasn't health side of things. was the
business side of things, but nevertheless, still regulated and still you have to understand how things work. And people come in and they have no idea, they don't understand. We have a lot of overseas people, they don't get the concept of what is an HMO? Why can't you change the data after it's been stored and stamped? Why can't we go and update it? They don't comprehend that, right? It's because they don't understand it and somebody has to explain it.
Randall Hand (19:46)
Yeah. at Magic Leap, we had a very impressive systems engineering team led by a very talented friend of mine, Sam, who's now working with Apple. And he was very instrumental in trying to get a lot of these teams to work together and round off a lot of these hard corners between the teams. And that would probably be if I knew I was going to tackle something as complicated as a giant robotics platform.
That would be one of the first roles to put together. Because just like magically, you're going to have software people, motors people, power people, physicists, mechanical. It's going to be a lot of disciplines. And each of them has their own internal lingo and language and set of tools and file formats and everything else that they like. And finding a way to make all those play nice is where a good systems engineering team.
Zhenya Rozinskiy - Mirigos (20:35)
Very cool. Randall, thank you so much. Thank you for your time. I think it was a very interesting conversation and definitely different from most conversations I have because they're all purely software. this is, I'm fascinated by this. I'm walking the streets and I live in Los Angeles. We have Waymo cars driving around. We have this delivery robots walking the sidewalks, bringing you food and humanoids. see them. I haven't experienced one yet, but it's only a matter of time.
And it's, it will have an interesting times.
Randall Hand (21:05)
It is very interesting times, yes.
Zhenya Rozinskiy - Mirigos (21:07)
Yeah. All right. Thank you so much. Thank you. Bye.
Randall Hand (21:10)
Thank
you very much.