What if the decision that sinks your hardware startup is one nobody remembers making?

In this episode of Why Design, Sera Evcimen shares the belief that sits at the heart of her work: most hardware failures are predictable, and the people who talk honestly about their mistakes are the ones others can actually learn from.

Rather than staying on one company's payroll, Sera chose to move through startup after startup, from CubeSats to fusion to robotics, and then to go in alongside founders as a hands-on partner. That decision led to Pratik, The Builder Circle podcast and a hardware community that now spans Boston and London.

This conversation isn't about startup statistics.

It's about the hidden chain reaction between a product decision, a hiring decision and a company strategy.

Think of it as the highlights reel. Same conversation, fewer detours, every point that still matters.

Don't just listen. Go beyond the podcast.

Join the Why Design community → teamkodu.com/whydesign

What You'll Learn

• 🏭 Why your first operations hire ends up choosing your manufacturing strategy for you
• 🔧 How the in-house decision gets made by accident, one purchase at a time
• 🧭 What hardware-savvy VCs respect in founders who name their own risks
• 🗺️ How to map skills to build milestones before you write a job description
• ⚙️ Why tribology explains so many gearbox and bearing failures
• 🤝 What actually works for engineers who find networking uncomfortable

Memorable Quotes

"If you hire too early, it will basically make the decision for you in a way."

"There's no such thing as bad PR. When you're a startup there is."

"I always joke that I'm the happiest when I'm crawling on the floor of a factory floor."

"Community is the lifeline for hardware."

"I would say focus more on being interested than interesting."

Resources & Links

🎧 Listen on Spotify, Apple Podcasts, YouTube & Amazon → whydesign.club

👥 Join the Why Design community → teamkodu.com/whydesign

📸 Follow @why.design_ on Instagram

🎥 Watch full episodes → YouTube.com/@whydesignpod

🔗 Follow Chris Whyte → linkedin.com/in/mrchriswhyte

🔗 Explore Pratik → pratikdev.com

🔗 Connect with Sera Evcimen → linkedin.com/in/seraevcimen

About the Episode

Why Design is powered by Kodu, a specialist recruitment partner for the hardware and physical product development industry.

Through honest conversations with designers, engineers and creative leaders, we explore not just what they build — but why they build it; the beliefs, decisions and responsibility behind meaningful work.

About Kodu

Why Design is produced by Kodu, a recruitment partner for ambitious hardware brands, design consultancies and product-led start-ups.

We help founders and leadership teams hire exceptional talent across industrial design, mechanical engineering and product leadership —bringing structure and clarity to one of the hardest parts of scaling.

🔗 Learn more → teamkodu.com

Sponsor

This episode is sponsored by Vax and TTi Floorcare. Kodu, is running the hiring. Recruiting for Vax for more than ten years, placing over fifty people including a VP of Engineering and a Head of Design. We know how they build. Right now they’re rebuilding their UK engineering and innovation function from the ground up: advanced development, design engineering and industrial design, all at once. We haven’t seen them move at this pace in a decade of working with them.

what happens is if you hire too early,

it will basically make the decision for you in a way.

Because if like you're hiring a COO with

with manufacturing experience,

guess what they're gonna wanna do?

They're not gonna wanna outsource

Yeah, absolutely.

that manufacturing. They're excited about it.

Sera, welcome to the podcast.

~ It's so nice to be here. Thank you so much for having me.

terms of our focus for today, we're dive into your career

and that unconventional career path through kind of the hardware startups.

what you've learned from working with dozens of teams as a fractional COO and a CTO,

what tribology or why tribology matters more than most engineers realize,

your take on common hardware pitfalls and how to avoid them,

the lessons you've learned kind of in the field,

but also interviewing startup founders as part of your podcast as well,

and the power of community, meetups and storytelling to build better products.

So I want you to introduce yourself,

give us a little bit of a flavour about who you are and what you do.

So my name is Sadaev Jaman and I'm a mechanical engineer by trade.

And basically, after finishing mechanical engineering,

I went right into ~ being, a lot of people talk about being a serial entrepreneur,

I was a serial startup employee.

So I went from kind of one startup and then

I did a bunch of stuff in one industry and then I was just fascinated

by other facets that I learned.

then I, because once you're in the startup community,

kind of start to know a lot of people,

everyone talks to each other, you get to network.

And as a result of that, I was able to,

I had the privilege of being able to be in a few founding teams,

very like the core engineering teams ~ early stage.

so.

started my career in the space industry.

I was building CubeSat satellites and kind of working in a clean room,

but also because we were only a few people,

I was also doing kind of sales engineering.

So I would go to conferences and I would talk to people and try

to understand what the consumer,

like the customer landscape was for our CubeSats.

And then kind of bring that back into the technical requirements.

And that was a really cool kind of role that I was able to hold.

And then afterwards I went into a consumer electronics business that

was building bracelets for protection of women.

And this was an interesting kind of social impacts project.

And also it got me acquainted with the kind of contract manufacturer

and mass production perspective from this really early stage.

And then from there I went to Commonwealth Fusion Systems.

And I worked on ~ basically the R &D team that would

be de-risking subcomponents for the fusion reactor.

And then I went and worked on ion thrusters,

and then I went to Toyota Research Institute and worked at robotics.

So it kind of like tittered and tattered around a lot

of different hardware industries.

But the kind of the lifeline of all of them was that I really liked building

physical products and really understanding.

the integrated systems and how they work together and what the risks are.

And then also got completely infatuated with the process of what it takes

to build something from absolutely nothing and kind of cater those relationships

in your supply chain and kind of build it up,

which basically ended up with me starting my own company so that I could

do that more with founders in a more involved manner than just an employee with this

specific job title.

~ I, now that's what I do. I basically,

~ fractional COO and CTO is like one of the things I do,

but mostly I like to call myself like,

~ a hardware startup partner. It's like a,

~ a thought partner, ~ a lab partner.

~ I go in, I build, ~ build their products with them,

or I kind of zoom out and I help them with their strategy.

kind of that that's me in a nutshell in this chaotic nutshell

That's awesome.

let's start at the beginning then.

So ~ why design? Where did it all begin?

How did your journey into mechanical engineering begin?

Where did you get the bug?

Yeah, it's such a good question,

right? Because everyone definitely has a story to getting into hardware,

which I, this is something that I love about it.

It's, it's, it's so much more than just nuts and bolts.

There's a lot of emotion behind the,

behind the designs. ~ So funny enough,

the thing that got me interested in mechanical engineering was watching

how it's made with my dad when I was a kid.

~ so I was just always really interested in the manufacturing process of things.

mean, for those who are listening that don't know what I'm talking about,

~ how it's made is this like really old TV show that was on Discovery

It's brilliant.

Channel. It was amazing. ~ there's still like kind of types of that show still,

~ kind of hearing on, ~ but basically they would take everyday items that

you would see like a golf club or

~ I don't know why I keep thinking of the golf club.

I guess I was really affected by it.

But then they show you from raw material all the way to the finished product,

how it's made. And so that kind of got me thinking about every single thing that

I would see as a kid, like my pencils,

my notebooks, everything. I would be like,

how does this get made?

you mentioned on our intake call and obviously at the very beginning in your intro,

you've had, you've worked in a lot of startups at the early stages,

but you mentioned you've worked in failed startups.

I think you mentioned a weird

Mm-hmm.

acquisition as well. ~ And

Mm-hmm.

then one that's doing really well.

What that mix, you know, what was it about those experiences,

~ you know, that made you...

kind of shift from, want to build things to,

or to help others build better.

Yeah, mean, it's, think ~ one of the things that really is jarring

is that 97 % of hardware startups fail.

And this is a known thing. And my personal experience with all of

the startups that I've been a part of was I was able to kind of see the signs.

Maybe it was not obvious to me at the moment,

but like kind of afterwards being like,

okay, like it makes sense that that did not work out or whoa,

like they were really doing something right.

I'm still kind of keeping all of the learnings from that with me today

and I'm applying them still today.

So it must have been that they're pretty solid ~ over there.

basically as I was doing this,

I just realized that there was a lot of really,

really good ideas. I met a lot of ~ academics that are working

on really cutting edge research that has the opportunity to really shift

the way that we operate in the world and have really positive impact.

But a lot of those ideas were kind of getting stuck on napkin sketches.

And people just really weren't able to put the,

I guess like the path stones in front of themselves to build systems

and then build businesses around them.

Or they thought they knew and they would get into it and they would have really good

connections. They would get a lot of money and then not know exactly how

to use it and when to use it. ~

~ how that path should go for a successful outcome.

And it's kind of this inherent frustration and curiosity,

I guess, that

You

~ led me to be like, okay, everyone's kind of making the same mistakes.

~ And there's a lot that people can learn from each other.

It's also really difficult to share mistakes publicly.

So not a lot of people learn from each other's for that reason.

We see a lot of news about like,

oh, we like raised this gigantic round.

We have this super successful launch.

have like all of these like super positive titles.

Very rarely do you see people talking about like we really messed up.

It's usually they don't want the bad PR.

There's no such they always say like there's no such thing as bad PR.

When you're a startup there is because

mean, VCs and customers are kind of looking for reasons to sometimes like

not invest in you or not work with you because you're new and they're scared

and there's like the reputational element.

So ~ as a result of that,

I was like, can I be a conduit to all of the people that I work with from

all of the kind of case studies that I've seen and do it in a way that's

not harmful to anyone?

where it's like, I'm not like throwing anyone under the bus being like,

well, they did this mistake, so you shouldn't do it.

It's like, no, these mistakes are pretty common.

Like I've seen five startups do it.

When I speak about it, no one would be like,

she's talking about us because it's like,

I've seen it so many times. ~ And so that,

that whole kind of culminated to me being like,

I need to, I need to get involved here and warn people.

and kind of give the big picture of just like this decision you're making right

now has all of these domino effects,

like have you considered that?

And if they're aware of it, they usually,

startups take a second to either make that decision or like

get more resources involved or whatnot.

And it just helps and it's just less wasted effort.

And I think that's really important.

I've talked to a few VCs about this because I've wanted to kind

of demystify this like process that they follow when they choose.

~ because it's this like, like this illusion.

mean, it's, I feel like it's, it's a really important part of the ecosystem.

And a lot of, ~ startups come from this pretty low level of leverage,

~ into those conversations. So I totally get being absolutely mortified.

~ going into that, knowing that certain things are not working on your part,

but time and time again, specifically with hardware savvy VCs,

what I've seen is that they really respect founders that know their risks

and can like kind of own up to it being like,

this is a problem about our system and we're fixing it doing like this test

and this prototype and this partnership.

~ and that's basically like our sole focus.

And then we have all of these other risks that we are considering

and doing de-risking efforts and mitigation efforts as well.

And this just shows rather than being like,

no, everything's going to be perfect.

We have amazing product market.

Our products working great. Like it's that kind of gives more of a sense

of pause more than it gives comfort.

I think that people think. ~

Yeah.

so I agree with you. It's like.

Owning up to your problems not only allows people to help you,

but it also shows that you know what you're talking about,

in my opinion.

So you you launched Pratic then to fill the operation on technical gaps that

you know, often slow hardware teams,

especially startups down.

Mm-hmm.

know, what what some fairly obvious from what we've just been discussing,

but what made you start Pratic?

You know, what was what made you kind of make that leap?

And, and then how do you usually plug into,

you know, a team you mentioned your heart,

you kind of

quite hands-on by the sounds of it actually building stuff or are

you talking kind of metaphorically building stuff?

All good questions. So it's funny,

actually, how Pateek came about was out of,

in a way, kind of necessity. I wasn't planning on it by any means.

What happened was when I started doing my mentor in residency at Techstars,

I had a few companies out of the accelerator show interest in working with

me as an advisor. So once that kind of initial pulse came through,

I said, okay, I should probably form some type of like limited liability

~ situation just to be smart about it.

And I'll take these on as just like onesies twosies.

And then as I was doing it,

I was gaining a little bit of steam,

kind of had this word of mouth situation happen.

And then I kind of looked at the amount of interest that there was and the numbers.

And basically it made sense to do it full time at that point.

So I made the leap out of like,

I guess, like if I'm the product,

a good product market fit for the time.

And then as I did it more, I just really loved it.

So I kept doing everything I can to possibly increase my impact,

which is why I created the Builder Circle,

which is the podcast that I create for hardware startups.

And it kind of progressed from there.

And in terms of how I work, it's a good question because it's not really obvious,

I suppose, because I don't work as like a traditional consultant.

A lot of consultants usually ~ do pretty like high level analysis.

They like meet with you a few times a month maybe.

I'm definitely a more like integrated engineer at the same time as a strategist.

So I usually...

I

mean, I could give you some examples of how I've worked with clients in the past.

So like I've had one client that's working on this robotic solution

for the life sciences with them.

I integrated to do like a DFX analysis of their product because

it was a first of a kind that they had built.

It was pretty scrappy. And I said,

Hey, like for me to do a proper DFX analysis,

I need to build this with you.

So I went to their facilities in San Francisco.

I sat with the head engineer and we actually built the robot.

And then as we were building, I was writing a document of like all

of the things that I thought that they can change to make it better.

And they like that kicked off a whole effort internally for them beyond like

the suggestions I made. And then they ended up reducing their part count

by significantly. They did some redesigns that reduced their labor time

significantly. So that was one thing.

And then they were looking into the process of insourcing versus outsourcing.

So then I kind of took a step back to a higher level.

And I was working with the CEO and engineer to be able to figure out,

if you insource this, like what are the trade-offs?

What is it going to cost? Like,

what are you trying to deploy?

And then if you outsource, what kind of contract manufacturers should

we be looking into? Let's have some preliminary conversations with them,

understand how they work, get a preliminary quote,

be able to kind of compare those to each other,

and then kind of make an assessment for what the

Thank

proper strategic approach would be.

So that's like a

pretty like hands-on ~ in one way.

Other

Okay.

clients I've worked with is I literally worked on

a manufacturing process development with them because I had a very niche like

expertise in the thing that they were building.

So it was like creating the process of how it gets built,

finding equipment for it, specing the equipment,

finding the vendor, qualifying the vendor,

doing factory acceptance testing.

I went to the facilities of the vendor with them.

to qualify the equipment. got them shipped to their factory.

like very, very much like I was like taping their grounds so that

the equipment could be like placed in the correct place.

So it really depends. I always joke that I'm the happiest when

I'm crawling on the floor of a factory floor.

~

the

And I try to put myself in situations where I do that.

sounds like a lot of fun. ~

you

Before you're kind of crawling on the floor then,

~ what do you typically look at first when you're brought in?

Hmm. I always start with a systems mind map.

That's my, I guess, it's secret sauce.

It's not that secret. I mean, people should do it.

Whereas like, I really need to understand the system that I'm working on.

I usually really like working on complex kind of deep tech,

like industrial systems. So there's a lot of sub components and subsystems

and how they interact with each other.

And then from there, I usually kind of take that system architecture.

and then work with the team to develop understanding around risks.

~ Basically understand like, okay,

what are the risks with these systems?

Are they technical risks, operational risks,

supply chain risks? And then also understand how they interact with each other.

Like if this system risk impacts this one and like what timelines they're thinking

about of deployments. And just that gives me the best like kind

of in-depth understanding of what decisions they need to make and all of that stuff.

And that's kind of where I began.

And then that's how I scope like what I could potentially help them with.

Yeah, I guess you go through a process of,

there's some obvious low hanging fruit here and then there's lots of questions

Mm-hmm.

we're going to, why do you do it that way?

You know, trying to understand how they've got to that.

Now that's, that's

Exactly.

really interesting. ~ So in terms of some of the common pitfalls then,

obviously you go through this a lot in your day job and I know you talk about

it on your podcast as well. Kind of hardware,

horror stories, I think you called it.

So, ~

Yeah.

What

are some of the most common pitfalls that you see founders and engineers fall into?

Yeah, I mean, there's there are many,

many, ~ But I usually try to go into like some deep cut ones where it's like it's

not super obvious. But I'll kind of touch upon what I said before,

where it's like rushing the decision to in source versus outsource.

And this happens sneakily. It doesn't happen like,

~ whoops, we did that. It's engineering teams ~ go and like they spend their gears

and they're like trying to figure stuff out.

They're like, okay, we'll buy this and we'll buy that and we'll get this

and we'll assemble it here. then,

this decision has been made already.

We've moved on. Hold on though.

Like that, that's pretty big because what that does is it creates

the precedent of what maybe the company strategy becomes.

Because if you're used to doing it in-house,

you start to hire people who do it in-house and then you're more likely

to continue doing it in-house,

even if it doesn't make sense with your car competencies that you're trying

to build.

and like what your techno economics are telling you.

So it's like, as an engineer, I actually just recently give

a talk about this at the Hackaday conference.

And a lot of the listeners were engineers and I kind of brought this perspective

to them being like, you might look at this and you might hear me talk about these

things and you're like, that doesn't matter to me.

I'm not a founder.

It's like, no, actually, these decisions,

these things kind of percolate in the engineering part of the organization,

and then they don't get caught until way later.

And then it's kind of like the sunk cost fallacy,

like, we've already done all of this work.

Basically, we should just continue it.

So in my opinion, that's a pretty big one.

In terms of sunk cost fallacy,

mean, sunk cost fallacy is a huge one because you're constantly operating

in this constraint mindset, right?

You have very little money, you have very little time.

So once you've sunk any type of cost or time into something,

there's this inherent attachment to it that I think is pretty problematic.

I don't think this is really startup.

This is like any

Hmm.

one in hardware because it's so hard to start over and the cycles are so long.

But I mean, some cost fallacy with design is really a true thing.

I even had one founder that came on my podcast about it being like,

we were so

headstrong about like how we did this particular thing and we ended

up buying so much of it but then we had to pivot because the market

was telling us that like it was not the right move and then they

had to they basically had a bunch of inventory that they had to basically throw

in the garbage. ~ So that's a big one I'd say.

Yeah, it's easy just to get carried away,

it? And yeah, you're too far down the garden path now.

Let's just

you

keep going. you said to me as well that ~ product decisions define hiring needs.

Perhaps you could unpack

Mm-hmm.

that a little.

Absolutely. I mean, this is just right up your alley,

isn't it? I feel like I'm preaching to the choir.

Well, yeah. ~

Yeah, this is another actual sneaky one because I don't think people think of it.

I think of companies and startups and systems,

well, not systems, but like technology as a system.

Like they're all interconnected and they really touch each other and there

is this inherent dependency that I feel like we keep forgetting where it's like when

you have a product roadmap,

and you have these, I guess, milestones that you need to hit,

you need specific people to be able to unlock that,

which is obvious. ~ But when you're making hiring decisions,

I think it's really important to understand what technical decisions

are going to affect your hiring decisions.

So the example I gave is a pretty perfect one,

where it's like, you're insourcing and you're,

let's say, planning on hiring kind of like an operations person,

Right. If you're, if you're insourcing versus outsourcing,

their background is going to differ drastically.

If you're like insourcing, you want someone that has manufacturing experience,

someone that has process engineering,

~ some type of, maybe they've like trained technicians before,

~ and like internal ops. But if you're outsourcing,

you want someone with supply chain experience,

maybe a little bit of manufacturing,

but more so like someone that understands like vendors,

contract negotiation.

maybe is really well connected in the contract manufacturer world.

So like when you're like, I need an operations manager or I need a

COO and you haven't made this decision,

it's just like, it's risky. It's risky on who you will hire and if it will

be a good fit for what your business will need.

And what happens is if you hire too early,

it will basically make the decision for you in a way.

Because if like you're hiring a COO with

with manufacturing experience,

guess what they're gonna wanna do?

They're not gonna wanna outsource

Yeah, absolutely.

that manufacturing. They're

excited about it.

And so what I usually do, and this is ~ actually a workshop that I gave

in one of the accelerators, was like mapping out skills according

to the milestones that you're trying to hit,

and then understanding your skill deficits.

And then that helps you determine what...

position you need to hire for from the skill deficits.

And then furthermore, you can have your kind of design test build cycles

listed out in a like Gantt chart format kind of,

and then you can have these skills ~ kind of saying,

okay, I need like, this person,

our second cycle of build tests,

so I need to put the job description out now because it takes this much time

to hire. And then you might find skill deficits that are

not a full-time position. And that's also a really good find because

I oftentimes see startups hiring full-time positions and then people either

are super overstretched or opposite,

don't have enough things to do because they were hired for something that could have

been done by a contractor. So all of these really affect,

I think, a startup success.

Massively, yeah. it's certain roles where you don't want them to be figuring

it out on the job either. Like

Hmm.

product discovery and figuring out mechanisms and things like that,

yeah. Maybe that's a lot of the stuff you look at might be unsolved,

know. But when it comes to the operations side,

it kind of pays to have someone who's got a few gray hairs and maybe

you

a few battle scars dealing with supply chains if you're going down that route.

let's talk about tribology then ~ and

Okay.

failure modes. Let's dive into this.

So ~ you mentioned this ~ on our intake call,

but what pulled you into tribology and what is it for those of us,

mainly me, who've never heard of the word before?

Yeah,

so as I mentioned in my introduction,

I decided to pursue a technical master's in mechanical engineering

and focusing on tribology here at Imperial College.

And ~ my whole reasoning for it was because I've been in these kinds of like,

like operational roles, like test engineering and all that stuff.

it just made sense to do a master's and because I have my own business now,

I can dictate my own time. So it ended up working.

and basically as I was looking into where to do it,

Imperial was top of mind because of how good of a school it is.

It has a really good reputation.

~ they also have one of the largest tribology groups in the world,

which a lot of people

well.

don't know. ~ so getting into what tribology is.

So.

for those listening, it is not the study of tribes.

People have asked me, they thought I was doing a sociology degree.

~ That is not true. So tribology is the study of contact.

Basically it's friction, wear mechanisms,

lubrication, and everything

Mm-hmm.

in between. This is something that in our physics classes and in general,

like dynamics classes, we just basically just like the tip of the iceberg

is taught to us. You learn about friction force and that's about it.

and then no one really talks about it.

But tribology ~ really dives deep into what happens

in the contact region and not just dry contact,

but lubricated contact, which is ~ most like bearings,

gears that are in every day everywhere

and how they behave and why they fail and how they fail.

~ and when I started learning about it,

I was just completely infatuated with how,

firstly detailed it was, but also how kind of it seems like uncharted territory

a little bit. There's a lot of newness to it in something that

is inherently the most common phenomena in any mechanism.

Mm.

I mean,

everything works with contact.

So it was, it was just this fascinating.

It

almost felt like a lost language,

lost art type of thing, but super critical and the baseline

of really understanding any type of failure mode.

One particular one that I was really interested in was a lot of,

for example, wind turbines ~ fail due to their gearboxes failing

or their ~ main bearings failing or their rotary bearing bearings failing.

A lot of times it's connected to a tribological phenomena that that's happening.

It's like when you have two contacts that have lubrication between them,

if they are going at a specific speed and the lubrication has a specific viscosity,

virtually they're not touching.

There's a film between them. The lubricant is between the two surfaces.

And so tribology really dives into and the project that I'm working into really

dives into understanding how that film changes according to temperature,

speed, loading conditions and all of that.

And then understanding once ~ that film is no longer there

for any given reason, what does the where look like?

There's different types of where's they happen for different types of reasons.

And being able to understand this and understand the phenomena ~ really helps

to determine how you do maybe preventative maintenance and then understanding

how different materials interact with each other gives you an understanding

of how those failure mechanisms could kind

of conceptualize and instantiate in any types of systems.

So I...

I just kind of grew very fond of the topic itself.

And then I saw its application and transmission systems and gears.

~ So I was basically like, this is just like the baseline

of understanding mechanical failure modes.

And I feel like everyone should learn it and do it and know it.

And it shouldn't be this lost art.

Absolutely. Yeah, so it sounds like it's it's helped you solve quite

a lot of problems as well. Getting to the root cause you can it's a

lot easier than to prescribe a solution.

~

Yeah.

Why do you think it's so overlooked then in mechanical engineering?

See that I have no idea. it is it is something like

the the basically institutions have

~ tribology like There's the this tribology class

and at Imperial is the one that I've seen the most in depth There's other

institutions that kind of touch upon it as like a sub sub topic but

I believe it's a marketing problem,

more so than anything. I've even talked to my professors at Imperial being like,

how is this not like a fundamental,

like you have to take this course.

It's an elective technically, but in my opinion,

it should be one of those courses that like,

for example, we have to take ~ statics and dynamics and fluid mechanics

and thermodynamics. Like these are

fundamental heat transfer. These are things that you need to know

as a mechanical engineer to be able to understand any type of phenomena

and be able to analyze it. So I feel like tribology is almost like

a unit that should be taught.

But this is my personal opinion,

and the professors obviously very much agree.

But

Absolutely,

yeah, think even if this episode triggers three people to Google tribology and start

like really getting interested in that,

think I'll be happy.

We'll

be creating a whole tribe of tribologists before you know it.

Thanks

So we'll definitely raise the flag for that.

So where did the podcast start?

Mm.

And, you know, just give us a note for you.

What were we going through on the podcast?

Yeah, for sure. mean, the podcast was another kind of natural project that came

about because I, the podcast really amplifies the voices of the primary operator.

That's what I really like to do.

The primary operator, the primary engineer.

It's like the, not the Steve Jobs,

but the people that worked on the first iPhone,

which I actually have two guests that worked on the first iPhone.

So it's really about ~ kind of one,

amplifying the stories of unsung heroes.

Two, I'm ~ all about practicality.

Pratik in Turkish means practical.

So I really strive to keep the episodes as informative,

snappy, deep cut as possible so that people who are listening really

get some lessons out and they can apply it to their product tomorrow.

So I got Scott Miller, who's the head engineer that worked

on the iRobot Roomba and got it scaled up in China for the first time.

And they had a lot of like failures and they were unable to detect it.

he had the cow key set that up.

And then I had Ying Liu who was the

person that essentially set up the supply chain of Apple in China from nothing.

So she's

Right.

one of the most impressive guests I've had.

~ And then I got like Tyler Mincy,

who was the ~ project manager for the first iPhone.

So it was just like all of these people that have worked in this like really early

stage, really difficult to scope,

chaotic. ~

environment for these huge companies that later on became gigantic

and really trying to claw at, but how,

but why,

You

really be able to concoct this equation that people can use to apply

to their own product.

How did you get started in the,

you know, the hardware meetup scene and kind of,

what was the best thing about kind of that whole kind of community?

Yeah, I mean, I didn't know about it until a few years ago and I

saw one hardware meet. I think someone just shared it with me being like,

like, you should go to this. And I went to it and ~ the format was really cool where

it was like a few people gave,

we haven't been able to do this in London yet because it's a new and baby community.

So we're trying to baby step. ~ But basically ~ the way that it was,

was they would have two like speakers.

that would present something about like a cool technology they're working

on or like a cool, personal project or just something like I spoke at

one where I talked about hardware pitfalls because that's my current,

~ personal brand is just the girl that cried pitfall.

~ but basically like you listen to these like really deeply technical conversations

and you can ask questions. and then they have an open mic at the end.

where if you're working on something,

you could give like a 30 second pitch about it.

If you actually bring a demo, you have like two minutes to show people how it works.

And it was pretty daunting at first because I went in and a lot

of people already knew each other.

So I just kind of, the odd one out,

I like saw one other woman and I just like went to them being like,

hi. And then I just like talked to everyone.

so this was in Boston.

~ and I got to meet the, ~ the event,

like, hosts that were there.

~ and they, they did such a phenomenal job.

So as I, as I met with them and as I went to,

~ more hardware meetups, ~ I knew more people.

mean, I'm naturally pretty outgoing and extroverted,

so I tend to talk a lot. ~

You

and so I just really loved what it was doing.

~ and I had the opportunity to present my podcast.

~ and everything. then basically Nate,

who is, ~ Nate Padgett, who's,

~ one of the partners at Informal.

~ he was at one of the hardware meetups.

They host them. They are the like founders of hardware meetup basically.

And he asked me like, Hey, you've been coming to these and we like really love your

energy. Would you be like willing to host with us?

Because I, we think that it'll be a really good fit.

~ and then I started hosting a few in Boston.

Some people thought it was my full-time job,

which I was like, no, do I look like an event coordinator?

think I would lose my absolute mind.

I will, I will stay

You

on the lab. Thank you. ~ but, ~ I,

got to, as a host, it was quite different because now people really associate you,

~ with the hardware community,

which is just so near and dear to my heart.

~ and it's, it's just been growing and.

When I told me that I was popping over to London,

he was like, actually, we really want to create a community there.

Like, could you help? have someone that's already working on it.

And then that's how Michael and I got connected to each other.

I just very serendipitously was was in Boston,

so was able to host one there.

And we had 280.

people.

Wow.

And it was like that was how many people registered and about 200 people showed up,

which was the most it was a record shattering participation.

That's nuts.

Community is the lifeline for hardware.

mean, supply chain is based off of community ecosystem.

Support is everything. And so I try to create

an environment where those connections naturally happen and that we

can create a safe space for everyone.

top tip for a nervous networker,

you know, how to break the ice,

how to say hello to people.

I would say focus more on being interested than interesting.

~ I think that's just a good advice for anyone.

Mm-hmm.

I think people love talking about themselves.

Even if you don't like talking about yourself and you're nervous,

that's okay. I think it's really good to kind of ask people,

like, what are you working on?

What inspired you to work on that and kind of drilling into that.

Also in networking environments,

there's no such thing as like pre-created groups or people.

~ Most

Mm-hmm.

likely everyone is meeting each other.

So I think there's this like ~ activation energy that requires you to kind

of step in and talk to people,

but know that they're likely just meeting.

So that's, it's okay. And if you don't have anyone else to talk to,

just come find me. I'm very friendly.

I usually

Yeah.

scout out the very silent people and I go.

I maybe traumatize them, who knows,

but ~ I go and talk to them because I understand it's a huge effort

to put forth and we're all engineers and talking and writing and stuff

is not our forte, so it's okay.

Well, thank you for squeezing us in considering how ⁓ busy your kind

of your schedule is at the moment and best luck with the finals and I will

Thank you. Yes, you will. ~ Thank you so much.

see you tomorrow. ⁓ But thank you for joining us,

Sera. Awesome. Thank you.

It was such a pleasure.

No problem at all. ⁓