Most teams don’t realize they’re missing critical data until something goes wrong.

In this episode, Austin Spiegel, co-founder and CTO of Sift and former SpaceX engineer, dives into why telemetry, simple in concept, a value and a timestamp, can become a massive problem in hardware. Miss even a fraction of a second, and you lose the story. Software engineers have plenty of tools to solve this. Hardware engineers haven’t, until now.

We also talk leadership, what it’s like stepping into management early, why teams can actually be too flat, and how your role shifts from doing the work to connecting context. On hiring, Austin explains why pedigree doesn’t equal talent, and how Sift focuses on practical, real-world ability.

And throughout, one theme emerges: speed. Not just moving fast, but learning and iterating faster than anyone else.

If you’re building complex systems or leading technical teams, this one hits on a lot of things that don’t usually get said out loud.

Links & Resources

Austin Spiegel LinkedIn: https://www.linkedin.com/in/austin-spiegel/

Sift Website: https://www.siftstack.com/

🤖 Automated Transcription

Austin Spiegel [00:00:00]:
When you have a very flat organization, you have very, you have fewer people that are looked to maybe to make decisions or are relied on to make decisions.

Matt Gjertsen [00:00:11]:
Yeah.

Austin Spiegel [00:00:12]:
And there's not a very clear, you know, there's not as as much clear accountability or clear delegation of tasks. And then you're kind of waiting on those people to, to make those decisions. Right. So I think that's kind of what that, what that comes from is like. Then there becomes bottlenecks in decision making because there's not enough people who, you know, have clearly been identified as kind of the people that we need to go to.

Matt Gjertsen [00:00:51]:
Almost every headline you have ever read about layers in an organization is about the need to remove them. If you have too many layers, it slows down decisions and it means a company can't move forward. And though I, I generally agree with this, there can be too many leaders and too many layers, I also think you can have too few. Right. Well, according to our guest today, you can have too few leaders. And he says that because he has experienced it himself. Austin Spiegel started his career as a software engineer at SpaceX before moving on to Riot Games and then in 2022, co founding Sift, a company trying to provide better tools for gathering and analyzing hardware telemetry. This was a fantastic discussion.

Matt Gjertsen [00:01:38]:
We touch on some of his early lessons as a new engineering leader when he was at SpaceX. Why a company can actually be too flat and without enough leaders it can slow down decisions and the importance of culture to inspire people and how to interview for talent in a way that doesn't rely on pedigree. It was absolutely fantastic talking with Austin. Before we get into that discussion, I do want to remind you that if you are listening to the show and realize that the leaders in your organization need more support. Bilt, my company and the reason this show exists, is here to help. At bilt, we are on a mission to train the next generation of hard tech leaders to build teams capable of solving the world's hardest problems. Just send an email to helloiltleaders.com and we will see if we can help with that shameless plug out of the way. Let's get into the discussion with Austin Spiegel.

Matt Gjertsen [00:02:31]:
So Austin, here's where I would love to start. What is telemetry and why is it so bad?

Austin Spiegel [00:02:40]:
Yeah, okay, great question. Yeah. So telemetry is typically sensor data that is coming from physical sensor sensors or the flight computer on a vehicle. So think a rocket or a spacecraft or a Dragon capsule, which is a spacecraft. And it could also be, you know, software metrics as well. Telemetry is actually a commonly used term across many industries. So in the world of software development we, we capture telemetry on our software, but specifically with vehicles you're typically referring to, or hardware, you're typically referring to sensor data. And the way that we look at it is it's a value and a timestamp.

Austin Spiegel [00:03:25]:
So it could be the pressure at a specific time or it could be, you know, the CPU measurement at a specific time. Why is it so bad? Good question. You know, this problem has largely been solved for software, right? So maybe you or your listeners have heard about companies like Datadog or Honeycomb, you've heard about tools like InfluxDB and Prometheus. These are all databases or full stack observability platforms for capturing telemetry, analyzing and visualizing it for software use cases. So they really serve the software engineers. And I think, you know, one of the reasons those tools have been so deeply developed is because software engineers love to solve problems for themselves. They know the problem, they understand it.

Matt Gjertsen [00:04:10]:
Sure, that makes sense, right?

Austin Spiegel [00:04:12]:
Whereas hardware especially, you know, post 90s when there was a great consolidation in the defense industry, hardware has kind of been underserved by software and it's not really well understood until, I'd say the last five to 10 years. So that's why, you know, there really hasn't been a modern hardware observability platform because no one really knew or not many people knew that it was a really big problem. And it's really only become apparent with I think, you know, the massive explosion of, of kind of startups that, that have started to build hardware and they need a lot of these tools that companies that had a lot of resources like SpaceX or even, you know, Lockheed Martins of the world could build themselves. So I think that's, you know, primarily why it's really not, not in a good spot right now.

Matt Gjertsen [00:04:57]:
It's really interesting because we're having this discussion the week after the super bowl and there was actually a brief moment in the super bowl that really reminds me of our conversation here because they were talking about how all NFL footballs now have a little position sensor in them. And I think it takes position data like six times a second or something like that because it needs to be really, really small and not get in the way of anything. And they were asking the question of why, why don't they use that? Why do they still have the little guys run out there with the flags and figure out where it is? And they said well, because with six times, only six times a second, the ball can move like 10ft in between those pings and if you miss one, then it's 20ft. And it's just, it's like a super simplistic example of where telemetry can go wrong. Because when you, you know, when you drop things, when you don't have that data, like, I mean, the things that are happening at the pressures and the temperatures and the speeds in a rocket, you know, I'm sure tenths of a second, hundredths of a second can. You can miss whole things. I remember watching the investigation of the AMOS. Was it AMOS 6, the, the, the Falcon 9? Yeah, that.

Austin Spiegel [00:06:05]:
Well, there was a CRS 7 and then AMOS 6 was what, it blew up on the pad.

Matt Gjertsen [00:06:09]:
Was on the pad, yeah, yeah. And on the pad, I think that whole anomaly happened in something like twelve hundredths of a second or so. Like, or it was just like such a small. And so that's, that's really why how valuable this data is. So what, how is SIFT going to change that? What are you trying to do? How are you going about tackling this problem?

Austin Spiegel [00:06:29]:
Yeah, yeah. I'm actually so glad you brought up that example as well because it reminded me, you know, there's also a distinct kind of difference between the two. Collecting telemetry for software engineering use cases and collecting telemetry for hardware engineering use cases. And that's why we decided to build sift. Right. We thought, actually when we were founding Sift, I thought companies would be using Datadog. And it turns out that datadog doesn't solve the solution. And one of the reasons it doesn't solve the solution is because it's too expensive to, and it can't store really high fidelity, high resolution, high frequency telemetry like you're describing.

Austin Spiegel [00:07:02]:
Right. And typically in the software world, actually when you're sampling telemetry from software, you're typically looking at an aggregate. So you'd say, well, actually I only want to know, you know, what the P99 request latency is. I don't necessarily need to go look at the request latency for every request for thousands of requests I receive per second. But in the world of software like, or hardware like you're describing, right. When another, another good example is when Dragon, Dragon 1, I think it was demo one, blew up on the pad. You know, all of that happens so quickly and all of those sensors are sampling, you know, a thousand hertz, ten thousand hertz. So you need to be able to dive in and understand what happened in these nanoseconds.

Austin Spiegel [00:07:42]:
Right. So how are we solving that at Sift? Well, our experience with SpaceX was that this was a big data problem. Every single one Starlink creates. Yeah, I'm sure much more now. But, you know, back in 2020, it was like tens of terabytes of telemetry per day and you needed a solution where you could store all that telemetry. We also knew that most of that telemetry is never looked at. And then if it is looked at, it's typically looked at, you know, hours after the event, and then it may never be looked at again. So when we broke down that problem and we knew we also wanted to build a cloud solution because we needed really large volumes, we needed to be able to store really large volumes of data.

Austin Spiegel [00:08:18]:
We realized that what we needed was essentially like a data lake for storing large volumes of data for a long period of time. And then we needed to cache on top of that for real time data. And then so that helps us solve the kind of data problem. And then really the other part of it is kind of the application layer that's purpose built for hardware engineering use cases. So how does a hardware engineer want to visualize telemetry? How does a hardware engineer want to analyze telemetry? And then we built this data review platform that was inspired by a lot of the data review tools that my co founder Karthik, who worked on dragonflight software used. So this is a workflow that is really common. Actually, if you talk to other hardware engineers, they're probably familiar with data review, but this is not a workflow that's common in the software engineering world. So we've built this application that enables customers to do that.

Matt Gjertsen [00:09:07]:
Got it. Awesome. Awesome. Fantastic. Yeah, I do. It is interesting how kind of, as you said before, there seems to be this big lagging gap in hardware focused software like to enable the testing, to enable the operations. And so much of that inside of SpaceX that led them to build so much of it themselves. And there's just been this whole spiel of all these people who have then left and gone on to try to build companies to build that software themselves that they can then sell to everybody else who's kind of trying to follow in the wake of SpaceX, which is, which is really, which is really pretty awesome.

Austin Spiegel [00:09:43]:
Yeah, I always say that I think the real secret sauce, I mean, there's a lot of incredible aspects of SpaceX, but some of the secret sauce is that, you know, there's several hundred software engineers that are building the entire software stack to design, manufacture, launch, you know, reusable rockets and thousands of low earth orbit satellites. And that's what enabled SpaceX to get ahead. Right. Like no one had reused a rocket before. So you weren't going to go buy some software that helped you reuse a rocket. You needed to build the software that enabled reusing the rocket.

Matt Gjertsen [00:10:18]:
Yeah, speaking. You know, even though I'm more like the HR side, after I left SpaceX, I went to a company where I got to work directly with software engineers to build our own talent development tool to our like review system. We built it and just having access to top quality software engineers to build, I mean, in three months we built something that we probably could have paid $50,000 a year or $100,000 a year that would have just been orders of magnitude worse to get kind of like a SaaS product. And so it was just so incredible. I want to shift us because the focus of our conversation today is meant to be about leadership and kind of the things that you learned about leadership. There's a number of specific things I want to dive into. You had a recent you recently reposted sound like an interview with Lava Lab that were. There were a couple of key points that I want to go into, but I would love to start kind of with your initial experiences becoming a people leader.

Matt Gjertsen [00:11:16]:
I think that was at SpaceX. What was that first jump? I feel like that's one of the hardest leaps to make, going from engineer individual technical contributor to people manager for the first time. What was that like? What was that experience like for you?

Austin Spiegel [00:11:31]:
Yeah, great question. So I went into people management when I was quite early in my career. So at that point I think I'd only been at SpaceX for two and a half to three years and then I was an intern prior to that. So it definitely, you know, in hindsight sometimes I wonder if it was too early. But at that time SpaceX, we were in a very flat organization.

Matt Gjertsen [00:11:55]:
Yeah.

Austin Spiegel [00:11:56]:
And it was very clear that we needed more leaders and managers in order to, you know, move more quickly because the decisions were, you know, being, I think, centralized to too many people or to too few people. So I decided that, you know, I was with. Threw my head at the ring. I felt like I was capable of it. There were, there were things that I saw that I wanted to improve and I stepped into the role to do that. And I think one of the nice things about doing it at SpaceX was that you were expected to still be almost a full time individual contributor on top of being a lead engineer. So I got to continue to grow my technical skill set while also learning how to manage a team and lead a team.

Matt Gjertsen [00:12:48]:
I gotta go back a second because you said something that I think is rarely said in that you thought the team originally was a little too flat, that there was too little leadership and that was leading to slower decisions. Usually you hear the reverse where it's just like, oh, we got all these layers and we got to remove them and everything. What makes you say that? That it was like that? How do you think back on that and be like, oh, the cause of this slowness or the cause of these problems is the fact that they're. That it was too flat?

Austin Spiegel [00:13:20]:
Yeah, it's a good question. I mean, I think perhaps the reason I say that is because it's, it's a problem that I'm experiencing right now as our team has grown very quickly.

Matt Gjertsen [00:13:28]:
Yeah.

Austin Spiegel [00:13:28]:
And I think that when you have a very flat organization, you have very, you have fewer people that are looked to maybe to make decisions or are relied on to make decisions.

Matt Gjertsen [00:13:41]:
Yeah.

Austin Spiegel [00:13:42]:
You know, there's not as, as much clear accountability or clear delegation of tasks and then you're kind of waiting on those people to, to make those decisions. Right. So I think that's kind of what that, what that comes from is like then there becomes bottlenecks in decision making.

Matt Gjertsen [00:13:55]:
Yeah.

Austin Spiegel [00:13:56]:
Because there's not enough people who, you know, have clearly been identified as kind of the people that we need to go to. But I want to be clear too. I think leadership comes in many forms and there's people leadership and there's technical leadership. And a lot of those decisions can be, can be driven through technical leaders. That's also something that was going, was changing at SpaceX at the time. So when I joined SpaceX, we didn't have levels. Everyone was a software engineer. And then I was there during the transition to leveling and I think that really changed the dynamics of the organization.

Matt Gjertsen [00:14:25]:
Yeah, I can see that. And then it can really. I think that's a big move that's really positive in a lot of organizations when there's kind of those like dual track structures where you don't have to become a people manager in order to continue moving forward in your career. And yeah, it's a great way to push off some of those more technical decisions to the non people managers. It can be a great way to do that. That makes a lot of sense. Any particular early lessons that you remember or early challenges that you remember when you became a people leader for the first time that you had to kind of like a mindset change or a new thing that you had to learn, what was the sticking point for you?

Austin Spiegel [00:14:59]:
Yeah, yeah, absolutely. I mean, I think the big, the biggest challenge, honestly, was that we were a matrix organization. So I, all of my direct reports were in different teams. So we did this squad model basically where the teams were kind of reorged every 60 days. And this is a very SpaceX process to basically keep people focused on the highest priority things and ensure the right people are working on those tasks. It was really challenging as a manager because if you have five to eight direct reports now you have to also keep tab on, you know, five to eight different projects and how your direct report is performing within that project.

Matt Gjertsen [00:15:43]:
Yeah.

Austin Spiegel [00:15:43]:
So I think that was very challenging for me, but I think it also really makes you. It improved the pace of my learning as a manager because I had to develop systems for, you know, gathering feedback, providing people with feedback, coaching when I wasn't directly involved.

Matt Gjertsen [00:16:01]:
Right.

Austin Spiegel [00:16:01]:
Because it's actually, if you're already, you know, maybe you're the de facto lead of a team and then you become the team's manager, that's not a huge transition. There's also the benefit of like, you've probably worked on the software that that team is building, so you can provide guidance on that as well. Right into now this kind of model where you may have never worked on the thing that your direct report is currently working on and. But how do you still make yourself useful to them? And I think a lot of management at that level is just connecting the dots. Right. So bringing the necessary context that you have to your direct reports and then also gathering context about their work so that you can ensure that they're doing well and that they're getting everything that they need from their teammates.

Matt Gjertsen [00:16:48]:
I love how you said that both the context and then specifically the gathering the context, because I think that is one thing that a lot of new leaders struggle with is they think because when you're a pure technical contributor, it's like that's what you're contributing. Like your skill in this engineering or in the. For this thing is what your contribution is. And so then you become a manager and as you say, like, if I don't have that expertise, how do I bring value? And it is so often kind of your slightly higher purview of being able to like talk to different people or get different information feeds that you can then distill down and bring to them is just. Can. Can be. It's. It's your ability to gather information and resour, provide it to them, which is so, so critical.

Austin Spiegel [00:17:34]:
Yeah, that's exactly it. So yeah.

Matt Gjertsen [00:17:37]:
Awesome. When you left SpaceX, you went to Riot Games and what was anything in particular stand out to you in changing organizations? Was it a very similar organization? Was it a very similar culture? Or was like just from like a thinking about as a manager, did you, did you have to like take a shift and like oh, being a manager now means this in this new organization, was, was there anything like that?

Austin Spiegel [00:18:05]:
It was wildly different.

Matt Gjertsen [00:18:06]:
Okay.

Austin Spiegel [00:18:07]:
There's actually a lot. Yeah. Which you know, partially was something that I was looking for I think because I had started my career at SpaceX, I worked there for five and a half years, including my internship. And I felt that in order to continue growing as a leader, which is what I wanted to do, I wanted to stay in leadership, I wanted to stay in management. I needed to see a different management and leadership culture. And I think something that attracted me to Riot was they. Well one was that it was a lot of software engineers and software at SpaceX. Even though it's still a really critical part of the business, it's kind of placed second to the hardware side of the company.

Austin Spiegel [00:18:48]:
Um, and I liked that Riot was I think very explicit about what its company values were and I felt that these values were really incorporated into all aspects of working at Riot. So everything from the interview process to performance reviews to the all hands, this, this is where the values were incorporated. And then that meant that people actually exemplified the values. Whereas I think SpaceX had. Has values, they're just implicit. Right.

Matt Gjertsen [00:19:19]:
Yeah.

Austin Spiegel [00:19:21]:
And, and SpaceX is such a unique company because it has this crazy goal of going to Mars and people sign up because they're so motivated by that. And frankly there's just not that many companies. Yeah. That where that is one realistic goal that can actually be achieved.

Matt Gjertsen [00:19:36]:
Yeah.

Austin Spiegel [00:19:36]:
And they have that goal that is so inspiring. Right.

Matt Gjertsen [00:19:39]:
Yeah.

Austin Spiegel [00:19:39]:
So you need to find other ways then to motivate people and to you know, deliver a great product. And I think that was something that I wanted to go see see at Riot. So, so that's kind of why I joined Riot. I think the things that were really different from a management perspective is it was not as a very non technical role. So okay. My team, you know at SpaceX I was a lead engineer. We didn't have product managers, we didn't have project managers. Engineers were full stack everything from product to software to infrastructure.

Austin Spiegel [00:20:11]:
At Riot my team was myself, I was the engineering manager. I had a tech lead, I had a delivery lead and I had a product manager. So that's basically four team, four people on like in the kind of like leadership of a 10 to 12 person engineering team. And given some of those people were also have responsibilities in other teams, so they weren't full time dedicated. But you know, that was a huge adjustment. In some ways great because now I had more support in other ways. As someone who, I think what I learned at SpaceX was I enjoyed having control and doing many things and wearing many hats. It was more challenging.

Austin Spiegel [00:20:48]:
And then I'd say my biggest growth was that I got to become a hiring manager. And that was a really great lesson. So at SpaceX, at least when I was there, lead engineers were not hiring managers. We did interviews, but we, we weren't involved in the decision process.

Matt Gjertsen [00:21:01]:
Sure.

Austin Spiegel [00:21:02]:
And I think becoming a hiring manager, realizing how crucial hiring is, would you have open headcount. I think that's probably the most important highest priority for a manager is to fill your head count. That was a huge lesson. I think that that has been incredibly informative in building a startup where, you know, we've raised capital, now we have to deploy that capital and our biggest expense is our people. So we have to not only hire quickly, but we need to hire great people and we need to design an interview process and figure out how to filter people out and so on and so forth. So, you know, this is, this was like a really big lesson and I'm really glad that I had that opportunity at Riot.

Matt Gjertsen [00:21:38]:
Well, that's a perfect way to segue into some of the quotes from the, from Lava Lab. One of the things that you said was pedigree does not equal talent. The best builders are scrappy and come from unexpected places. So you talk about at Sift, your building this hiring program. How do you do that? Because I do think I have a lot of qualms with a lot of companies because I do feel like so many organizations, because they don't really know what they need, they kind of outsource the deciding process to other people, whether it be other companies or universities. And they say, well, they worked at this company, so they must be good, or they worked at, or they went to school here, so they must be good. And really what you're doing there is you're not figuring out how to decide what is good, you know, and so it sounds like you're going straight at that problem. What are some of the things that you've seen work? How do you think about identifying that best talent if it's coming from unexpected places.

Austin Spiegel [00:22:38]:
Oh, yeah, this is a great question. And I think, you know, my mind, I will say, evolves on this constantly because, you know, there are people, there will always be people that surprise you and buck the trend. I will say our what we really, what we've tried to do since day one here at Sift is make our interviews very practical. So it's not about, you know, can you solve this algorithm that you may never use again? And it's not about did you spend 80 hours practicing on Leetcode so that, you know, you could solve some, some dynamic programing question. It's really about what are the things that we're going to do day to day at Sift and can you do those things?

Matt Gjertsen [00:23:24]:
Yeah.

Austin Spiegel [00:23:24]:
And how do you work with our team in doing those things? How do you collaborate? Right. So the interview is as much about showing your work. Right. Which is what we all did in school, as it is about getting to the right answer at the end. It's actually about how did you approach a problem. So our interview process is of course we have a technical phone screen and then on the, on site we do a presentation. So actually this is something that we did at SpaceX and I think, you know, engineers will think, well, why? Why are we doing a presentation? But a presentation is a really great opportunity for the candidate to put their best foot forward and to present on something that they're really knowledgeable about.

Matt Gjertsen [00:24:01]:
Yeah.

Austin Spiegel [00:24:02]:
So, you know, the best candidates will just take advantage of that and they'll talk deeply about a technical subject or a project that they've solved before. They'll be able to answer all of our questions and go deep on it. So there's really no way to, you know, oh, you didn't know the answer, so on and so forth. Then of course we do like a system design interview, which is really based on what we're doing here at Sift. And then we do another coding problem which is really just about kind of like fundamentals. It's actually not about algorithms at all, but more about kind of like fundamental software engineering concepts. And then we do our values interview. And then the values interview, you know, ties into kind of all of all of the company values.

Austin Spiegel [00:24:41]:
And that's a behavioral interview based on, on the star bubble. But I guess it's all to say that really my idea with finding kind of talent that is, I guess, not obvious on obviously great on paper, which not, not, not how I want to put it, it's a poor way of putting it, but is really about like just interviewing people as if they're already working at sift.

Matt Gjertsen [00:25:05]:
Interesting, interesting. I like that. It's, it's interesting that you have that mindset. One of the things that I always tell people, I've talked to a number of people about going into interviews and helping prepare for interviews because I was, you know, since I was in the military for the whole beginning part of my career, I'd never done an interview. And then I go out and I'm like, what am I doing? What is this whole thing? And I, and then I got to be a hiring manager. And so one of the pieces of advice that I always give is that, look, every hiring manager hates hiring. Like, like they, they're busy, they have things to do, they don't want to spend all day in interviews, they want to hire you. So just make it easy for them to hire you.

Matt Gjertsen [00:25:44]:
And you know, it's kind of almost sounds like you're kind of coming at that perspective from the interviewer of just like, no, we want to hire you, so just like help us hire you kind of.

Austin Spiegel [00:25:53]:
Yeah.

Matt Gjertsen [00:25:54]:
Which is, which is really interesting. I want to touch base on that you met because you brush it, you went over it. Some people might not be aware. When you were talking about kind of the values interview and you mentioned the star model. Could you touch on that just a little bit more of what that is?

Austin Spiegel [00:26:09]:
Yeah, sure. So that. Yeah, yeah. So this is something that I had learned at Riot, but it basically originated from Amazon and it is situation, task, action, result. So the idea is that you ask a question. So in a behavioral interview, you're asking questions that should be solely based on previous experience. Right. So there are no hypothetical questions.

Austin Spiegel [00:26:28]:
Because it's very easy to answer a hypothetical question about ideally what you would do. But really what you're looking for is like, what has the candidate done? Right. Yeah. And then the star model is a, is just a way of kind of how a candidate should break down their answer. And typically with a star model, you can have, you know, a header question so you can say like, you know, tell me about a time where you had an interpersonal conflict with a peer. And then the situation would be this time that I was working with my peer on my project, and then the task, so on and so forth.

Matt Gjertsen [00:27:05]:
Right.

Austin Spiegel [00:27:05]:
So it's basically just a way of breaking down and it's good both for structuring follow up questions for interviewers. And I think it's really great for candidates as well to think about, you know, as they think about preparing for a behavioral interview to kind of think about their answers in this model because it's just much easier to kind of answer the question that way once you, once you learn it.

Matt Gjertsen [00:27:23]:
Yeah, and it's nice because I think generally day to day, not many people are confronted with the kinds of questions that they would get in an interview. And so some people are good at interviews and some people aren't. And the more structure you can provide them for answering these kinds of questions, the more you are certain that you're truly testing them on how they're answering versus how they're able to interview, which is, yeah, not a useful skill.

Austin Spiegel [00:27:50]:
That's a, that's actually a really great point. Yeah, I really like that way because you're, you're basically eating the playing field a little bit and saying like, just answer this way and then we're totally evaluating you based on what you've done instead of like your ability to sell yourself or to interview.

Matt Gjertsen [00:28:03]:
Yeah, yeah, exactly. Another thing that I wanted to bring up from the Lava Lab interview that I thought was really interesting was you talk, talking about speed is the only unfair advantage in this idea of shipping and iterating quickly. I get the opportunity in my role. I work with a lot of different companies, many of which are startups, many of which are, are more legacy aerospace companies. And I think a lot about, you know, the ones that are really thriving in the world today and the ones that are struggling in the world today. And it all comes back to speed. It's just like comfortableness with rapid changes and kind of this idea that change isn't an event, it's the environment. Like, it's just things are moving quickly and we gotta be okay with that.

Matt Gjertsen [00:28:45]:
How specifically you mentioned the quote was shipping and iterating quickly is a highly transferable skill. I rarely hear like speed as a skill, like talked about as a skill. What do you mean by that as being a skill?

Austin Spiegel [00:29:02]:
Yeah, great question. I think it's really about pace of learning. Right. And I think that's what, what my big takeaway from, from SpaceX was that if like you learn quickly and then you can reincorporate those learnings and adapt and ship new things. So I'm thinking very much in, in, in the context of shipping software. But yeah, you know SpaceX, right. You look at how, how, how were they able to land a rocket? Well, there was a lot of failed rocket landings before that and each rocket was slightly different because they kept testing new hardware designs and so on and so forth. And I think the same thing applies to build building software.

Austin Spiegel [00:29:40]:
And it's actually easier when you're building software because you're changing bits, not atoms. Right. So you could ship something new, get feedback from customers, talk to customers, use the tool yourself, take those learnings, incorporate them, and then go back, go back for more. I just returned from a conference in San Francisco this, this past week, and there was a lot of talk of, you know, agentic coding platforms and how a lot of software engineers are now leveraging multiple agents to work on multiple tasks at once. And I think that is also why speed like that, you know, that is almost. I don't, I'm not entirely sure if my mind is totally made up about it yet, but is it a threat to software engineering? I don't necessarily think so. I think the, the best software engineers are going to embrace that. Yeah, but you know, that pace like that enables such a quicker pace of innovation.

Austin Spiegel [00:30:32]:
It also means that the software that you've already built could probably be rebuilt in a matter of time by somebody else or your customer.

Matt Gjertsen [00:30:40]:
Yeah.

Austin Spiegel [00:30:41]:
So you also, in that case, like, speed is really the only moat. Right. So, and speed also, I should say, manifests itself in insights.

Matt Gjertsen [00:30:50]:
Right.

Austin Spiegel [00:30:50]:
So how quickly that goes back to learning, but like, how quickly are you identifying a new problem to solve? And it's not only about, like, how quickly can you push a new feature?

Matt Gjertsen [00:30:58]:
So now that you're the CTO at sift, how do you think about pushing your team towards speed? How do you incentivize speed? How do you keep them moving fast enough or faster?

Austin Spiegel [00:31:10]:
Yeah, this, this is a tough one. And this is one that I've, I've thought about a lot. And I think that there's even some changes now that I, I've wanted to make to, to incentivize speed more. But I think one thing is really connecting engineers to the customer. You know, I think a lot about motivation and then, like, what motivates engineers. I also am leading our sales team right now, and our salespeople are very thoughtful, very intelligent, but the incentives are very clear. Right. They close a deal.

Austin Spiegel [00:31:42]:
Yes. They get commission for that deal.

Matt Gjertsen [00:31:44]:
That's the nice thing about sales software.

Austin Spiegel [00:31:46]:
Right? Nice thing about sales. Exactly. And you can find levers to pull and, you know, to incentivize people to do different things. It essentially, software is a lot different because one, that's not traditionally how software engineers are compensated. But also I think people that tend to be software engineers are not motivated in that way. They're not thinking as much about. Of course, everyone wants to get paid and everyone should get compensated well. But also that they are more maybe interested in solving the problem.

Austin Spiegel [00:32:12]:
Right, yes. And digging into the technical details of how to solve that problem. So I think if I think back to when I write code and when I ship software, what was very gratifying for me was seeing how it impacted the customer and getting feedback from the customer. So then the way that I've thought about motivating the team is how do I bring the team closer to the customer so that when they make a change, they see the impact of their work. And it's pretty cool when we make a change to see the impact of our work because we're directly helping people launch satellites and develop autonomous vehicles and launch rockets and so on and so forth. Right. So, like, that's actually super gratifying. That's why a lot of people chosen to come work at Sift is because they have that opportunity to make a difference in the physical world.

Austin Spiegel [00:32:54]:
Yeah. So it's really then about, you know, I think, bringing the engineers closer to the customer to kind of instill speed.

Matt Gjertsen [00:33:01]:
I love that very much. A kind of a Travis Kalanick answer of a customer obsession. He's, he's all about that, you know, just like making sure people understand, understand the, the pains of the customer and really, really going after solving those problems. Awesome. Well, what's next at Sift? Like, what is there a next big milestone, Next big. What are you. What are you working towards right now? What's the next big announcement going to be? Not that you can tell me like when the next announcement, but, you know, what are you working towards right now?

Austin Spiegel [00:33:29]:
Yeah, totally. I mean, for us right now, we've been growing our team. So we're at 70 people now. Our engineering team is about 40. I actually just hired a VP of engineering. He just signed with us, so he'll be starting in March.

Matt Gjertsen [00:33:41]:
Congrats.

Austin Spiegel [00:33:41]:
Which I'm really excited about. I love being a leader, but as a founder, I think I've seen that I can provide value in a lot of different roles in this company. And I think we need a VP of engineer who understands the next growth curve. We're going from probably 35 ish engineers to 50 or plus this year. And there's a lot of complexity in managing a really functional organization of that size. So I'm really stoked that we've hired our BP of engineering we're working with. We've got, you know, many kind of enterprise customers that we've been working with. So that's something that's very exciting.

Austin Spiegel [00:34:18]:
And then we're building new products. So we've got, we've got not only our core telemetry product but we've been working on kind of new analysis products to bring, you know, non technical users into the platform. Products for capturing data from different types of tests as well. That's not necessarily telemetry, but more measurement oriented data. So yeah, lots of cooking here at Sift.

Matt Gjertsen [00:34:41]:
So two things. One, it just suddenly the name suddenly hit me. So it's. Is it. Am I correct that it's sifting through the data to like find what you're looking for? Of course, yeah. And why that took me so long. And then secondly. So you're going to be ingesting data from Artemis 2.

Matt Gjertsen [00:34:55]:
Is that what I heard? Like you're going to be processing. That's awesome. That's awesome. Yes.

Austin Spiegel [00:34:59]:
Yeah. So we've been working with them for a while now and they're using us to review telemetry retrieved from the capsule.

Matt Gjertsen [00:35:04]:
That's exciting.

Austin Spiegel [00:35:05]:
Cool.

Matt Gjertsen [00:35:05]:
Okay, well this has been a fantastic discussion, Austin. Thank you so much. Really excited to have you.

Austin Spiegel [00:35:12]:
Awesome. Yeah, thanks so much Matt. This was a pleasure.

Subscribe to listen to your favorite episodes!

Listen on

Spotify

Listen on

YouTube

You may be interested in