Han Yuan 0:02

Welcome to Career Journeys Revealed. I'm Han, and along with my co-host Sitesh, we unpack the career stories behind technology's most impactful

Introduction

Han Yuan 0:18

transformations. Today, we're diving into a journey that spans the entire evolution of the modern internet. What does it take to go from writing web servers in assembly language to leading AI companies. How do you scale from handling a billion ad requests per day with hardware less powerful than today's smartphones to building teams of over 80 people? And what happens when you realize that being a Delta Force engineer isn't enough, that the real challenge is teaching others to solve impossible problems too. Today's guest has lived through the entire evolution of the modern internet. Steve Heyman started at Flycast in the late 90s, one of the earliest ad networks, where he literally invented the technology that powers much of today's digital advertising. When their web server crashed every hour under the load of a billion daily requests, Steve didn't just fix it, He built an entirely new one from scratch, driving physical servers to data centers at 2 a.m. and debugging live traffic with millions of dollars on the line. But Steve's story isn't just about technical heroics. He was there when Yahoo Music Engine pioneered the first all-you-can-eat music subscription service before iTunes, before Spotify, before anyone believed streaming could work. as part of a tiny four-person team inside a massive corporation, he learned the art of juggling impossible technical challenges while navigating the complex politics of a company trying to do everything at once. What's fascinating about Steve's journey is how he transformed from someone who could single-handedly solve the hardest technical problems into someone who could build organizations that solve them at scale. he realized that being the smartest person in the room wasn't sustainable. The real skill was breaking down impossible challenges so entire teams could tackle them together. From founding multiple companies to serving as CTO for Dynamic Signal, which he helped grow from zero to tens of millions in revenue, Steve learned that the path from engineer to executive requires mastering entirely new domains. understanding customers, navigating sales, and making the hard decisions about when to chase cutting edge technology versus when to focus on what actually moves the business forward. Now, as CEO of SnowOwl, he's applying those lessons to the AI revolution, building workflow automation platforms that don't just showcase impressive technology, but actually solve real problems for real companies. This is a masterclass in career evolution, from the technical trenches to the executive suite. Steve's going to share the frameworks he uses to balance innovation with execution, the organizational challenges that taught him to think beyond code, and the three key principles he applies to every decision he makes. So, Let's dive into this remarkable journey from assembly language to artificial intelligence, from individual contributor to CEO, and discover what it really takes to scale not just systems, but entire organizations.

Hitesh Chudasama 4:09

Welcome everyone for another episode of Career Journeys Revealed. I'm your host, Hitesh, and I have with me my co-host, Hanh. And today we have a great guest whose name is Steve Heyman. He's been a technologist for the past 20 years. He started and been a CTO for multiple different companies.

Steve's Background

Hitesh Chudasama 4:32

He was recently a CTO and a founder at Dynamic Signals, which is now FirstUp. And currently he's focused on his new company, Snow Owl. Welcome, Steve.

Steve Heyman 4:44

Thank you, Hitesh and Han. Great to be here.

Hitesh Chudasama 4:46

Steve, it would be great to go ahead and if you could share with us your highlights of your career journey, just in a high level in regards to what are some of the different things that you've done. And then what we'll do is that we'll go ahead and dive into it further.

Steve Heyman 4:59

Sounds great. So I've been in the Valley for 25 years now. I've seen a lot of different companies along the way. I started at a company called Flycast, which was one of the earliest ad networks. We invented ad network technology, lots of very powerful technologies around handling requests, billions of impressions a day back in the late 90s. And I'll tell some more about that later. I worked at a company called Comscore doing market research, worked at Yahoo, where I was one of the main developers. co-creators of the Yahoo Music Engine. After that, I helped found my first company called Adify, which was another ad tech company focused on private ad networks. So taking some of the concepts from Flycast and extending those into a new direction. After Adify, we left the ad tech world and focused on dynamic signal. which is employee communications and engagement. We built technology to help companies talk to their employees, not one-on-one, but how do I talk and have conversations with thousands or even hundreds of thousands of employees? After Dynamic Signal, here I am now CEO of SnowOwl, which is an AI workflow automation platform.

Hitesh Chudasama 6:35

Great. Thanks, Steve. So let's go ahead and maybe rewind back. I mean, you started your journey as an engineer and being an IC, and just similar

Sometimes You Can't Throw Hardware at a Problem

Hitesh Chudasama 6:45

to Han and myself. And maybe if you could go ahead and talk about some of the projects that you worked on, maybe a challenging one that has taught you a lot of lessons, especially as you excelled in your career going forward. Is there any particular project that comes to mind?

Steve Heyman 7:00

Definitely. The first The first really interesting one was building a web server for Flycast. So if you think about, if you set your mind back, maybe before some of your listeners could even use a computer, they were little kids or maybe not even born yet, there was a big problem. How do you handle a billion ad requests a day? This was before cloud existed. This was before Docker, before scaling, before auto scale. We had to do it all ourselves. So the web server that we were using, it was this ancient web server called Zeus. Zeus would crash every hour, literally every hour it would crash. My project was to write our own web server. So I built one completely from scratch. using back in the day. This was in C. This even had some assembly language in there. So really bare bones. You would not recognize what things were like back then if you're a developer today. There was no frameworks. It was all just written in C. And so my job was to build a web server that could scale to a billion plus requests a day. on hardware that's less powerful than any of the iPhones that are in your pocket. So that's the project.

Han Yuan 8:30

Were you ever scared that maybe you couldn't pull it off?

Steve Heyman 8:34

I wasn't sure if it was possible back in the day. I spent a good few months on my own writing the code, testing it, coming up with how to even test it, right? How to even simulate that many requests. Finally, I was pretty confident it could be done. But then the real challenges started. So what we realized, and this is completely obvious now to anyone involved, but you cannot do it on one or two or three machines. You had to use a lot of machines. So we ended up driving down to the data center and installing 20 new servers. Again, this was way back. So there's no way to auto-scale. You couldn't turn on AWS and say, oh, I need 50 machines, or we physically drove them down there, installed them in the data center with the air conditions blaring. So it was not just a software job at that point. It was very hands-on. I have lots of respect for the ops guys from that experience. We got it all up and running. We did some early testing, and then we cut over to make those servers live. They would stay up for about two minutes, and then they crashed. And this was at two in the morning. And this was live traffic, and we couldn't fail back because the other servers were crashing too. So the real struggle was, all right, I've got live traffic. Every second we're down is costing money because these are paid ad impressions. And so what do we do? So I was sitting there with a laptop and trying to log into one of the servers and there was a two line bug. You know, all bugs are like one or two lines, right? There was a two line bug and figured it out, was super happy. We got it live and it started working.

Han Yuan 10:36

Wow.

Hitesh Chudasama 10:36

That's great. That's great. The fact that you guys were, you know, persistent in regards to just keep on working on it, especially at that time, because there's not a lot of support and you have to go and figure everything out yourself.

Han Yuan 10:47

Yes. That's a tricky scaling problem because presumably the traffic is a little bit bursty and you can't you can't scale it to whatever traffic you have at the moment. You know, Hitesh and I ran into an issue where this was back in the Elance ODesk days where we had a physical data center and we were running out of servers and we couldn't order them fast enough because the lead time was three months. We were really screwed. Like, there's this whole business of over-provisioning. You had to work on those models too, right? To actually say, hey, this is how many machines we need to be safe.

Steve Heyman 11:20

Yeah, we ended up working... with Compaq and HP back in the day, like names from the past. And they would send us servers. They would send us different caliber, different grades of servers, and we'd have to test them out. We ended up using one server that had like four physical CPUs, right? Like with boards, when you plug in the boards and the boards would expand. And it had, at the time, an outrageous amount of RAM. I think it was like eight gigs, which today sounds like nothing, but again, back then. And so we had to use multiple of these servers just to test drive the web server that we were simulating. So then once we figured out the hardware profile, then we were able to place the order But we were ordering, again, same as you, you were seeing just lead times were long, and you had to have enough overcapacity to be able to handle it till the next servers arrived. What I learned, though, is, and I mentioned how I used assembly language, right? So nowadays, no one would even think of doing that. I mean, maybe if you're writing a kernel driver for an OS, but sometimes ordering You can't just throw hardware at the problem. You have to be creative. Whether creative is an algorithm or creative is taking a piece of C code, unrolling it, and turning it into something that uses half the instructions. Sometimes you just can't throw hardware at the problem. It's just there's a huge limitation. So you have to be prepared to really learn how the optimizer works and learn how the profiler works and really try to cut the number of cycles.

Hitesh Chudasama 13:06

You're definitely at the forefront of innovation at that time. I

Single-tasking Isn't Always an Option

Hitesh Chudasama 13:09

know another company that you were a part of, and I think a lot of our listeners know about this company, Yahoo, and you were part of the Yahoo music team and coming up with the Yahoo music engine itself. Maybe can you walk us through what exactly were some of the problems that you were facing at that time and what led to that creation?

Steve Heyman 13:32

So the Yahoo Music Engine was the first all-you-can-eat subscription download service. So iTunes existed for the iPod. This was even before the iPhone was released. And you could buy your songs for a dollar each. Or you could listen to music I mean, music streams, like someone else would curate the music for you. The goal with the Yahoo Music Engine was to let you download as many songs as you want onto your device as long as you were paying the monthly subscription. So we had a small team. We were brought in by Yahoo Music. My friends and co-workers had started another company. It was a little acquisition. They were brought in to build the Yahoo Music Engine, and they brought me on as well at the time. So we had a lot of interesting challenges on that project, both technical challenges as well as sort of operational and organizational challenges. We had to build something that would run mostly on the PC, would talk to all the Microsoft music devices, the iPod, Creative Labs back in the day, like all of these companies that have mostly gone by the wayside now, except for Apple. We also had to implement DRM, which no one likes. We didn't like it much either at the time, but it was the only way to make it work. The music companies, this was a very high-risk project in terms of convincing the record labels that this was going to work. So I think it had to be secure from their perspective, and it had to be... You couldn't jailbreak it or... And so I was assigned the DRM project, as well as the front-end UI on the Windows GDI client. So a couple really, really, really distinct projects that I was working on at the same time. And what I learned from that is just how important it is to be able to juggle lots of different balls in the air. You know, sometimes as a developer, you really want to focus in on one thing, and that's great when you have the opportunity to. But sometimes you need to just bounce back and forth between 10 different things all at once and keep your sanity in the process.

Hitesh Chudasama 15:59

What were some of

Large Company Organizational Challenges

Hitesh Chudasama 16:00

the organizational challenges that you faced at that time at Yahoo?

Steve Heyman 16:04

So Yahoo was a very big company at the time, very obviously very well known. They had everything from Yahoo Messenger to Yahoo Music to Search to just everything. And it was a great company back in those days. It was really fun to work with. The organizational challenge we had was, how does our four-person team, who's trying to build a really ambitious software project, also integrate with all the different Yahoo products, product lines? So for example, we... we had this concept called music over messenger. And the messenger team and the music team wanted to cooperate so that when you're playing music in your Yahoo music engine, it would show what song you were listening to. And then your friends who also subscribe could listen in and really kind of have a, you know, you could have a group radio stream almost, which was a really cool idea. And we got it working. The biggest challenge was we had four people on our team. Sorry, Messenger had about 20 people on their team. So how do we keep up with them? How did they not bury us in the process of building these integrations? So we really had to be careful about picking and choosing what integrations we wanted, getting all the input from all the different PMs and stakeholders at the company. and then build what we could to really make sure that the experience was great as we were trying to scale up the hiring on the music engine side. I would say one other interesting thing about Yahoo. Yahoo was going through, we didn't know it at the time, but Yahoo was going through an evolution, right? Kind of going from kind of one of the early giants of the internet age to more of a, know more of a company that was in the process of being overtaken in many ways sadly because it was a really good company yahoo is not nearly as well known today as it was back then but in hindsight you could see that there was a lot of different areas that they were trying to work on all at the same time engineer i was able to focus on my product for the most part but just watching how the company worked you could see that they were having us work on varying different aspects instead of instead of keeping the focus on one or two things and doing those really well yahoo was trying to do everything and then that led to the yahoo music engine like we were trying to do all sorts of different things to tie into all of these different goals and i think that was a um That was a big kind of organizational challenge at Yahoo in general, and then something that was, you know, something that

From Product Builder to Organization Builder

Steve Heyman 19:04

trickled down into our team.

Han Yuan 19:07

In both stories, you're working on very serious things. Like, you're working on problems that, for better or worse, I think are somewhat captive to very specific individuals who have a lot of talent. You know, ostensibly you. And... maybe just a few other people. Like your teams were small, you were working on hard problems with quite a bit of scope, even at a massive company like Yahoo. My question for you is, you spent all this time as an elite IC. At some point, you did move into management. Why would you do that? Because... You know, you're very good at solving ridiculously hard problems, right? You're like a Delta Force type engineer. What got you even curious about that? I

Steve Heyman 19:58

always thought that solving hard problems is fun. I always liked doing that. What I saw, though, is the opportunity not just to solve a hard technical problem, but to solve how do you solve these problems at scale, right? It's great to have one or two really strong engineers, but to really build a company, you have to pull these problems apart and make it so you don't need, to use your term, a delta force engineer to solve the problems. You have to start breaking them down into things that are much more tractable. It's not really realistic to assume that you're going to find one guy or one person who can figure out how to write a web server for a billion requests a day. I mean, I pat myself on the back a little bit for figuring it out, but it's not really a scalable solution. And so what I started looking at was, you know, I wanted to start a company, lots of people do, and what's needed is to, how do you take that the skill set of being able to solve those problems, but break it into how you can have a whole team working together to solve a problem so that it's not all focused on one person. If they're out sick, what do you do? If they decide to move on to the next company, what do you do? So I really took that as sort of an extension of the hard problem solving to get into the management side of things. And that's what I really like to do. I like to be a... I'm very technical, but I also like to solve the problems from an organizational scenario. How do you hire the right team? How do you get the right people? How do you get them thinking in the right way so that all of a sudden these crazy hard problems can now be solved as a team and understood as a team? And so that's a lot of what led me down that path.

Hitesh Chudasama 22:02

Steve, just to follow up on that.

Understanding the Customer

Hitesh Chudasama 22:04

So as you went from being a developer and starting your own company, being a founder, what were some of the areas that you found that were something that you had to go ahead and focus on much more? Because technology is something that you had worked on for many years. Like for me, when I moved in more into management, especially upper management, finance and sales were some of the areas that I had to go ahead and really dig in to understand because it was not as intuitive as what I had thought. And so like for you, for your journey as you went through becoming a founder, what were some of the areas that you felt like you had to dig in and put a lot more time and attention to?

Steve Heyman 22:44

Both finance and sales are definitely up there. I'll start with one other before that, understanding the customer. So when you're an engineer on a very purely technical project or even on a project like Yahoo Music Engine, which was a consumer project, project, we had the luxury of letting other people understand the customer to kind of give us the specs. You know, you're an engineer, you get some specs, you have a discussion, you do your stand up, and then you go off and write code. And if the specs are wrong, that that's a shame. But, you know, your job is to, generally speaking, build the project, ask technical questions, etc. As you move up into management, either technical management, CTO, or much more importantly for my current role as CEO, you have to really understand your customer. What do they want? What do they need? What are they telling you? What are they not telling you? And what do they think they need versus what do you think they need? There's a lot of nuance there. So I think that was one of the biggest areas of kind of broadening my horizon or my mind in terms of really understanding the customer. So you need to be a good PM in addition to being a good engineer. You also mentioned sales. Certainly at the CEO level, sales is a huge part of it. I'll talk a little bit about that with Snow Owl. But even as a CTO, anyone in the C-suite has to be able to go meet a customer, convince them, why the product is great from your vantage point, like either technically or operationally, and be able to put the company in the best light, put the product in the best light, and help the actual seller on the ground or the person running the deal close that deal. So those are a few big things as you sort of move from individual contributor through sort of skipping through the middle level of technical management, but really as you get into the C-suite. It's knowing the customer and being able to help the sales team close. Yeah,

Hitesh Chudasama 24:53

great.

Building for Customers Versus Building for Market Segments

Hitesh Chudasama 24:54

So as a CTO of a couple of the companies that you were part of, is there one particular major project or initiative that you recall which was something that you felt like it stretched to you in regards to not just collaborating internally but also with the customers as well as making major changes within the company?

Han Yuan 25:17

Yeah.

Steve Heyman 25:18

I was at Dynamic Signal for... 10 years, helped start the company, grew it all the way to lots of revenue, high tens of millions, and grew the team from zero people to something like 80 people. So along the way, there were quite a number of inflection points. But I think one of the biggest was your whole goal is to get to a million dollars ARR, right? That's like a huge milestone. Then if you can get to two, and you can prove that it wasn't just a fluke, right? And then you get to 10, and then you get to 20, 30, 40, 50. Each of those stages requires a different thought process. Though really one of the most interesting ones that I've been lucky to see is when you get into that tens of millions of dollars of ARR. You have to all of a sudden switch your focus from individual customers to really what does the market ask you for. Even in the millions, the low millions, you can still build things for one customer, close a deal, and fold it into your overall product. But that just stops working at the scale of tens of millions. Every customer has their own special situation. They have their own requirements. They have their own needs. The real important thing for engineering is to make sure that you are addressing the overall market successfully. At Dynamic Signal, we had customers that were paying us six or even seven figures a year. So when a customer asks for something and they're paying you a million bucks a year, they want it, right? They expect they're going to get it. So we had a customer who really wanted a particular feature and it was a hard feature. It was a video live streaming functionality. And what we had to do was figure out how to turn that into a product that this one customer could use, but we could also sell to the rest of our team. Sorry, the rest of our customer base. And it was a very challenging project. We never fully realized the goal that our initial customer wanted. But what we were able to do was leverage this capability at a reduced scale for a lot of our other customers to really deliver on something that was really meaningful and really productive and did help our sales numbers. We sold a lot of business there. But ultimately, you have to make the right decision for the whole company. And that might be, unfortunately, sometimes you can't deliver everything you need to for one customer, but you have to do it for the good of the overall product. So that was an interesting learning point that even though you might not quite deliver what the initial person wanted, you still ultimately can succeed.

Han Yuan 28:13

I guess a

Making It Work Versus Making Computer Science Projects

Han Yuan 28:14

follow-up on that, and I think there's a bit of a dark art here that you alluded to, sort of the challenge of running the business and what the market needs. Then there's the business of running an 80-person team. and making sure they build the right thing the right way in a way that ostensibly addresses said market needs. And there's a dark art there because I think as technical people, we have a passion for doing things well, doing things in a scalable way, in a robust way, in a repeatable way. We're excited by novel challenges. And so as a CTO, do you have frameworks on how you balance these really different tensions between... the technical staff, and the business staff? Because in some ways, like it or not, as a CTO, you are in some ways the arbiter of really big decisions for the company.

Steve Heyman 29:12

So I'm going to answer that, but in the context of Snow Owl. So Snow Owl, I'm the CEO now. So I'm even one step above, although we're still a small company. So it's a slightly different scenario. But there is absolutely a... point of diminishing returns. As a technical person, you want to build the best product you can. You want to build the coolest product you can, the most innovative, the one that uses the most cool new technology, whether it's for just the pride of saying you did it or helping you get experience with new technologies. So there's a definite bent towards just making it better, making it better, making it better, keep going. On the business side, you need something you can sell. And you don't always need the best product, but you need one that solves someone's problems. And there's a real... There's a real tension between that. And like you said, it is an art. It is a bit of a, it's an optimization problem to put it in engineering parlance, but it's not one that's purely numerical that you can just go look at to see what the results of the test were. It's very much a judgment call on an ongoing basis. You get asked by your engineers, you know, does it need to do this? Should it do that? Can we get away with this? or not. And they often want to, you know, just the nature of engineers is they want to make it work really well and be really solid. But sometimes you have to make those compromises. So on our product, workflow automation, there's a big tension between how much time do you spend making the user interface is easy to use, or the AI is flexible as possible, or do we jump right into Claude 3-7 Sonnet because that came out last week. Your natural instinct is, it's brand new, let's go for it. But sometimes it's much more important to set the stage by building an integration with the web app talking to the corporate website so you can go and make a better hook to sell the product and put a little nudge in to get people to upgrade, right? So we're working on very, very high-tech, cutting-edge AI, lots of the coolest technology around right now, right? But sometimes you have to step back and really say, what's going to move the business forward? What's going to help sales? What's going to empower the team to close that deal as opposed to just going off and staying in engineering land and building more and more high tech. So absolutely a great question and it's a balancing act that CTOs have to play, good CEOs have to play as well. And I think giving your engineers the understanding of why you're making a decision is one of the critical pieces because they have to understand and know why all of a sudden you're saying, okay, you know that really fun tech project you've been working on for a few days? We got to put the pause on it and go back to doing some other stuff that's much maybe less fun and interesting, but much more important right now for the business.

Han Yuan 32:39

Do you have a framework for maybe figuring out what may or may not be the business impact of not doing something or doing something? And I say that because the space is just moving so fast you know mcp went from from my point of view like a blog post

Frameworks for What's a Fad

Han Yuan 32:55

and a very crude spec like maybe less than five months ago to an explosion um where we're now seeing mcps all across the internet there's an active discussion around you know as entrepreneurs you know, who is our customer to your earlier point. And there's a legitimate argument to say, you know, maybe some of these customers are actually like AI. And so that has all kinds of implications on, you say, how you would build an interface for SaaS software. So, and I say all of this because just as a very specific example of how the, like the landscape of, you know, what you're building, who you're selling to, even that could change. And so when an engineer comes up to you and says, hey, we should try this or that, do you have a way of quantifying you know, whether or not we should or should not do it or what could be the business benefit? Because it seems like it can't be completely just, you know, I feel like it as the CEO or is it?

Steve Heyman 33:50

That's a great question. In some ways for the CEO, it is I feel like it. Like there's a lot. But let's put that aside. Let's say you're not the CEO, but let's say you're an engineering leader. The way I like to think about things is it's cost benefit. It's a pure cost benefit analysis. How long does it take to build the functionality that we're talking about or build the product or build the MCP integration? And that's a very timely one. We're working on MCP right now ourselves, so very timely. How long does it take? How much long-term cost does it add to the product? It's not just about, you know, can I code this thing up? But what are the implications down the road? So you look at things like... Cost to serve, you know, cost to service, cost for documentation, for explanation, maintenance. Is this something that's going to be a one and done? Or is this something that's really opening up a multi-month, multi, maybe even multi-year project? So that's the cost side, right? It's the short-term cost, the long-term cost. And then the benefit. Does this functionality keep you competitive? Does it actually let you raise your price on what you're selling? Is it table stakes where if you don't have it in three months, you're going to be passed up because everyone else built an MCP connector and you didn't, so all of a sudden now no one will even look at you? Is it something that a particular set of large customers has been asking for? Is it something that enables you to unlock a much more powerful underlying capability, right? Maybe by having MCP, all of a sudden you can integrate with 15 other vendors that you would have had to build each one of those manually. But with the MCP connector, they've exposed a common protocol to get data in and out. So those are the benefits side. And sometimes it's quantifiable, purely. Sometimes your product marketing person will come to you and say, hey, we surveyed 15 customers. They all said they'd pay $500 a month more for this. That's rare. That usually doesn't happen. I mean, large scale it starts to happen, but you might get expressions of interest that, hey, we've got 20 people asking about MCP in the last few weeks. Like, okay. Sometimes you get sales feedback saying, hey, we're looking at talking to... MCPs appeared on the radar. Sometimes you get a deal that says, hey, we'll sign this really large deal if you build this for us. And then you have to weigh those. And weighing those is somewhat of an art, also somewhat of a science. You can build some spreadsheets and projections around it, assuming your data is good and you have a confidence that the feedback is good. But At the end of the day, there is still that gut feeling to it. So gut feeling supported by data. And this isn't necessarily true in the consumer world. In the consumer world, it's a different, in the enterprise space or the B2B space, what I've described as a general framework works pretty well.

Hitesh Chudasama 37:20

Just for our audience, just to explain what MCP, MCP is a model context protocol. It's a communication protocol that allows applications to provide context to large language models. Steve, I know we

Snow Owl - Repeatable and Intelligent Automation

Hitesh Chudasama 37:34

started talking about Snow Owl. We'd love to understand a little bit more in regards to the work that you've been doing there because I had a chance to take a look and some of the solutions that you and your team have been working on is something that has been a pain point for a lot of different companies across different departments. Can you give us maybe a little bit of a high-level overview in regards to Snow Owl?

Steve Heyman 37:54

Sure. So Snow Owl is an AI-powered workflow automation platform that... departments within companies can leverage to build and automate workflows that traditionally required a person. With the advent of generative AI and LLMs, you are able to take on a lot of different tasks that traditionally could only be done by a person. So examples of these are, let's say you're trying to hire a bunch of people and you've got Thousands of applicants and you've got hundreds of job descriptions. How do you match the right person to the right role? Well, traditionally recruiters Look at a resume they spend a minute on it. Then does it fit with the three positions? They're working on right now. Yes. No move on and then if it's a yes you get to You get to interview the person. If it's a no, as the candidate, you get that dreaded, we'll contact you in the future. But you never really get contacted in the future. With AI, we can automate the process of reviewing candidates against all the open jobs all at once. So you get a better result and it can be done much faster, freeing up people to do the things that they really do well. like talking to other people, interviewing, exploring fit and personality, and all those sorts of things. So Snow Owl is designed to allow teams, whether it's HR, as I just dove into, or other functions, sales, customer service, finance, to build workflows that enable people to use them consistently, repeatedly, reliably, without needing to know prompt engineering or Even worse, without needing each of your employees to know how to write prompts. And so that's our focus. We're trying to build out capabilities to make it easy, make it low-code, no-code, make it so an analyst or a process person, not a developer, not an AI expert, can build out the workflows they need at their company to dramatically improve efficiency, reduce the amount of human time spent on low-value tasks, and provide a much better level of service than you'd get traditionally.

Hitesh Chudasama 40:31

That's awesome. Steve, I know you've been in the tech world and now being a founder at Snow Owl. Across your years of experience, What are maybe two or three nuggets of

Lessons Learned

Hitesh Chudasama 40:44

knowledge that you want to go ahead and pass off to our listeners? Are there certain things that you've learned that you apply on your regular day-to-day decision-making process?

Steve Heyman 40:54

Yeah. So one of the biggest things is from the most entry-level role all the way to the CEO, you have 10 times more things to do every day than you could possibly get done. So one of the most important things is organizing your day, organizing your schedule. Now, when sometimes your boss does that for you and he says, hey, work on this today, a lot of times you have to do it yourself. And so one of the most important things that I've found is really focusing in on what do I have to get done today? What's going to move the needle today? what's going to help the most number of people at my company or get something really important done that day. And so I try to do that every morning when I wake up is just, what do I got to get done today? Another thing that's really important, especially for engineers, is the balance between working on your current project and staying up to date on tech, right? Some people... get really focused on what they're doing at the expense of keeping up with trends. Other people do it the other way where they're always looking at what's next and they're not really focused enough on the day to day. So I really think coming up with a way to keep yourself balanced and really mostly focused on the day to day, the one foot in front of the other, but with enough time to see what's out there, see what's new. keeping up to date on MCP or A2A or some of these really hot new technologies without getting absorbed by them and spending your whole time just looking at new technologies. Unless that's your job. There are some roles at a company where you're like an experimental technology person or the CTO sometimes has one person working for him whose whole job is to go play with new technologies all day long. That's a pretty fun job if you can get it. But for the rest of us, It's really kind of keeping that balance. And then the last one that I'd mention is don't be afraid to ask for help, either from your manager, your coworkers, or your maybe a trusted peer, because you definitely will run into scenarios where you don't know how to solve a problem, where you're not sure what to do. All too often, people see that as a sign of weakness or they're embarrassed that they can't figure it out unless you know it's very rare that you're going to be at a place where that is somehow a negative and this should sound like really common like common you know almost throwaway advice but I've seen it so many times where people get so stuck on a project, if they had just asked for help, if they had just asked three questions from someone, it would have saved them days. So I always like to mention that when people ask me about sort of either career advice or It's very common sense, but just ask for help when you need it. Everyone will be happier. Your manager will be happier. You'll be happier. The company will be better off.

Hitesh Chudasama 44:18

Nice. These are great advice. So first being making sure the fact that you're managing your time. The next one being balancing between current priorities and upcoming innovation and keeping yourself up to date. And the third one is making sure you're seeking a support, having a support team. Wonderful. Steve, I really want to thank you for

Wrap Up

Hitesh Chudasama 44:40

taking the time to talk with me and Han, as well as sharing your experience with our audience. Thanks again, Steve.

Steve Heyman 44:47

Well, thank you. Thanks, Han and Hitesh. It was great to be on with you guys.

Han Yuan 44:52

I learned so much from you, Steve, today. I'm so grateful that you were able to join. I mean, your last point is so amazing. I mean, if we zoom out and we think about some of the most successful people that we know, They also happen to have the most help. And I think an argument could be made that if you want to help, you got to ask for it. And the people who ask for help are going to get the most help in life. And it's very difficult to walk through life without any help. And it's so profound listening to you speak because you are an elite engineer. You have, you know, two decades plus of experience. The longevity is incredible. And so the advice that you gave around Thank you so much. I do think for better or worse, there are a lot of engineers who will lose their jobs. I think they, I think they're the level of efficiency and automation that's happening in our field is so high that it will be very difficult to get some of these entry level positions. And so now that balance is so prescient right now at this point in time. So just, you know, really thank you for that advice. That was really, really great. I learned a lot. Thank you for the time. Well, thank you both very much. See you both.