Henry Kirk: The Realities of Running a Startup! 🚀
=================================================

by kirupa | Interviews with Creative People: https://www.kirupa.com/podcast/index.htm

Henry Kirk (https://www.studioinit.com/) gives a clear-eyed look at startup life, from the adrenaline of building fast to the less glamorous work of hiring well, surviving cash flow problems, and keeping partners aligned. It is especially good on what AI changes, what it does not, and why credibility still decides whether a young company gets another shot.

Watch the interview: https://www.youtube.com/watch?v=KUG6HpVOgSw
A conversation with Henry Kirk | 1h 01m

ABOUT THIS CONVERSATION

Henry Kirk approaches startups without theater, and that makes this interview stand out. He has worked inside large companies and built outside them, so he can compare the structure of one world with the improvisation of the other. The startup version is faster and more exposed. You move between product, sales, hiring, delivery, and strategy in the same day, often without much separation between them. That broader frame gives the episode its tone: not anti-startup, not romantic, just very honest about what founder work actually looks like once the slogans wear off.

The AI discussion is particularly useful because it stays grounded in business reality. Henry sees software creation getting faster and cheaper, but he does not confuse faster execution with a lasting edge. Teams still have to validate demand, shape the right experience, earn trust, and explain why their product deserves attention. The same realism carries into hiring. In a world where candidates can lean on language models for polished answers, Henry talks about recorded work sessions and closer observation as ways to understand how someone actually thinks through a problem.

The later sections add the lived experience that many startup conversations skip. Studio Init came out of the 2023 Google layoffs, grew through relationships and visibility, and had to survive the usual operational strain along the way. Henry talks about tough client work, partner alignment, unpaid invoices, and using severance money as early runway. He also makes a strong case for public writing that sounds like a real person instead of a polished growth machine. That combination of tactical detail and plainspoken self-awareness makes the episode useful whether you want to found a company or simply understand how one is kept alive.

WHAT YOU'LL HEAR ABOUT

- AI changes delivery speed, but customer demand and trust still decide outcomes.
- Hiring now requires seeing how people work, not just reading their final answers.
- Startups often begin with relationships and visibility before they have a polished product story.
- Operational problems like cash flow and partner alignment can be as important as technical skill.
- Credibility compounds when you speak plainly about both wins and failures.

JUMP TO A TOPIC

- 0:00 - What Founder Work Really Feels Like: Henry introduces the realities of startup life and how it differs from working inside a large company. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=0s)
- 8:00 - How AI Changes the Craft: The conversation explores how AI speeds up software work without removing the harder product decisions. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=480s)
- 16:00 - Winning After Validation: Henry explains why speed matters, but only after you know people actually want what you are building. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=960s)
- 20:00 - Hiring in an LLM World: They discuss interviews, recorded coding sessions, and the challenge of evaluating real problem-solving ability. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1200s)
- 32:00 - From Layoffs to Studio Init: Henry shares how the 2023 Google layoffs pushed him and former coworkers toward starting something together. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1920s)
- 40:00 - Taking on Hard Problems: A demanding robotics coffee project becomes an example of the kind of work the team likes to pursue. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2400s)
- 48:00 - Cash Flow and Founder Scars: Henry gets candid about unpaid work, runway pressure, and the importance of setting partner expectations early. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2880s)
- 56:00 - Credibility in Public: They close on LinkedIn writing, honest storytelling, and why sounding real matters more than sounding polished. (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3360s)

TO LEARN MORE

- Henry's Studio Init: https://www.studioinit.com/
- Henry's X / Twitter: https://x.com/henrytkirk

TRANSCRIPT

The automatically generated captions have been organized by speaker, lightly edited for clarity, and broken into paragraphs for readability. Names and wording may still contain errors.

0:00 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=0s)

Hi everybody. Today I talk about startups and just life as an entrepreneur with Henry Kirk. Henry has the unique experience of working at large companies, working at his own startups, and making the jump between them a few times. Today, he's the co-founder of Studio Init, which he started with a bunch of his colleagues from his time at Google, so over the next hour we're going to have a pretty wide-ranging conversation on a bunch of topics, mostly focused around what it is to be a startup founder. What does your day-to-day life look like? How do you wear multiple hats and remain focused?

How do you hire people effectively, especially when candidates today are probably just an AI assistant away from having the perfect answer, which might mask how talented they truly are? How do you deal effectively with multiple co-founders? And a bunch of other topics that we'll just naturally get to along the way. It's going to be a fun one, so let's get started. Well, Henry, it's great to chat with you.

I've been following your content on LinkedIn for quite some time, so it's just great to get a chance to talk to you in real time about all the things you've been doing and just dive deeper into the other topics that we might touch on during our conversation.

1:09 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=69s)

Absolutely, Kirupa. Thank you for having me. It's a pleasure.

1:12 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=72s)

I like to ask this question of all my guests, which is: you've been working in tech for a long time. What made you decide to start working in tech?

1:23 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=83s)

What made me decide to work in tech? That is a great question. I think I've always been into technology since I was a kid. I was fortunate enough that my dad had a little chain of retail stores, so I was exposed to my first computer there. It was like an 8088 or something like that, with a five-and-a-quarter floppy. He had a full-time database administrator and programmer there. So when I would hang out there on weekends, I would kind of look over his shoulder, and he introduced me to GW-BASIC at the time. So I just got books at the library and kind of got hooked. That was pretty much the start.

I was introduced to it and I thought it was super cool. Oddly enough, I was not a gamer. A lot of people became very into gaming early on when they were into computers. I was more interested in how they worked, and I really liked making software. It was always fun. I had way too much fun messing around with little programs at a young age, so it was pretty fun.

2:37 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=157s)

First program you remember creating?

2:39 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=159s)

Yeah, well, I knew you were going to ask something like that. I was kind of a bored kid trying to channel my energy into computers, and what I used to love doing was writing these little scripts. I would go to computer stores and install the scripts on the computers. They would say things like 'bad command or file name' or mess with things, like putting a fake UI on the screen. Then some sales associate would run over and all the machines were beeping and doing all kinds of crazy stuff. It was fun. This was before Windows was even out.

I used to like doing that, so one of the first programs I used to write was basically just annoying people.

3:26 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=206s)

Was there a programming language you were really drawn to?

3:29 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=209s)

I started in BASIC, and I stuck with that. It was what I was first introduced to, so I would mess around with it. Then, once the internet was out, I started dabbling in HTML and other things like that. It wasn't a programming language, but I started moving more toward web-based stuff. So I was doing BASIC at the time, and then I started doing a little bit of Perl and some PHP stuff. But what I was really interested in, really early on, was Java and JavaScript. I remember getting the books and going through them, so I didn't really have a preference. I was just super interested in learning everything.

I remember one of the bigger applications I wrote years and years ago was server-side JavaScript, which essentially exists today. It's like Node and what that was. I thought it was cool. It was a Netscape thing, and I remember applying to become a certified Netscape Enterprise developer. It was probably 1995 maybe. It was pretty fun. I just loved everything about it. I used to keep notebooks with ideas for programs and sketch things out. It was just a lot of fun. It was much different from kids growing up today when they're introduced to computers.

So I tell my kids that I'm torn now to say those were the good old days, because there are plenty of really cool things they're exposed to today that I didn't have, things that can accelerate their learning or help them dive into something really cool. So it's hard to know if it was actually a good or a bad thing, because back then there weren't websites you could just go to, or YouTube you could check to ask how to do something. You had to figure stuff out on your own. BYTE magazine was a thing. I think Wired had some interesting things.

Barnes & Noble was the place you could go to the computer section and find esoteric books on topics, and you had to figure it out on your own. But beyond that, you learned so much through the mistakes you made, and I feel like today's students may not be getting that same level of depth in some of these areas.

5:59 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=359s)

Some of these areas, that's true. You had to go really deep. There was no Stack Overflow to save you, so it was just getting different books. The hard part was that things changed so much that the books were behind, or you had to really stay on top of it. These days, I mean, obviously books are out of date too, but like you said, there was no YouTube, there was no internet, there were no courses to get or anything like that, so you were really on your own. I feel like the creativity is still there, from back then to now.

When you talk to people, it's just that the mechanism for how they dive in has changed, I think.

6:42 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=402s)

I think, as of the last year, I'm just as excited now about where computing is going as I was as a kid. The things you can do with LLMs and some of the other technologies out there really allow you to accelerate development, because I call myself a product engineer. I like to build things and solve problems with that. I don't necessarily care what the code looks like. I'm sure people will beat me up for that, but I think the outcome is more important, and I don't really care how you get there. I'll try different things as long as I can get the outcome.

So the last year has been pretty exciting.

7:33 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=453s)

Oh, absolutely. I think every generation of developers probably goes through the phase where they're like, the stuff I learned back then may not be relevant anymore, but there are more interesting things to work on. You said you started with BASIC. For me it was actually JavaScript and ActionScript, the early versions from the Flash world. Now, if we were having this conversation 20 or 25 years ago, someone who learned assembly and machine code might have been like, 'Why can't these people learn machine code?' You know, that's where the real magic is, and because they didn't learn it, they're missing out on some of these things.

Right now, with AI assistants, you can have an idea and get code that kind of comes out of it, and you don't think anymore about what version of JavaScript you're using or your Node server. All those little details, all that tribal knowledge you've been collecting over the years, you no longer need, and you're just focusing on the idea. So I'm always curious about what that next version is going to be. 20 Years from now, will people look back at LLMs and go, 'Wow, that's such a backward way of building applications'?

Or will apps, as we think about them, even exist in that form when we think about what the future looks like?

8:41 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=521s)

You're right. It'll be like, 'Oh, what version are you using?' I've been an iPhone developer since the beginning, and I remember conversations like, 'What version of iPhone OS or iOS are you using?' Even for me, and I've been here from the beginning, I can't even remember now. I used to know all the different APIs and the features across different versions, and what the capabilities were across all the phones. Now it's way too challenging. It's too broad and too deep, and it doesn't really matter anymore. It used to be very important back then, but that's completely gone. Now it's just, 'Oh, I'm looking to build this.' Okay, cool.

It's no longer, 'You really have to consider XYZ because of this, and here's a workaround for that.' Things have just accelerated so much. Maybe it's just my bias speaking here, but I also felt like things were easier back then. There was something nice about having a text file, writing some HTML in it, using an FTP client, typing your username and password, and sending it off to a server you paid 4 or 5 dollars a month for. Everything just worked immediately. Whereas I think most people today would probably be like, 'What is an FTP server?' And where does AWS fit in? It doesn't have to fit into that.

You can actually deploy websites without needing all of these complexities. Sometimes I feel like the abstractions are a good thing because they help you focus on bigger problems. If you're on an FTP server and you get a million people visiting it, yeah, there's a very good chance your site is going to fall over unless you have a CDN, which back then was maybe Akamai, and that was for big clients. If you were an individual, you didn't really have access to any of that. So there are new problems that have been created that are great to solve in the future, but things in the past didn't have those same issues.

There are pros and cons to it. But I do always wonder whether the world would have been better if we had kept some of those little details in introductory material, so people aren't completely missing what it took to get to where we are today. Everyone's impatient these days. The clients we work with are startups, so we have to get stuff done fast. Years ago, if we said it took two weeks, it took two weeks.

Now if you say, 'I think I'll be done in two weeks,' they're like, 'Can you get it done in a week and a half?' Because some guy said it could go faster this way or something like that. So the whole industry has changed, and it's challenging to compete because there is an endless number of ways to do what we do. We're no longer very special.

11:25 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=685s)

Agreed. It's always this tension between quality and quantity, and you see it across so many other industries. I feel like software development was somewhere in the middle of it, but you saw early signs in graphic design when Fiverr and some of these services showed up. You'd say, 'I want a logo, and I'm going to pay you 5 dollars.'

Someone in a part of the world where 5 dollars is a larger amount of money than it is in America creates something, and you're like, 'I don't know enough to say whether it's a great logo or just a good one, but it's good enough for me, and I'm going to use it.' We saw the floor on pricing for a lot of graphic design agencies and companies start dropping rapidly. The services people used to provide, where they thought about the craft and the art of how to make a pitch and do all these things, now turn into one email conversation. 10 Or 20 minutes later, you get options very quickly.

And now that same audience is struggling with AI being able to generate visuals and things very quickly as well. We saw this with content creation in general, with tech, editing, news articles, and things like that, where people used to spend a lot of time actually writing detailed pieces. Now it's really a quantitative thing. How many articles can you write in a given day, knowing that one of them might go viral and the other 90 might not? But unless you write all of them, you won't know which one is going to work, because your competitors are doing exactly that using machine learning or crowdsourced technologies and so on.

I think software development is starting to hit that phase as well, where the art of the craft and the things you prided yourself on back then are still valuable, but maybe not as much for certain clients who want something to solve their immediate problem as quickly as possible. Whether it's done by a human being or by some computer, they're okay with it. And the prices for those things can vary wildly, and often we gravitate toward the cheaper options. Yeah, it's true. It sounds like you've been around as long as I have, and way back when computers were much slower.

They obviously weren't as efficient as today, so poor programming practices would really stare back at you. These days the machines are so fast they can mask a lot of the inefficiencies, so you don't really have to write performing code anymore. It's much harder to notice. I think that's been a big change in this whole question of where we fit in. And I think it's providing the guidance and the experience that folks coming into the industry today don't necessarily have. It's like: how do you make the right decisions?

The conversation I have a lot when working with startups is, 'I want to be able to scale to 2 million users.' Well, how many do you have today? 'We don't have any.' Okay, so let's build the infrastructure for the first thousand users, because I guarantee you're going to pivot along the way. If we spend all our time building for a million users, you're going to waste money, you're going to learn things, and you're going to change it anyway.

I see startups that go the million-user route because that's what they think is the right thing to do, and then I see startups that build fragile stuff because someone made poor decisions along the way and they have to go back and fix it. I'm of the opinion that you need to balance it. If your system goes down because you're flooded with users, that's probably a good thing. You'll figure it out and get it back up. But the key is knowing how to make the right decisions along the way to build the product and get it out there, because at the end of the day you're building for users.

If users don't have the product to work with, there is no business there. So speed is very important, and speed is important for being competitive too these days. There are developers all around the world, and they can build things very quickly nowadays. If you have an idea, and I see this a lot when I talk to startup founders, there are a lot of patterns I notice. That was one of them. The second one I think is very interesting is that they always say, 'I have such a great billion-dollar idea,' and then they'll tell me what it is.

And I'm sorry, but you're the fifth person to tell me this in the last month. So one way you can win is to get it out there faster than someone else. Number two is to make it a better experience or market it better. There are a lot of different ways you can compete, but it's about knowing how to do that and what knobs to turn along the way. That all makes it very exciting these days. I mean, the first step is whether people even care that you're building it, and how quickly you can validate that there's interest or desire or need for what you're doing.

Once you have that, then you get to the problem you're mentioning. It could be a good problem to have if a million people are using your website and so on, but taking a lot of time to build for this utopian future that you may never get to because people don't care about it is risky. And the other thing is that you have an idea today. By the time you get your MVP out, let's say 6 months from now, is that idea even still valid or worth it? The speed at which some of these things are moving is incredible.

If you had asked me when we'd get really high-quality video from just text prompts, I would have been off by years. When I saw the first version of Will Smith eating spaghetti, I thought, okay, this is awful. We're not going to get really good video for at least four or five years. Six months later there was a much better version, and another six months later you were seeing videos and even professional commercials generated entirely through AI. If I had been working on the perfect processing pipeline for video and all these things, I'd be lost at that point. I'd already be out of the game.

17:45 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1065s)

Yeah, I can't even... To me it's gone so fast. It's like a blink of an eye. I remember when I first saw that Will Smith example, and it's kind of funny that Will Smith is the benchmark, because you're not the first person to bring that up. It is really crazy how fast things have come. And you know what's interesting that I haven't really seen yet? No one has really gotten the whole AI detection thing done very well. It's not that there are no startups trying to do it, but the next big wave we're going to have is all this fake stuff coming out there.

And I don't just mean propaganda, cons, or government conspiracy theories. I think engagement seekers on social media are going to use these things to prop up their reach and exposure. You can see it now with the DeepSeek stuff that just came out. Folks jump on it and say it's going to replace this or that, and they show screenshots and videos of everything working. Some of it is factual and some of it isn't, but they're doing it because people are looking it up and they want the engagement.

So it would be really cool to see startups trying to build things that can at least say, 'Hey, this is generated by AI.' It could be code, a video, an image, or anything else, just to validate that it's not real. Tying that back together, one of the challenges I have in hiring for our teams is that so many engineers are relying on LLMs to do a lot of their work. I've seen cheating when we ask them not to use an LLM and other things, and that makes it very hard to gauge their ability to do the work without that crutch.

The detection software we use during coding exams catches some of it, and other times we have to watch the video and see the copy and paste and how quickly they do stuff, because I know how long it should take a person to do it. So that's where I'm going with this. Nobody has built anything that's really good at simply saying, 'Oh hey, this was created by an LLM,' and I think that's important. You need to at least mark it, watermark it, or something like that. But I could be wrong.

20:40 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1240s)

Yeah, it's almost like there's this hive mind controlling everybody at this point, because whatever you might be doing as individual thinking or creative thought, you're like, 'I'm going to outsource that to an LLM.' Then all you're doing is acting as the warm body that translates what the LLM tells you into an interview or an essay or something on the screen. You're not really exercising those muscles to come up with these things on your own anymore. That's an interesting one, though. So for these interviews, do you actually have them record the screen at the same time so you can see what they're seeing as well?

I'm a product manager, so most of my interviews are conversations like the one we're having right now. I don't do coding interviews. But how does it work?

21:28 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1288s)

Yeah, I can see. We've tried a bunch of different things. Without giving away all the secrets, for folks who might be listening and wondering how we know they're cheating, there's a piece of software we use for interviews and it has a lot of triggers in there that flag things for us to review. It doesn't say it's definitive one way or another. We ask folks to do it themselves, and that's very, very important. Why? Because I know that LLMs don't write great code, and even if you're the best prompter in the world, you still have to know what's happening, because it confuses itself.

The context windows on some of these tools are not very large, and you need to understand what's going on. We want people to demonstrate that they have the core skills. So it records their screen in the browser, the whole session, and then it flags things along the way and we watch it. A lot of folks either don't realize it or ignore that it says we're recording your screen, don't do this, don't do that. But we can see it by how fast they do things. If they do a coding challenge in five minutes, I know something was wrong. You also see a lot of copy and paste.

During live interviews, we'll see people who did really well on the pre-screening section, where they're asked to code something, and then they get into a one-on-one video chat and they can't actually perform well. So we know something was there. We've interviewed probably 1500 people over the last two years for our engineering roles, and I want to say that more than 50 percent of them have cheated by not following the guidelines we gave for assessing folks. We've tried to make it challenging. We've tried to make it interesting, to pull people out and find the real creative talent and then bring them onto our team, but it's been very hard.

We're about to hire another round now, and I think we're going to have to revisit how we're doing it as well, because we do have to enable these AI tools in a way. I think they're in a state now where it's okay that people use them. We've always said it's okay to use them, but you need to understand how they work to be effective with them. They will be the future, so we have to find people who have the core skills, can still use them, and don't completely rely on them. It's a partnership, and we're still trying to figure out that balance.

24:33 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1473s)

You touch on the common question all over the place, which is: are interviews in tech broken in general? People have been having that conversation forever. But now, with coding questions that can easily be answered by an LLM, where do you stand on that? Do you still think asking coding questions is an effective way of gauging someone's abilities, or are there other things you think would be a better indicator?

24:57 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1497s)

Yeah. There are all these YouTube videos on how to crack interviews and things like that, so you can usually tell when people are super prepared for that. I want someone who is going to solve problems and be creative with it. I don't care if they solve the LeetCode problem in 30 minutes or 20 minutes. What I want to see is how they solve the problem. How they think is more important. So yeah, we do the traditional interview. I was at Google for eight years and Amazon for two before that, so I have 10 years with these interview styles for trying to find really smart people.

At the end of the day, it's how you think. And for the type of work we do, it's also what kind of drive you have and how ambitious you are. Certain things can be taught, and certain things are just how people are raised or whether they have it in them. We're trying to find those sorts of things. So yes, I give the coding challenges and I pay close attention to how people do them. We have multiple steps in our interviews, whether it's for design, engineering, product, or anything like that.

After the initial coding screen, just to see how they think, we'll bring them into a virtual or on-site interview and ask questions to probe how they think. That's all it is. There might be no right answer. We just want to see how they approach it and whether they break down along the way.

26:34 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1594s)

Do you see the tendency to be unable to answer these questions properly without using an LLM as more of a junior developer thing, with people who are just coming into the industry recently? Or do you see it also with experienced developers who've been doing this a very long time, yet maybe they've lost the ability to write code effectively, or they've been working in roles that are different from what they're interviewing for, which happens in big tech all the time?

You might be supposed to be working on one thing, but it turns out you're working on something completely different, and now you're interviewing for something you're supposed to have experience in but maybe you don't. Do you see any patterns there? I guess I'd put it differently. Whenever I subcontract parts of my website and hobby things to other people, I tend to go with the most experienced people. I've known them for 10, 15, and 20 years, because I know exactly that they know these skills inside and out.

Whereas I'm always a little wary of rolling the dice and going with someone newer, because I can't always tell whether the work is truly theirs or whether they used these newer tools to create something that gets past my filter, which is by far not the most tuned.

27:40 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1660s)

There's a lot to it. First off, the job market is horrible for engineering right now, so to be successful you have to apply for dozens of jobs, and that makes people cut corners to get ahead. I think that's part of it. Not only is your resume made or tweaked by an LLM, but now you're also trying to get through the many coding challenges or pre-work that's needed before that. How else do you get through dozens of them? It's just too competitive right now across the board.

When I used to do a lot of interviews, and to your point about folks who were out of their game and coming back into it, I'd see a lot of engineering managers switching back to IC roles, and they would struggle the most. But at the end of the day, it's preparation. If you go into these interviews really well prepared, you'll do super well. If you're not, then that's a problem. I used to do a lot of coaching for people going into interviews while I was at Google and Amazon. I'd always tell them: this is your one shot, be super prepared. Here are the things to practice.

Practice in the environment you're going to be in. Code on a whiteboard. Code on a piece of paper. Get used to spacing, writing clearly, and thinking it through. Those are the kinds of things that made people successful if they had those core skills. That's where people usually broke down. They just jump in unprepared these days. If the market wasn't so competitive, you probably wouldn't see so many people leaning on LLMs to get through these interviews. That's one area where I feel pretty strongly that it really is the circumstances.

But at the same time, there's been such a push for people to enter engineering to get these big salaries that there are probably people who picked the career without really loving it, and they're just trying to stay in it. I can see those folks getting lost and struggling to find the right fit, and then potentially cutting corners to find those roles. When I was at Google, they used to only hire generalists for a bunch of years, and then it started changing. The definition of a generalist was that I can put you in front of anything and you'll figure it out. You're code-agnostic.

You don't have a preference, you don't have a certain stack, you're willing to learn anything. I think that's really important, especially today. You have a lot of folks who are very fixed on one type of tech stack or another, and there's good and bad in that. I happen to think you need a very broad set of skills, and that also helps you make better decisions. Until you've done the whole end-to-end thing and felt the pain of all the different nuances, you may not realize what it takes to build the product and make the right decisions. And there are a lot of solo folks out there too.

Until you've really worked on a team with other engineers, bouncing ideas off people and defending your decisions, you don't have that outlet to improve yourself. So I think there are a lot of different circumstances that draw folks to this, and it could be temporary or permanent. I'm not sure.

31:35 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1895s)

Yeah, no, it'll be interesting to see how it all evolves. It also goes back to the question of whether there will be an AI system that can accurately detect whether something is genuine or not, whether it's someone's actual ideas or not, and that could all feed into it. But as we've seen historically, no matter how good the technology gets for detecting bad actors, the bad actors also evolve and figure out ways of bypassing that detection logic. This is a fascinating topic on its own, but I want to get to the present a bit.

Studio Init: tell me more about your startup, how you got there, and all the things you're working on.

32:15 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=1935s)

Sure,. So, we're- we've been around for just about two years. We were born out of the Google layoffs in January of 2023. My entire org pretty much was cut and, when the layoffs happened, I was a manager at the time and I noticed that it was going to be really hard for me as a manager to get a job. So a lot of us wanted to kind of like continue to work together.

I'm kind of like shortcutting and compressing it down, but, like over a couple week period, I decided that I didn't want to go back to the corporate world for a variety of reasons, and so, a bunch of us wanted to keep working together and think of a good startup idea. So I said like, hey, you know, we were kind of like a startup team within Google. Why don't we try and see if we could do this outside of Google? Inside of Google, we would kind of like do zero to one projects. We would do our own like research and build stuff.

And so I said, you know, hey, we're really good at this, like this space. So let me do a post on LinkedIn. I have, like I think I had like 1600 connections at the time like maybe someone can like connect with with something. So I wrote a post kind of announcing what we were doing and seeing if I can get a couple meetings, and it went ridiculously viral and so that kind of gave us the we were fortunate to have like a little like propping up and get ourselves going, got some projects out of that, and that gave us kind of the.

We had a goal of getting it done by the time. Our kind of like, sance kicked in and so, and also like not everyone's family was kind of on board with us playing business, so we had like a cut off. And so then, you know, we proved that it was a viable concept at least, and so we kept did that and continued to grow it. And so what do we do? We work, we do like product design, engineering and go to market for all in the zero to one space.

So we work with early stage startups and we kind of help them kind of take their like grandiose vision and turn it into something very concrete that would be valuable to users. And we try to back that up with research and get that out the door for them so they can kind of either find product Market fit or raise additional funds or whatever they need to do, whatever their goals are. So we've worked on with a lot of we work. I actually just looked this up today: we worked on 34 projects in the last two years, which is kind of cool, and so, we're still still hanging in.

There had some ups and we've had a lot of ups and downs along the way. A couple clients didn't pay us, and couple startups didn't make it. Some of them did pretty well and but at the end of the day, we like the process, we like the people that we work with and we're. You know I do not want to go back to the corporate world. So every day I wake up, I make sure that I have the mentality that my back is against the wall so I can keep going.

35:19 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2119s)

So, in your history you've jumped between entrepreneurship and the corporate world a few times, and so what makes you feel like this is it? That you're not going to make that switch back into the corporate world again.

35:31 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2131s)

Well, the reason I jumped into the corporate world is that all of the startups I had before that, except maybe one or two, failed, even though I was always very entrepreneurial. I couldn't figure out why. So I thought these big companies probably knew a thing or two about scaling and growing businesses, and I figured I'd go join one of them. I had an opportunity to join Amazon and I said, 'All right, done.' Then that was history. I really enjoyed working at Google. I probably would have stayed there. I was always planning on leaving to do something like what I'm doing now, so it just happened a little early.

But I filled in the gaps. I learned about leadership style, how I worked with teams, and how to make better decisions. I learned how to work better with people. My technical skills grew over the years too. I understood more about user growth. How do you nudge users to use the product? How do you do research? I learned everything I was trying to figure out back then. So why don't I think I'm going back to the corporate world? Because I feel like I've filled in enough of the gaps that I can figure out the rest today, and this is what I wanted to be doing from the beginning.

36:54 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2214s)

So no, I think that's great. When you talked earlier about how you want to validate an idea and then slowly grow it into something bigger and see how it goes, many startups and products have time. You can figure out what the problem is, experiment, try things out, and so on. In this case, you had a very accelerated time window. You needed a startup that was going to prove itself viable within a narrow period of time. So in some ways the process came first, and then it was like, okay, what do we focus on? How do we navigate that?

From how you describe your history, you were passionate about certain ideas and things you wanted to pursue, whereas this seems a little different. It was like, okay, we need a startup now, and the clients might dictate what we focus on.

37:40 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2260s)

Yeah, that does happen at times, but we're a little different. First off, I love the process. I love building things, and I love figuring out the idea and executing on it. While I was at Google, I was having a blast because every 6 months or so we were doing different things, so I felt I was able to be creative. In this business I'm able to be creative too, and we're not spending years on the same product and getting bored. The types of startups we work with are not ones where we just take a list of things and say, okay, we're going to build this for you.

We really work with you. If you said, 'Hey Henry, I want to build this thing. Here's the PRD,' I'm going to ask, 'Do you really need this?' I'm going to tear apart your PRD and challenge your assumptions, all the stuff that you either appreciate or you don't, and we're going to try to help you get to a better place. It could be that your PRD is really well thought out and researched, and I'm just challenging it because I like doing that. Or maybe you'll find things you didn't think of and we'll get to a better spot. I like that part of it.

When we're talking with startups and doing that early dance to see if it's a good fit, the ones that don't appreciate our style of partnership tend to go elsewhere if they're looking to dictate everything end to end. So the folks we tend to work with appreciate that partnership. It's not always my way or the highway. It's a collaboration. Like I said before, some startups will say, 'Yeah, we need to handle a million users.' I'm like, 'Okay, cool. Show me your growth plan for how you're going to get to a million users.' 'Well, in five years.' Okay, five years is a long time. A lot can change.

Maybe we should just start with this. We've been very fortunate. We've worked with really great people, and we haven't had any of those issues where personality differences between us and the startups made anything go sour.

39:52 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2392s)

Do you have any kind of preferences for the types of projects you like to personally work on?

39:58 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2398s)

It has to be challenging. We don't want to just do websites, so we gravitate toward ridiculously hard problems. I don't know whether that's good or bad. One of the most challenging projects we've had in recent times was with an ex-Amazon Robotics founder who started this robotics coffee drive-through company called Ping. They're super great founders. I met them through LinkedIn or something like that, and we had a conversation. He was saying they were going to build this system, and their premise was that you get super hot coffee from the robot when you drive up.

It makes it on site instead of being like Starbucks, where it's sitting on the counter when you order ahead. He was explaining their initial approach to building the software to power the system, and I said, 'I don't think it's going to work. I think this is a harder problem than you realize. I have some experience with that, and I'd love to work with you on it.' So we went back and forth, and we ended up building this presence-detection system. You order the coffee at your house, you're driving up there, and at some point we detect that you're nearby through one of the algorithms we wrote.

Then the robot—well, right now it's powered by humans, but eventually it will be robots—starts preparing your coffee. It knows when you drive up, it knows the order of the people in line, and the people are hidden inside, so you don't see them. The system says, 'Put so-and-so's coffee in the window. Push the button.' The window opens up, and magically your order is there. I've seen videos of the customers' reactions when they drive up and all of a sudden their order is there and they had no idea. It's completely magical. That has been one of the more challenging things. We had issues a couple of times.

I think they ran over one of the beacons we had set up to detect presence, so we had to learn how to harden that a little bit. We went through multiple iterations of the software because different cars have different signals and different thicknesses of glass. I'm not the expert in that space, my partner is, but we built this incredible system that I don't think anyone else has really done. It was truly magical. So we gravitate toward hard problems. That was a lot of fun.

42:43 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2563s)

Well, that's very cool, because whenever you cross from the software realm into the real world with physical things, it's a whole different ball game. My lack of experience there often means I miss obvious things that I would otherwise catch. Like, for example, when you mentioned someone ran over the beacon, I probably wouldn't have thought about that on day one. I'd be like, oh yeah, someone could run over the beacon. The weather could be really bad. A bunch of different things could play a role here. So how much did you end up learning and discovering during the early versions of it, where you were just like, yeah, everything?

43:21 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2601s)

Every day it was something different. The list of 'oh yeah, forgot about that' was completely endless. We finally got it to a really good spot, and now they've raised another round of money, because I think they have a really great idea. They're going to go far, and they're coming back so we can improve it and make it even better. I knew it was a hard problem going in, but I had no idea just how hard it would be, because there were no books on how to do this. There wasn't any obvious 'oh, you just do this' answer.

You can't just do geolocation because it's not accurate enough, and all the phones are different. The thing that got me the most was that different types of cars, and the way they're built, read signals very differently. I didn't truly understand that. I was being very naive, because when we did similar signal processing early in my career at Google, there weren't cars involved. There were just people walking around in the prototypes we were building. So I was like, okay, this really does make a difference. How do you solve for that? It was very challenging, but hopefully I'm answering your question instead of rambling.

44:51 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2691s)

No, you are, because I work both at Google and on my side projects, and I work with agencies and things like that. I'm always fascinated by how they're able to bring in the talent and solve some of these really hard problems. So in your case, do you have people on your direct team who are experts at navigating hardware and software, or do you have your own consultants and clients you often work in partnership with who aren't part of your company?

45:17 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2717s)

Yeah, we don't actually contract anything out. It's all done locally. We don't offshore, we don't nearshore any of the work. It's all us. If we can't do it, we'll pass on the project, or if we have an opportunity to grow off of that, we will. I was very fortunate that one of my partners did his PhD in Internet of Things, which included signal processing and things like that, so we were able to have some very nerdy conversations early on about how to design the overall system. That even challenged some of the hardware manufacturers' assumptions when we were working with them, which was pretty funny. So we were lucky there.

But it was also something I knew we could solve because I had prototyped a bunch of similar things. I've always loved working on magical experiences. Whether it's delighting someone through an app that does something cool, or bridging hardware and software for some kind of outcome, I've always loved that sort of thing. So this was perfect. Even if I hadn't been familiar with it, I would have figured it out. I would have gone to the good old whatever the Barnes & Noble of today is, or the library, and gotten books on it if I had to.

46:35 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2795s)

Yeah. Amazon had their own bookstores for a bit, but I think I've seen a lot of them disappear from malls, so I don't know where people go nowadays. Maybe a library or something like that. I haven't been in a library in years. But stepping back a bit, starting a company is hard. Starting a company with a single co-founder is hard. When you started, you had a lot of co-founders. How were you able to navigate who does what? When does a tie-breaking decision need to be made? How did all of that work?

47:12 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2832s)

Yeah, first off, having partners is hard. It's like getting married to more than one person, so you all have to get along. I was fortunate that I'd worked with all these folks for many years, so we already knew everyone's quirks. The thing that changed over time was everyone's tolerance for handling the craziness of a startup, the ups and downs, whether we were going to make payroll next month, whether we'd earn some money, whether we'd finish this project on time, or whether we'd get the next project. That was what really caused most of the bumps along the way. We also had some challenging clients.

Like I said, a couple of them didn't pay us, and one in particular was rather large. We worked for months and months and they never paid us. We had fronted a lot of it. We put our severance into seeding the business, and that evaporated pretty quickly. So it was just challenging. So how do you navigate partners? You need to set expectations ahead of time and agree on who does what. Everyone had their skill set, since we built the team together, so we already knew what everyone was good at and we each kind of did our thing. No one ever stepped on someone else's toes.

But at the end of the day, the life of a startup led some of the partners to decide to move on and do something else. I'm still crazy, so I'm still doing it. We're still a startup and we're on our way, but we're not completely there. I'm the type of guy who, once I go into something, I'm not going to stop. I'm going to figure it out. I'm very stubborn in that way, so I'm still hanging in there. My advice to anyone else is: know who you're building a partnership with. You may think you know people, but trust me, once money gets involved, things change very quickly.

49:20 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=2960s)

I think people's tolerance for risk and for navigating the unknown is often very different too. You mentioned that you worked with a lot of them at Google, which is a large company. There are a lot of processes in place there, where what might feel like chaos inside a large company isn't chaos at all compared to a startup. In a startup there is no box. There isn't a boundary where the worst thing that could happen is A, B, and C. There's no container. Things can go in any direction, extremely high or extremely low, and there are basically no seat belts.

You often find that individuals who think of themselves as very risk-tolerant are not risk-tolerant at all, because their basis for measuring tolerance doesn't apply in startup world.

50:09 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3009s)

That's true. Your ability to tolerate risk is really what makes or breaks your ability to hang in there. You can join a startup early on, after some of those things are figured out, and be very successful, and there are plenty of people I know who purposely look for startups at that stage. But the very early stuff is not for everyone. It's super stressful, but for some reason I like that.

50:38 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3038s)

Call me crazy. I mean, they always say certain personalities tend to thrive in these kinds of environments. The conviction that there is a destination you're going to get to is a big motivator for many people. It helps them do well in startups because they know there may be chaos and hardships along the way, but they're still laser-focused on the destination. I think that founder mindset, which you clearly seem to have, plays a big role in keeping things moving.

51:09 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3069s)

Yeah. You learn a lot. One reason I feel I was able to start my career at Amazon was because I had all that startup experience. During the interview, a lot of the folks I was working with on the iOS team there hadn't encountered the things I had, so I think that made me unique. Maybe that helped me get the job. It's because I'd been through all of that and had been responsible for so much on my own, having started things up and failed. If you can hang on long enough, there are plenty of opportunities to learn. Then if you embrace those learnings, it helps.

I make mistakes all the time, but I look forward to those mistakes as long as they're not super bad, because then I'm not going to do that again and it'll make me that much better in the future. I don't know. I just love the chase. I love the ride.

52:04 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3124s)

And with startups as well, you mentioned that people have areas of expertise they focus on, but it's also very fluid because you wear many hats. You might be doing marketing one day, core development one day, and negotiating payroll or business deals another day, and those skills are hugely invaluable. Like you mentioned, your startup experience helped you join Amazon and do some of these things. I always find that too many people try to conform when they go to large companies.

They ask, 'How can I do exactly what everyone else is doing so I fit in?' But the more successful ones are the people who have a variety of experiences and can say, 'Why are we doing it that way? That doesn't make any sense. Let's do it differently.' And they're not saying that just to be difficult. It's the diversity of experience they got from doing startups and things like that. For someone with your background, that would have put you far ahead of someone who had spent many years inside a corporate environment like Amazon and never had the opportunity to think differently about how things are done. So it's almost an advantage.

53:09 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3189s)

Absolutely. I think it's real-world experience. You're really in a bubble in those companies, like you mentioned before, so having a broad set of experience is important. A lot of folks ask me for career advice, and I usually say: try to join a startup for the first couple of years, because you'll learn more, then enter big tech or something like that. If you go into certain big tech companies too early, you end up with bad behaviors that don't mesh well in the real world, or you learn things that are completely not applicable.

There were certainly systems at Google that I worked on where, I mean, how many companies in the world have to deal with a billion users? It's not really valuable to you outside of that. It may help you understand how to scale things, but it's not useful in the same way. So I usually say, hey, go have fun on your own. Do something like that for a few years, then go, kind of like I did, fix your mistakes by going to bigger companies to round yourself out and fill in the gaps.

54:21 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3261s)

Yeah, that is so true. Now, speaking of career advice, you also have a leadership podcast. I watched a few episodes just to get a real feel for whether you were AI-generated or real. For all we know now, I could not be a real person either. I could just be an avatar with prerecorded audio samples creating all of this. So how do you balance your time between it all? You mentioned at the very beginning that having a good idea is part of it. How you market it is a big part of it too. I think you're very effective at the marketing piece, because your posts are compelling.

I scroll through a lot of LinkedIn posts in a given day, but when I see yours, I actually stop and read because they seem genuinely interesting. So you have the hook figured out, and of course you balance that out with your podcast, where you go into more detail on these things. There's a marketing capability there that I think sets you apart.

55:16 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3316s)

Oh, thanks. I appreciate it. I consider myself a little extroverted. I'm not your typical introverted engineer, and I like talking to people and being out there. When I made that first post on LinkedIn, I did a little reading to figure out how to write a useful LinkedIn post, but I'm not a social media guy. I had never gone viral or anything like that. But when I did go viral, I kind of figured out what I had done right, and I knew I had to keep up the writing and communicating. I've always been a very direct person, so I'd rather tell it how it is.

I didn't want to come across like one of those fake gurus, where you have one hit wonder and then you're selling a 49-dollar course to teach people how to get where you are. I've had successes and failures, and there are things I could tell you about the failures that would blow your mind. I try to be honest about them and explain what creating a startup, or just a business, is really about. I think that has resonated with people. So my style is just to be legitimate, share the things I think are important, and be real. I have no agenda.

At the end of a post, I don't say, 'Hey, if you like this, go subscribe to my newsletter,' or 'Please follow me,' or anything. I just share, and if people choose to follow me or read what I have, great. I started a podcast because one of the most valuable things I did throughout my career as a leader was have a coach. I wanted to show folks what coaching was all about, so I teamed up with my coach, Jonathan Aronson, to do the podcast. We haven't done it in a while because I've been a little busy, but ironically he wanted to start it up again this year.

It turns out we've had some evergreen content over the last year. We were posting episodes and no one was watching them, and all of a sudden we have hundreds more subscribers and other things, so we're going to try it again. Why did I do it in the beginning? Again, it was part of the whole larger thing: I wanted to share. A lot of people reached out when I announced what we were doing, and my goal was to flip the layoff into something positive. Everybody was saying, 'I'm laid off. It's the end of the world.

I'll never recover.' And I was like, okay, I'm going to turn this into a good thing that I'll look back on in a couple of years and say thanks for, which I pretty much did a couple of weeks ago. So that was the benefit. A lot of people reached out asking, 'How do you do it? How do you stay motivated? How do you find the time?' A lot of this was just an extension of that. It was like, okay, here are some secrets I have and some things that might be helpful to people.

I never wanted or thought I would earn money off it, or that it was part of the marketing plan. It was just, let me try this and see how it goes.

58:43 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3523s)

It also helps you not lose touch with what coaching often goes into, because you're so focused on startup life and actively solving these problems for your clients. At least for me, one reason I do some of these podcasts is that I get to meet really interesting people, but I also learn so much through the process. When I did research to talk more about you, I was like, wow, there are all these really cool things I never would have thought about. For example, you have an app like Schedulator. So I'm like, okay, how do you balance the time?

You're doing all the startup work, all this client work, and also all this public-facing content for LinkedIn. I know those posts may take 30 seconds to read, but they probably took a lot longer to create. It really is the typical iceberg principle. What we see is only a small fraction of the effort it took you to create all these things. So how do you find the time for all this?

59:39 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3579s)

I work constantly, Contex, I work constantly, I'm very fortunate that my family is very understanding and understands the mission that I'm on- to kind of like reinvent myself after being laid off and get back to like where we were. And so, yeah, 7 days days a week, seven days a week, I wake up, I get up before 500 every day and I either hit the gym or I start working and I work till 9- 10 o'clock at night and I crash, wake up again. I do it. It's one.

Some of the things that I try to get across is that it is a there is no 4H Hour Work Week in what we do, and so I preach that a lot. It's because I think that sometimes folks make it seem like like I don't want to make a presence, that it's not that I don't have sleepless nights and it's not super hard. It is incredibly hard what we do and the amount of effort that it takes to do this. You know, especially you're wearing multiple hats. So, yeah, I'm doing the sales and marketing, I'm doing the post to try to like support that, we're doing.

You know, apps like the schedul lator, which is part of our Venture Studio, which is part of our long-term vision of like having our own startups and things that we want to cultivate and build and, you know, not have to rely so much on, you know- client work and stuff like that. So to do all of that and to still serve as clients, it takes a lot of effort. So I'm basically working two, two full-time jobs.

1:01:03 - Kirupa (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3663s)

And you still have time to chat with people like me on this. So, Henry, thank you so much. That was quite the journey. Best of luck, and hopefully we'll keep following along and do this again in the future.

1:01:18 - Henry Kirk (https://www.youtube.com/watch?v=KUG6HpVOgSw&t=3678s)

No, I appreciate this. Awesome. Thank you for having me. Hopefully some folks find it valuable.


Browse all Interviews with Creative People: https://www.kirupa.com/podcast/index.htm