Hiring top-tier talent, the importance of adopting an evolutionary mindset, and taking critical feedback to solve technical problems w/ Sergiy Nesterenko @ Quilter

Speaker A: This episode is brought to you by Cinch. Here's the thing about Cinch. You know them better than you think. That text confirming your order, the call that checked it was really you logging in the email that landed right when it should. Behind each one is real technical complexity. Getting a message delivered reliably, at scale across a hundred countries and carriers that all play by their own rules. It's usually not a problem that any engineering team wants to own. So Cinch owns it for you. They build a powerful infrastructure for messaging, voice, email list delivery, routing, compliance, and a fraud prevention. Building APIs for builders who want to go deep, ready made applications for the team who just need it to work. It's the communication infrastructure that the AI era runs on, um, already trusted by over 200,000 businesses globally and empowering a trillion interactions every year. So the next time a message test works, there's a good chance it's powered by Cinch. Learn more@cinch.com that's s I n c h dot com.

Speaker B: When you're selling to an Enterpr, uh, right, we're talking like the big, big enterprises. You're not selling to a person, you're selling to an organization. And there's a big difference there. There are many people involved in that procurement decision. You have your champion, who is the direct person who believes in your product. They may or may not be the user, right? Uh, they may be different from the person who's actually going to drive your product and deal with the day to day, but they're almost certainly going to be different than the person who signs off on the budget and gives the approval. Certainly different from the person who detracts and says that we shouldn't pursue this company's priority and you have to solve for all of them at the same time. Like, would the CEO care about your product? If not, would the, uh, SVP underneath them care? If not, does the VP care? If not, does the director care? And unfortunately, the lower down you go, the less you have the ability to get somebody with real power to step in and push it through. So how do you arm all of those people? With evidence. So that when people come and say, hey, this isn't gonna work, you have educated your champions, uh, the answers to those questions.

Speaker C: Welcome to Engineering Founders, the show for engineering leaders making the daring leap to start their own company.

Speaker D: Hey, Sergey, uh, thanks so much for joining our show today and been looking forward to this conversation with you.

Speaker B: Yeah, likewise. Thanks for having me, Jerry.

Speaker D: We had a conversation earlier to kind of talk about, you know, Your story and the insights you learned as an entrepreneur. So there's so many different things that I think can be really inspiring to a lot of, you know, engineering leaders and leaders in general think about starting their own company. Can you give us introduction about who you are, what the company you're building, and how do you get into it?

Speaker B: Yeah, yeah. Um, so my name is Sergenis Sirenko. I run a company called Quilter. At, uh, Quilter, we focus on circuit board design. Um, so we focus on creating these green things that stitch together a whole bunch of chips to perform all sorts of electrical functions necessary, obviously, for cell phones, rockets, cars, just about everything nowadays. Got into it, actually, out of my previous job at SpaceX, where I was in the avionics department, focusing on designing electronics, obviously, and just felt some of the pains of electronics design and that, ah, kind of inspired me to start this company here.

Speaker D: And what's the inspiration come from?

Speaker B: It's probably a story common to a lot of founders is, um, you know, I'm effectively my own customer when it comes to this product. You know, when you design a rocket, obviously you might imagine there's hundreds, uh, or maybe even no more than a thousand circuit boards throughout the rocket. But that's only a part of the story. You know, for every circuit board that you design that you fly, you design many circuit boards to test what you're going to fly. So you end up with quite a few people designing quite a lot of circuit boards for all sorts of purposes. And, uh, the pain, or one of the pains we ran into is that it's a very manual, very slow process. So SpaceX obviously very famous for kind of having high pressure on speed, critical path, and speed matters quite a bit. And all of a sudden, when you have to take two weeks, three weeks, four weeks to kind of sit there and manually draw every detail of something like this, you start to ask why, you know, why isn't a computer doing this? Why is it taking me so long? Why can't I parallelize it? How can I make this go faster? And unfortunately, uh, at the time, there is no kind of good answers to that. For my time at SpaceX, we kind of just took it granted, right? That's what it is. Everybody in the industry draws these manually. That's just a part of the status quo. But already the problem was felt. And for me, kind of the second piece that kind of caused me to go after this is the realization that maybe the technology has matured enough that we could tackle these problems. So, kind of you have identification of a problem that is technical in nature and then identification of technologies that might unlock that technical problem. Uh, and so those two come together to potentially make a good company.

Speaker D: People have been trying to automate using computer to design the board. Many have failed. What lead to the conviction that now is the time?

Speaker B: Yeah, it's a great question. Uh, I mean, to put that in perspective, uh, the first papers that I've seen that attempt to automate the full process of where do the chips go and how do we connect them together date back to the early 60s. Right. So before people even used CAD software in a computer to draw these. Right. This was drawn on transparent masks with literal tape, which is where tapeout came from. People were already starting to ask the question, why can't we automate this? Why can't we kind of generate some sort of diagram that tells us how to create one of these things? And so for 60 years, effectively people have been trying to do this. And so far the best things we've gotten in the industry are, uh, these things called auto routers, which are ironically, uh, notoriously hated by electrical engineers for being kind of woefully insufficient for tackling this problem. So whenever you tackle any kind of hard problem like that, it's important to study what's been attempted. And one of the big things that was the case for, for the bulk of that 60 years is that for one, you realize that computational constraints in terms of just how much compute you have available are a major problem here. And obviously that's been increasing over the decades, but not to the point to make the problem trivial. The second problem is that all previous attempts have relied on sort of human heuristics and human construction, where a human tries to write a program and explain to the machine that we should place the components in this order in this case and in this different order in this case. And we should route like so in this case in a different way, in a different case. And if you try to enumerate every decision an electrical engineer makes when they're making a circuit board, it becomes impossible. Right. And I think the direct analogy here is what we observed in self driving cars, right? If you kind of look at the DARPA grand challenge, the early days of Waymo, so on and so forth, they're describing having millions of lines of c, of how to segment away a road and where's the lane marker, how to project it onto two dimensions, how to steer the steering wheel, what to do with an obstacle, how to identify the depth of the obstacle, so on and so Forth. And it frankly just didn't work that well. And it wasn't until data driven statistical approaches, AKA machine learning, came into the picture that the problem became even feasible. And now, uh, it's kind of transitioning almost entirely to neural nets driving the cars away from classically written code. And so I think that that structure, that framework of the human doesn't have to write down every possible rule. What the human has to do is write down the success criteria and let the machine statistically figure out what heuristics to follow. That's the major unlock.

Speaker D: Take us back to when you decided to build this company. Where's the technology landscape there? To give you the early insight that likely is something that is achievable with

Speaker B: a problem like this. You have to kind of extrapolate from other industries to get the conviction, because to even begin to experiment with your own ideas on a problem like this, it certainly was the case for us. You have to build up a lot of machinery first, right? So for example, in my company, the first couple of years we spent just trying to replicate the existing solutions for this problem. Out of the chip industry, right? In the chip industry, an analogous problem is faced and it is solved largely autonomously, especially for digital chip design. And so the first non obvious question was, why aren't those techniques sufficient? As you build that out, you also have to realize that there's a lot of infrastructure that needs to be built. So for example, how do we get an input, how do we read the file that represents a PCB and identify what are the pins to route, what are the components, what are their shapes, what kind of uh, uh, nets do they have assigned, so on and so forth. You know, in this industry, these even just these file types are 40 years old and they're proprietary binary. And so they're not like a nice neat JSON that you can just import and start playing around with. You know, from there you have to invest in geometry engines. If you try to take off the shelf basic, uh, you know, computational geometry engines, they have a lot of things that make them insufficient for this problem. There's years and years of work is kind of what I'm trying to say, to even get to the point where you can start really applying novel ideas on top of what has existed. So for me, the conviction to start the company, to hire people, to raise money, so on and so forth, did not come from a technology demonstrator that proved that this was feasible. It came from kind of first principles, thinking of what has been tried, what were the Failures that were common in all of those attempts. What has changed since then and what are the analogous examples of where those changes are powerful enough at a very, very high level? I tend to think that this problem we're solving is easier than what the self driving car industry has done. Now that's still a very tall task because the self driving car industry is usually companies of thousands of people with billions of dollars in funding. But at least an upper bound exists. And so the next question becomes how do you stitch together milestones that put together customer traction, hiring, fundraising, all those things to build a roadmap to a company of that size with that technical resource to fully solve the problem?

Speaker D: And do you do that right off the gate or that's as you start to talk to investors and also talent to convince them to join the company. Tell us more about how the roadmap, the timing and also evolution fit.

Speaker B: Yeah, so let me, I'll share my story a bit and it's a little bit different than maybe some folks and their fundraising stories, so take it with a grain of salt, but I'll at least share mine as candidly as I can to maybe give some people a path. Right. So for me, uh, in my particular case, I got kind of lucky that I actually ran into an investor who offered to fund me before I even set out on this specific idea. So I was working in the Bay Area in Silicon Valley and I helped an investor with some diligence on a different company related to circuit board design of sensors in general, after kind of working with that investor for a little bit on just that side project. For him, he was trying to invest. For me, it was just a little contract to do on the side. We kind of built a relationship and he said, hey, if you'd want to start a company, I'd fund you. So the actual initial founding of this company wasn't targeted at specifically PCB design, nor did I specifically go out and try to raise. Right. That's kind of the unusual part. This kind of tends to happen for folks who are from some famous company. Right. Like anybody currently working at OpenAI or Anthropic or whatever would have opportunities like this or, you know, like if you've published a famous paper or something like that, like opportunities, uh, like this arise, but it is not necessarily common. So at that point it was really just my background that was sufficient for the investor to invest. And the investor was very willing to accept the idea that we would have to iterate on what it is we're going to pursue. Exactly. Like we had a thesis, but then we disproved it and disproved many others until we eventually came back to this. My second round was with uh, an investor that I knew for a bit longer, with whom I've been speaking with, uh, for years before that investment, just out of my personal network. They understood this specific problem very well, right? So the person, Chrissy Mayer, who led that second round was an electrical engineer at Apple. And so for her it was quite obvious what this problem is, how big it is, so on and so forth. And so I think that for her the main thesis was that we've chosen a good problem to solve. And at the time we had four or five people with good backgrounds but nothing insane. And that was sufficient for kind of our formal seed round. And to be frank, for both of our next rounds, our Series A and Series B, it's really the combination of the problem and the team that justified the investments more than anything else. Of course at that point there's some customer references and so on and so forth, but that's really what you're betting on when you're betting on a technical problem.

Speaker A: This episode is brought to you by Cinch. Here's the thing about Cinch, you know them better than you think. That text confirming your order, the call that checked was really you logging in the email that landed right when it should. Behind each one is real technical complexity. Getting a message delivered reliably, at scale across 100 countries and carriers that all play by their own rules. It's usually not a problem that any engineering team wants to own, so Cinch owns it for you. They build a powerful infrastructure for messaging, voice, email list delivery, routing, compliance and a fraud prevention. Built in APIs for builders who want to go deeper, ready made applications for the team who just need it to work. It's the communication infrastructure that the AI era runs on. Already trusted by over 200,000 businesses globally and empowering a trillion interactions every year. So the next time a message just works, there's a good chance it's powered by Cinch. Learn more@cinch.com that's s I n s

Speaker D: h.com yeah, I remember something you mentioned last time, something that's really impressive. You said that as you start a journey you're not going to have out budget are the talent on technology but you see things in an evolutionary way so that as you make more progress, they're going to attract more talent and increasing the probability of solving problem that will attract more funding and then customers. So I think that's a uh, really good perspective and they kind of project the journey for the company.

Speaker B: Yeah, I think that's absolutely critical. I mean, nowadays, of course, there are some people who manage to raise $300 million on their seed round. And at that point, like, okay, you've got the ability to hire and have a long Runway and all that stuff out of the gate, but again, that's exceedingly rare. Right. If you're one of those people, it's kind of obvious how to kind of proceed from there. For my case, it was certainly the fact that I have to treat it as iterative, and I still do. The real question is, how do you build this feedback loop of like, okay, we've got a small team, that small team made impressive progress that gained some customer validation of some type, that then gains investor validation in the form of investment that then goes and attracts more really, really intelligent people, makes even faster progress, better customer validation, even better investor validation. And you spin that. Right? And as a founder, that is probably the most important thing that I do, uh, or that I see most founders doing is you cannot possibly go and tackle the whole scope of a problem this big. So you must choose very tactically how to do something that's small but impressive. And this is a pattern you see in deep tech companies, right? Like if you think about supersonic jets or nuclear power plants or whatever. If you look at the stories of those founders, they often talk about being very tactical with the problems they pick. I think a particular like a nuclear reactor company, uh, I forget which one it was talked about. The first thing they solved was actually just a very, very high power magnet. And okay, that's still very far away from fission or from fusion or whatever. But a very powerful magnet is the crux of that problem. And also useful even if you don't manage to solve the nuclear thing. Right. Something that's, that's useful in MRIs or other medical instances. And I think it was Khosla that invested in that company. And I heard Vinod talking about like, well, the magnet's useful and interesting and impressive even without the rest of the reactor. And that gave us the conviction to. And keep building from there. Right. I think in an airplane company that might be like an engine or an airfoil that's unique or something like that.

Speaker D: But for you, for your company, what are some of the early problems try to solve?

Speaker B: Yeah. So within electronics, there's two directions of complexity that we think about. One direction of complexity is just pure geometry, right? Like how many components do we have on the board? How Many pins do we have to route? How dense is it? And it's a problem that you could give to a 7 year old and ask him to start drawing and moving things around or whatever, and they might feasibly solve. But it's purely a geometry problem. It's just a very, very, very, very hard, very time consuming geometry problem. So there's that axis. The second axis is the physics considerations. And so roughly speaking, in a circuit board, as your signals get faster or as they carry more current, you start to have non negligible physics side effects from the Maxwell equations and from laws of thermodynamics. But conversely, if your uh, signals are very, very slow, you know, like megahertz or slower, and they carry very, very low current, say 100 milliamps or lower, you can mostly ignore a lot of the physics. Physics and the physics represent constraints onto this geometry problem, right? So even if you solve the geometry problem, if you ignore the physics constraints, your board still doesn't work. Obviously the first question is, well, what's interesting in that world of low complexity, low physics complexity boards. Now in that world there are a lot of hobby boards that happen, right? People build kind of hobby projects on and so forth. But in our opinion that was actually the wrong place to start, right? You might have to traverse through the kind of boards that hobbyists solve, but those don't have commercial interest. And so, okay, maybe you can do a demonstrator and prove that some hobbyists can build some boards and build a board to show just to have something working, but it's not commercially interesting. So for us, the first kind of commercially interesting use case was use cases, specifically in R and D and more often than not, uh, in parts testing. So there's multiple cases where a company, whether it's automotive or aerospace or whatever, might be trying to just choose a part. And to choose that part to choose that chip, they need to expose it to different environments, thermal environments, radiation environments, cycling environments. This of of course always requires a custom circuit board, but it often does not require a lot of constraints on that circuit board. For example, it's okay if that circuit board is really big because you're not going to make that many of them and they're not that expensive. It's okay if you have to sample that part relatively slowly. If it's not a high speed part, then you know, you can just take your time and collect the data. It's okay if it has a lot more layers than a human could design with, and so on and so on and so on. And so forth. So we found this kind of set of problems that are commercially useful but are low in the complexity space. That's kind of the initial point. And then, and from there you start to push on the boundaries. Are we able to push on the complexity boundary? Are we able to push on the physics boundaries? Where are the next kind of useful repeatable islands that we can jump to? And we're obviously still in that path today, just further down the road.

Speaker D: That's really helpful to get to know the actual first bet you take and the idea that we make it commercially interesting, that's really important. And then taking back to your early journey, you had that experience at SpaceX and you found a very compelling problem you try to solve and you feel the timing is right. Where do you get a conviction that, uh, despite it's a technically interesting problem to solve, but what about the commercial value, the customer's readiness? How do you think about that?

Speaker B: Yeah, so in my case, uh, and this is also the case for some technical founders, you know, I am my own customer, so I at the very least had conviction that were I at SpaceX doing my old job, I would have bought something like this. And that was, that's very helpful to me. I mean, still to this day in being focused on what the product should look like and feel like long term, right? Like, I'm not dependent on a whole bunch of customer interviews to know the roadmap. Of course that's important, but even without customer interviews, I have some of my own intuition and experience. I don't know how I would be able to do this without that.

Speaker D: Right.

Speaker B: Like that was very, very, very important for, for my journey. But from there the kind of next question becomes, who else has this problem? Was it unique to me at SpaceX or is it at every hardware company? And then what is the value of it? Right? Like, how do you start to measure what other companies might be able to pay for this? Right? That's kind of very important to determine that this problem actually has merit outside of just SpaceX at that point. That's where you have to start speaking with people, right? You can start with friends, but of course you have to be careful. Friends tend to want to tell you the good news and what you want to hear. So ideally you, as fast as possible, want to put something out there and start posing it that way. So we went pretty fast to try to get at least a basic product, even if it didn't work that well. Just something that starts to look directionally correct and start putting in front of engineers. The feedback we started to get was, roughly speaking, yes, this is a problem. Yes, this is how much time I spend with it. No, what you've built is like orders of magnitude away from what I would want, but please keep going in this direction. And a good heuristic for that is actually when you see people start to get emotionally attached to what you've presented. Right? And in a lot of cases, it can actually start with bad feedback. If you show the product and people are like, yeah, that seems nice, they're not that interested. But if they start critiquing it heavily and saying, this is off and this is off and this is wrong and this should be like this, and go read this book and why didn't you do this? You're onto something them, right? Because you've tapped into some sort of emotion and they care about that problem. Right? Uh, so you can get that from one on ones and just going to friends and friends of friends and so on and so forth. You can start to get that if you just post on Reddit, post on X, put it out there in a free beta and just see who shows up. And if nobody cares, that's a signal. But if people start to have an emotion, whether it's intensely positive or intensely negative, you're onto something.

Speaker D: Give us example, that intensively negative reaction.

Speaker B: Oh, there's tons. There's plenty. I mean, uh, almost every decision that we make, and especially in the early days, was critiqued or could be critiqued. I mean, what it ultimately fuels from is when you approach a designer who designs circuit boards and you propose this idea, right? Uh, especially nowadays with all the precedent of how many things are being automated with AI, the hope from that person is, oh, maybe I can just click a button and this would solve my problem. Wouldn't that be amazing if instead of going to work the next week and spending six weeks tediously drawing this thing out, I could focus on the higher level, more difficult work and just automate this. No matter how much you set expectations, they go into the demo with that idea, that impression, that hope, maybe, let's say, and then you show them the result. And the result isn't that for whatever reason, and they have disappointment. Right. They won't tell you directly. I'm disappointed in a lot of cases. But they will start to critique it. They'll say, why did it do this? Why did it put these components so far apart? I see a more obvious way to do this. Why couldn't you have connected this this way? Why didn't it Account for high voltage or high speed. Why did it choose the stackup? That sort of critique? They're digging into techn problems of what things they would have done differently. And what they're really reflecting is I was hoping this was a magic button that solves my problem. And here's all the issues that I'm seeing that I would have to go manually do. I'm disappointed. But what it's telling you is that they care, right? They were hoping that you would have this product, you've delivered them something subpar, but they are investing their time to show you what they would have done differently in the hope that you can

Speaker D: address that and then you iterate on top their feedback.

Speaker B: I would say I would add one thing to that. Like generally of course iteration is important. Of course you want to act on customer feedback and so on and so forth. But the hardest part that I found is knowing which thing to iterate on, right. This is absolutely critical because, uh, in a deep tech company with a hard product, right? With a product where the risk is technical, not like market adoption or anything else, right. You have to acknowledge that your team does not have the capability to solve every problem, right? Like of course it would be ideal if you could just take all that feedback, knock it out in a day, come back the next day and uh, so on and so on and so forth. That would maybe be easier in some sense. That's just not the case. So you heard 100 points of feedback and you've got time budget for maybe three over the next quarter and then you heard another hundred pieces of feedback from the next customer and the next customer and the next customer and same thing. You can only tackle three. So the question becomes which three? Right. That piece is where you have to do your own customer qualification and disqualification. You might get 100 pieces of feedback from a customer or potential customer, solve all of them and only come back to get 100 more and come back to get 100 more and come back to get 100 more. And what you'll really realize at some point is that this customer doesn't actually have that problem, right? Like for them it's a nice to have, but it's not a hair on fire problem. They like you as a founder. They maybe wanted to be a founder themselves one day and so they're engaging and they're excited. And how often do companies listen to their ideas and implement those improvements? Not often. So they kind of get encouraged to keep doing that. But at some point if they don't convert, even when your Product frankly still sucks. The problem is not significant enough for them. So the really important part is to figure out who are the customers that are going to use your product even while it sucks. Because if they're willing to do that, the problem is severe and therefore a subpar solution that helps at all is still something they will invest in, spend time on, pay for. And it's their feedback that's critical. And their feedback is often very different than the people who give you the nice to have kind of feedback. This is where it's on you as uh, the founder and as a go to market team to identify who is really our first customer. And it's some combination of people you can serve in the somewhat immediate future and people who have their problem so intensely that they're willing to put up with a subpar product.

Speaker D: Yeah, I think that applies almost generically because you actually want a customer that are open to take a compromise to use your product because their pain is so intense. That's better than a customer that are happy where everything you have is perfect. In that case they don't have tradeoffs. So I mean their conviction is revealed by the fact that they're letting go some of the things that they wanted. I think the same can be applied for attracting talent too. If you are finding people that are giving away things they want in order to join the company. That's conviction.

Speaker B: I agree. Yeah, totally agree.

Speaker D: Do you have any examples when you have you choose the wrong customer and what do you learn from that?

Speaker B: I would say, you know, the first customer that we chose this was very early on in the company's life. It was a customer who actually was just my previous boss from SpaceX. It was at a different company, different group, but basically it's a customer that is a friend and that's often actually a good place to start. Right. Because at least it gives you some starting point somewhere to iterate from. And you are uh, riding on your own personal credibility as somebody in the industry rather than your company's credibility which doesn't exist yet. So it's an important first step. But in that particular case I think that the, the problem was not a hair on fire problem. And so we spent a lot of time with, okay, like how do we get this product deployed, uh, at this company's servers because it had to be on prem, how do we deal with uh, integrating with their systems and all these kind of non critical problems just to get something going, just to start getting some feedback. And the reality is, is that when that person left that company, the product didn't stick because it wasn't a good enough product and nor did it solve a critical enough problem. In some sense it was right because something is better than nothing. But in some sense it was wr because we really earned that kind of deal only because of my previous credibility, not because of the product. And had we not earned that, we would have had to fight harder for the next person with whom I had no prior credibility and to identify, um, a more kind of hair on fire, painful starting point.

Speaker D: And also there's a big risk because the resource constraint, you only can solve three problems at a time, but if you work with the wrong customer, they lead you to the wrong direction that there's often a cost of, you could have solved problems for a real customer. I think that happens a lot to many, many especially B2B company building solutions for enterprise thousand percent. So now we talk about customers and et cetera. So at enterprise, buying can be as hard as selling. So there's a lot of hoops to jump through for enterprise procurement. And that's also another thing to consider when you pick the right problem. Can you share something around that, the learning, the insight that other founders need to know?

Speaker B: Yeah, it's a good question. Maybe something I underestimated when I started this and have learned over time is you have to realize that when you're selling to an enterprise, right? Uh, we're talking like the big enterprises, you're not selling to a person, you're selling to an organization. And there's a big difference there. Very specifically, what I mean is that there are many people involved in that procurement decision. You have your champion who is a direct person who believes in your product and wants to see it there. They may or may not be the user, right? Uh, they may be different from the person who's actually going to drive your product and deal with it day to day, but there's almost certainly going to be different than the person who signs off on the budget and gives the approval. Ah, certainly somebody different in who reviews the security claims and um, so on and so forth. Certainly different from the person who actually deploys it. Certainly different from the person who detracts and says that we shouldn't pursue this company's priority. You have to solve for all of them at the same time. If you're still at the stage of choosing a product, how important is it at the highest levels of the company? Like, would the CEO care about your product? If not, would the SVP underneath them care? If not, does the VP care? If not, does the director care? And unfortunately, the lower down you go, the less you have the ability to get somebody with real power to step in and push it through. So ideally you're solving a problem that the CEO would recognize, but if you can't, then you're gonna kind of fall down from there. You have to arm both your budget approver and your technical user with evidence of why your product should be brought in with the user. Of course, you make a nice product that's fun to use and so on and so forth. That's the obvious part. The non obvious part is that that user needs their manager or their manager's manager or their manager's manager's manager's manager to get the budget approval. Well, that person needs proof. And so you need to arm that person with at the very least some sort of presentation or deck on, hey, we've done this with other companies and here's the ROI they've gotten and here's how the rollout, uh, plan should be and you should expect an ROI in 12, 18, 24 months and so on and so on and so forth, forth. And then you should be ready that there are detractors you haven't met. So how do you arm all of those people with evidence. So that when people come and say, hey, this isn't going to work, you have educated your champions with the answers to those questions. And so that's kind of the thing that I've underestimated is you're going to have to map all of that out. And ideally before you even pick your product, you think that through. Who are all of those people? Have I met people like that? Let's give them a fake name. What kind of evidence would they find compelling? When am I going to be able to have that evidence? How am I going to have that evidence? And so on and so and so forth.

Speaker D: I can imagine this is particularly challenging as you creating, uh, a new category in the market. How do you think about when should a founder educate the market? When should the product adapt?

Speaker B: In general, the more you educate, the more of an uphill battle you're fighting. Right? So for our specific case, full and complete automation of circuit boards doesn't exist and people don't approach the problem that way. So in some sense we're creating a category, but we have the luxury of masquerading as something that does exist, which is just human labor paper. So we very, very specifically have targeted a part of circuit board design that is often handed off to a different person, which means that interfaces exist, right? Which means that there's already a handoff between person A and person B of, hey, here's all your inputs. Please do this task of layout. Oftentimes in our industry, it's actually outsourced, which means that not only are there technical interfaces in place, they happen over email, but it's still a technical interface. There's also a contractual interface which is, hey, we're going to outsource this. It's going to cost roughly this much. Here's how much the labor costs, here's how we meas measure the labor up front, here's how we predict it, so on and so forth. For example, in circuit boards, what it specifically means is that if I send this out for a quote for a professional PCB designer, they're going to go through and count how many parts are on this board, how many connections on this board, multiply that by some rate and say, okay, it's going to take me $30,000, eight weeks to do this design as much as possible. From that contractual and interface perspective, we look exactly like the status quo, right? You give us the same files you would give a different human. We bill you the same way way it comes from the same budget, you still learn the same tools. And ideally, you'd learn very little about the new tool because the new tool is trying to automate. The only difference is instead of a human doing the task, it's a machine doing the task. And therefore it happens much faster. But on cost price neutral to labor, at least in our case. Of course, for us, that's fantastic because it's very high margins. But from the customer's perspective, it's same inputs, same outputs, same cost, same contracting structure, same budget source, but much faster, which is very, very compelling.

Speaker D: In the previous conversation, you mentioned the curvy trace example that was really leveraging the first principle of thinking. Can you ask more on that?

Speaker B: Of course, yeah. So for the listener, the discussion here is around how you actually create the shapes of the wires on the circuit board. And if you look at any modern circuit board, what you'll find are wires that are drawn very strictly in either left to right orientations. So horizontal vertical orientation up or down, and 45 degree angle angles. And that's it. Right. So typically there are no other kind of directions or angles that wires take. And this is called octilinear routing. Right. A, uh, simplification of this might be Manhattan routing, where you strictly route left to right up and down, kind of like a city grid. That's not common in circuit board design. It used to be. But if you want to picture Manhattan routing, it's the same for our purposes. And if, uh, you actually reason from first principles on the electromagnetics of the situation, you find that a better approach is actually to allow your wires to be fully curved, curved and to take on any angle. Because an electromagnetic wave moving through a smoothly curved waveguide has fewer aberrations or problems, especially at high frequencies, than one moving through sharp turns. So I actually also dug in and found out that the only reason that we have all of these sharp turns on boards anyway is from the limitation of computers in the 80s of just being very slow and CAD software requiring parallel line segments, for which it is very cheap to compute collision call cost. Detecting a collision between two parallel lines is just a float comparison, whereas detecting collision between two off angle line segments is like 16 if conditionals of different projections. That's much more expensive for an 80s computer. Not anymore. So at first thought for Quilter was well, let's just make all of our traces curvy. And that should just be better. And customers should recognize that. And instead it was met with literal horror. People literally looked at the board and were like appalled by how it looked and laughed at it and so on and so forth. And I took on the stance of trying to educate my customer about, hey, this should, shouldn't this be better? And so on and so forth. And it was really hard because this is.

Speaker D: Even though they worked.

Speaker B: Yes.

Speaker D: Right. Then still have a challenge to convince people that this is the right approach.

Speaker B: Yes, yes. Because they're so not used to it. And it's one is familiarity. Right. So the customer has to really break. Like they've never worked with curvy traces everywhere. That's just not something they've ever seen. All the best designs they've ever looked up to that they've ever created, that their mentors have ever created are all octane linear. So you have that initial shock factor. Furthermore, in my industry there's a lack of understanding of the manufacturing process. So a lot of customers, uh, start thinking, well, this is going to be worse for manufacturing for some reason. And what they're really kind of getting at is like, if curvy was really better, we would have had it by now. So it's not possible that something so fundamental is wrong. That's really where they're coming from. And if everything you have to educate your customer on is going to present an uphill battle and a challenge. And even if you manage to convince the person sitting in front of you, how are they going to convince the naysayer behind the lines. Chances are they're not going to be able to argue it as well as you just did. And so you're going to lose at that point, even if you got that far. So what I've kind of found is that you want to educate your customer ideally only on one or two of the most critical assumptions that your company is challenging that unlock the major breakthrough. So I'll give an exact example for us now, the thing that we pick as the battle with our customers now that most accept, but not immediately, is that whether or not a circuit board design is a good circuit board design is a computable problem that in principle it's possible to write a set of checks and a set of simulations that unambiguously determine whether or not a circuit board layout is good or bad. From a first principle that kind of seems obvious. Right. Like we can simulate Maxwell equations, we could simulate thermodynamics. We're not dealing with the limits of quantum mechanics here. Right. This is like not a terribly difficult thing to simulate. There's of course corner cases and issues and you have to take statistical distributions and make sure you're on the kind of one sigma, two sigma conservative side and so on and so on forth. But it's doable. That's not common in our industry. And so to a lot of people it's like, wait a minute, I'm used to making the judgment call. How could a machine possibly make that judgment call? And you have to take them m through the logic of, well, think about everything you decide on. It's all based in physics. But for us, that is the critical unlock, right. That if you are able to simulate and determine if a board is good in silica, then you're able to run reinforcement learning and unlock real automation. And so it's kind of critical to our company to make that point. And so that's why we choose that fight to go after on education. But in every other place, I'd like to not educate the customer and instead make them feel familiar and in control.

Speaker D: Yeah, that's a very calculated bet because that's the whole premise of the company. The corp believe that this can be automated, but if you win that, then the customer will follow along.

Speaker B: Exactly. And this is uh, another good test for do you have an early adopter hair on fire customer? Right. Like we very quickly see who kind of inherently agrees with that bet. And sometimes we state it and people lean in and like, my gosh, of course it makes so much sense I've always wished it was this way. Please tell me. And others lean away and say, no, that's impossible. You'll never replace human judgment. And that's your first clue of, uh, who should be your customer.

Speaker D: Especially in the early days, there's only so many customers you can serve and serve the one that are wholly heartily believe what they believe and just make everything easier.

Speaker B: Yeah.

Speaker D: So since you are building a hard tech company, I think it comes along its own set of unique challenges and opportunity. So one of the questions I have is, how do you know whether a hard technical problem is to earn early or is the right time?

Speaker B: Yeah, it's a good question. And to be honest, I don't know that there's a good answer for this. In general, I forget what this book was called, but I remember somebody wrote a book studying different successes in the venture industry and which companies have worked out or not. And by far the number one correlation between success and factors wasn't the founder or what school they went to, or what their tenure or age was, or how big a team is or funding or any of those things. It was timing. Right? Timing is the number one prediction, Victor. And many, many, many good ideas were attempted early. I mean, arguably, if we got this problem right on timing, then the 60 years of people who tried to solve it before were also solving the right problem just a little bit too early. And the question is just, are we the ones who are on time? And how do you know? I mean, it's very, very, very hard. I'll put it in even more drastic, uh, kind of way. There was a conference of physicists in, I think the 40s. Think of like the, you know, von Neumann and those kinds of folks who at the time already were aware of neural networks as a concept. And, uh, it was believed that we might be a four to eight week seminar away from solving general intelligence. And the physicists got together and kind of tackled the problem and sure enough, they were at least 80 years too early. And yet some of the smartest people at the time believed that maybe it was the time. So I can't say anything more than this is a part of the founder magic, right? This is a little part of why it is hard to create a company and to succeed. And why it's so rare is because either you as the founder have to have that conviction and have some reason, and it's not something you can read and apply out of a book or simply you have to get lucky.

Speaker D: Luck is definitely a, uh, very important part of, you know, Being a founder,

Speaker B: I would rather be lucky than good any day.

Speaker D: Yep. Any other thing that you can share, uh, with our audience in terms of picking the right problem solve and how to embark on entrepreneur journey?

Speaker B: Yeah, I think, uh, uh, specifically talking about hard tech and hard problems here, of course there's a bunch of things that make it more difficult. Namely that it's a hard problem and you don't even know if you're able to solve solve it. You know, contrast that with a lot of other kinds of problems where whether or not it's possible to build is trivial to determine and besides the point and it's just a question of is it the right product to build. But the nice thing about these hard technical problems is that they attract wonderful people. You tend to attract really great investors who maybe have already succeeded, uh, to some extent and are willing to take on a bit more risk, but themselves get attracted to the problem. You attract great teammates because generally the smartest people in the world want to solve the hardest problem. You can work with great people and you also attract great customers. Right. The more kind of ambitious and important your problem is and the more credible your team and approach, the more likely you are to have some of the biggest, most important companies in the world working with you even while you're tiny. And that's a great honor as well. Right. Because why would a 100,000 person company on the Fortune 50 spend time with a 30 person startup only if the problem you're solving is difficult and meaningful and important? And those are really good advantages to have in a startup. I would much rather be solving a, um, very, very hard technical with those advantages than solving a technically easy problem where it's really not clear if the product is kind of right or wrong. It's a personal preference, but that is an advantage of the hard problems. You know, I think that's probably the best advice I can give is like if you're thinking about the hard problems, I mean sometimes maybe it's even better to make them harder. Right. And to bet a bit bigger because then you can attract even more ambitious people and the team you put around you and the customers you put around you are really the company and really the key to success.

Speaker D: Yeah. I think here there is a common misconception that if you have an early, early stage product, you don't talk to the best companies, they're not interested. But based on what you just shared, it can be quite the opposite because those leading companies, they're the ones that want to innovate. So more likely they are betting on uh, early startup.

Speaker B: You know actually I'm really glad you pointed that out. It's uh, something I failed to mention but I think it's absolutely been true. You know, we took the initial wisdom of well startups should sell to startups first.

Speaker C: First.

Speaker B: Right. Like a lot of companies conclude this and for us it really has not worked at all. And it's, it's the bigger companies that have paid much more attention along the way. And what we saw in our case was that with the startup you're dealing with another startup that's strapped for time and uh, you know, overloaded and if you try to give them a solution that, that isn't perfect that they have to invest in, they're busy investing in their own thing, they don't have time for that. But a big company oftentimes has a well walked program, program for how to bet on early technologies that takes years to develop, years to invest in, years to roll out, uh, throughout the business. And they're perfectly okay if it's still early and not working and they're happy to have their influence on it and a lot of times happy to pay for it as well. So for us it has been much more successful to work with the big companies than the small companies and I suspect that'll be the case in a lot of places. And I wish I had focused on that sooner.

Speaker D: Yeah. That is to say to founders that don't be scared that you don't have anything to always want but I think that's opportunity actually because the large company, they now they know they have an influence on your roadmaps.

Speaker B: I think that's absolutely true and I would give a um, corollary here with investors. Actually at some point my thought on fundraising was you know, oh like well we don't have the revenue and the traction of some of our competitors and so on and so forth. And so let's go to investors who maybe aren't name brand and tier one as you might call them and ironically we had a harder time convincing them than and now benchmark and index who are some of the best. And I think it's the same thing where for investors also it can be the case that a harder, more long term, more non obvious company and problem is the right one to bet on. And so in general for founders I would say especially if you're picking something hard and meaningful and that you really believe in, don't be afraid to go to the best people in the industry.

Speaker D: So I remember, I listened to, I uh, think Eric from Benchmark talked about very proudly identifying your, uh, company and betting early on it. So anything you can share with interaction with Benchmark, Eric specifically.

Speaker B: Maybe the most interesting part is how that relationship started and what I did in that pitch. And this may be helpful to founders especially who are kind of starting out thinking about how to pitch. You kind of tend to think of a pitch as like, here's this polished slide deck and here's this recent story and all these bullets and whatever. And it's very easy to lose the person, especially if it's a technical problem. And usually your investor is not from that same domain. Eric, as an example, is somebody who's never thought about designing circuit boards before. He has. I spoke. So my pitch, roughly speaking, was to him and his partner Victor at the time I came in with a computer motherboard and just put it on the desk and told him to look at it and said that a human designed every single element of that board. And I just sat quietly for a minute and him and his partner just giggled over that board. In that moment, I think they saw how ridiculous that was. It didn't matter anything else. Right. It didn't matter at that point yet about how far did we get and who was the team and whatever all that would have to fall follow. But my guess is that the first two or three minutes did the bulk of the work and from there it was why am I the right person to solve it? Why do I have the right team? Why do we have the right approach? What's been tried? All the kind of obvious questions, and this is one of the advantages you have as a hard tech founder is especially if it's in hardware, put the hardware on the desk and let them very naively, very obviously stare at it and say, oh, wow, I didn't realize XYZ was this bad, bad. And it seems very important and let's go tackle it. So that's, uh, maybe a piece of advice. Our founders pitching is in fact, it probably shouldn't be a business story. Kind of like a Harvard Business Review type thing. Right. Like come in with a piece of hardware ideally and just show the problem and let them feel it viscerally.

Speaker D: Yeah, I think it's an emotional moment. And also you're not pitching you to lead them to the problem that they realize, oh, there's a problem here.

Speaker B: Exactly. Uh, at the time, especially given growth of electronics. Right. Like something so important at the heart of everything that surrounds us is so painfully manual, which is nothing like the software industry draws attention the other Thing that I've heard Eric describe about his own reasoning on choosing to work with the company, and this is also important for the founders out there, is his realization that our team and I as a founder, spent a lot of time in what he calls the idea maze. Right. Uh, it's this kind of idea that like somebody who's really honestly trying to solve the problem has looked at it every which way, has explored all the different possible paths and looked at how everybody else has approached it and so on, so forth. And it's kind of very obvious to the investor that this person has really, really, really, really studied this problem. And if anybody's going to solve it, it's going to be this person. And so that's kind of the other piece of advice is hopefully if you have your own conviction, it is because you've really studied the problem in every which way. And if you can speak to that plainly as investors ask you questions, it will be evident and important.

Speaker D: Do you have example of convincing a high profile talent to join a company that otherwise going to be insane? I know no way we can have someone of least caliber to join our company. So right early, do you have example of that?

Speaker B: Yeah, for sure. I would frankly argue that especially the early team and most of the team now can certainly join companies that pay them much better and that are much more recognizable in brand. Right. Probably close to a third of My team has PhDs or professors or whatnot. And uh, yeah, they have a lot of opportunities. I would say the way I more often than not convince folks like that is to sort of infect them with the problem a little bit. What I'll do is I'll describe this problem of kind of routing circuit boards, but I'll pick, pick a fraction of it. That's very, very easy to understand. I'll basically express uh, the routing problem as something where, okay, finding the first path is really, really easy. But as you add wires and as you add paths, you block off the future paths. And so how do you predict that and manage to get all of them? And a lot of times or almost always, these folks tend to think, well, that should be easy, right? And then they ask me a few questions about some obvious approaches and I give them some counterexamples of where it fails and they walk away. And then a week later I speak with them and they say, I was on vacation with my kids, kids and I was still thinking about this or I was taking a shower and I was still thinking about this and I still can't stop thinking about this. So all I've done is give him a puzzle. And smart people love puzzles, right? And this is, this is the number one thing for attracting hard tech founders. Now you have to still make the, you know, the math. Math, so to speak, right? So you have to be at a point where the salary is acceptable and they don't have to make major life sacrifices. You have to compel them with equity. And for some people, they're not willing to take risk. And that is what it is. Right. Like I also select people who are here specifically to take risk. Take risk, but the hook is a puzzle.

Speaker D: And also you get a signal that the fact that you can't stop thinking about it is the right talent you want to hire.

Speaker B: That's right.

Speaker D: I have a few rapid fire questions if you're ready for reading Pub Cool.

Speaker A: How do you deal with stress as a founder?

Speaker B: Uh, exercise is the best way. I had a period in the company where I was rather overwhelmed with stress. I had a teacher introduce me to meditation, uh, which was somewhat effective. But what I really got into was martial arts arts. I started taking Krav Maga and Jiu Jitsu and Muay um Thai classes and really enjoyed that. And so for me, physical activity exercise is the number one way.

Speaker D: How do you find time to keep your head up versus just keeping your head down working on things?

Speaker B: I try to split my time relatively evenly. One third recruiting, one third customers, one third product. And by virtue of that scope shifting, uh, you end up having to think a little bit higher level because you don't have time to just run away and dig technically deep for a long time. Early on you might do that, but you should try to get away from that as soon as you can. And as you recruit, as you talk to people from not your industry, but other industries, as you talk to customers, you are forced out of the local thinking. And the only trick is to stay in that uncomfortable space more often and longer than you would otherwise naturally do.

Speaker D: What is one effective tip for you to manage time better?

Speaker B: Oh, that's a good one. Uh, a good classic tip is color code your calendar and just ask yourself, how much time am I spending on, like, what is my top two or three priorities? So for me, I've stated recruiting customers and pro product. How much time am I spending to both. Calendar audit is also another good way to just delete things that you don't need. Right. Ask for everything that was on your calendar. What did it actually accomplish, and what would have happened if I didn't do it another way? To do it is just clear your calendar and see what re enters. But honestly, I would just stare at the calendar and be honest with yourself.

Speaker D: What is something that you intentionally want to set time to learn as a founder that you think is critical for the future of the company?

Speaker B: Oh, that's a great question.

Speaker A: Question.

Speaker B: I spend a lot of time listening to other founders on podcasts like this, to be honest. And the thing that I want to learn from them is how they handle all the various things that you don't think about that come up in a company, but that then nearly kill the company. Every major company has had some near death experiences, some crucible moments, some critical decisions. These are effectively case studies. And you know, so my wife was at, uh, Harvard for business school. I read most of her case studies when she came back, but they were presented often in this very nice, like you're CEO of Coca Cola and you pick this or that strategy for expansion. And it's very analytical. The founder version of that is very similar in that there is no one structure and you should study a lot of case studies. But it is never a decision you can make analytically with rigorous thinking. With an mba, it's a oftentimes gut, faith driven decision. And listening to some of the stories that those founders go through inspires me to kind of trust my own cut and make decisions that are quite radical that maybe I'm afraid to make. And that's something I dedicate a good amount to time too.

Speaker D: Last question. As a founder, I'm, uh, sure you go through a lot of unseen challenges before. Where did you go for support?

Speaker B: Number one thing for me is my wife. She, you know, even started the company with me in the early days, worked with me for the first half a year to a year, and has been, you know, the closest partner ever since. And I think that's just immensely, immensely, immensely powerful and beyond myself. I know from another podcast, I really like Grit, um, uh, by Kleiner Perkins Jubin, the host of that podcast, says, says that the one common thread of all of his guests is having a good amount of support and family at home. So for me, that's number one.

Speaker D: Wow. Thanks for all the insights. I learned a lot and be inspired already. So, um, I'm sure there's a lot of founders in the audience. They're better equipped now with a lot of insights and perspectives. So thanks again for your generosity of time and insights and look forward to maybe continue conversation again.

Speaker B: All right, thank you, Jerry.

Speaker C: If you're listening to this and you're wondering how can I connect with other engineering leaders in my city? Pull up your phone right now and go to elc.community click our chapters page. You can see that on the menu on the left. Find your local chapter and click Join. We're hosting virtual and in person events all the time and this is the best way to help you get involved, expand your network in your city, and support your leadership and career growth. So pull up your phone, head to ELC Community, join your local chapter and get involved. A huge thank you to all of our local leaders, leaders who make community happen, and thank you for listening to the Engineering Leadership Podcast.