Don't just create a roadmap and then throw that roadmap over the fence and expect your engineers to implement it... foster a culture where the engineers see a customer problem and then feel empowered to go and address it.

What’s the secret to building better products? Letting engineers drive the vision. 

This week, host Ben Lloyd Pearson interviews Austin Spiegel, co-founder and CTO of Sift Stack, who previously spent years leading engineering teams at SpaceX. Austin reveals how SpaceX's unique engineering culture, which eliminated the product management layer,  influenced his approach to building Sift Stack, including the implementation of a forward-deployed engineering team.

Learn how this approach leads to faster development cycles, happier customers, and more innovative products. 

Austin also argues that we're entering a new era where the most valuable engineers aren't just skilled coders, but also savvy business thinkers. He believes that as software development becomes easier due to the proliferation of AI engineers who can connect their technical expertise with a deep understanding of customer needs and market trends will have a significant competitive advantage.

Show Notes:

Transcript

Ben Lloyd Pearson: 0:00

Hey everyone, I'm your host Ben Lloyd Pearson, and I'm happy to be joined today by Austin Spiegel, co founder and CTO at Sift Stack. Austin, thank you for joining us today.

Austin Spiegel: 0:12

Ben, thanks so much for having me here. I'm really excited to be on.

Ben Lloyd Pearson: 0:16

So you bring an impressive background. So before Sift Stack, you spent about five years working as an engineer at SpaceX, and I want to start the conversation there because, I think SpaceX is relatively unique in that they famously build almost everything in house, like even systems like HR from what I've heard. And I imagine that this is probably Your role that engineers play in product design. In fact, you wrote an article about this that I want, I'm going to ask you a little bit about later, but first let's just start with SpaceX. So can you tell us a bit about your experience at SpaceX and how it's shaped your entrepreneurial path?

Austin Spiegel: 0:56

Yeah, definitely. And I just want to start out and say too that, I didn't really set out to be an entrepreneur. I've always been a builder. I loved playing with Legos as a kid. I've always liked watching How It's Made, the show about manufacturing. But coming out of college, I didn't really feel like I had a kind of unique perspective on a problem that needed to be solved. I was actually in an entrepreneurship organization in college, and of course, the problems that I was interested in building products for were fairly trivial like a crowdsourced playlist, for example. So SpaceX really opened my eyes to a whole class of problems that I don't think a lot of us get to experience every day. And specifically that was manufacturing. So I think something that's really unique about SpaceX is it takes a kind of first principles approach to solving all these problems. And I think that gets to your point about, SpaceX now building all of its own software, rather than rely on software that's already existing in the world. For example, maybe SAP, which is a robust ERP system. SpaceX thought we're the first company that's going to launch and land rockets. So what would an ERP and manufacturing execution system look like? So that's what it's going to look like for a company that's going to do that. And I think that's really what my big takeaway was from my experience at SpaceX is if you're going to go solve novel problems you probably need novel tools to help you solve those problems.

Ben Lloyd Pearson: 2:19

Yeah, I can relate very heavily on the not having big enough problems to solve, to actually start a company for, I think a lot of engineers relate on the idea of having a lot of side projects and like other things that, that they love to build. And maybe that's why, SpaceX engineering is so highly revered because it does encapsulate that type of mindset.

Austin Spiegel: 2:39

Yeah, absolutely. In order to land a rocket we needed to also build an autonomous drone ship. So that's not a problem that you're encountering pretty much at any other company.

Ben Lloyd Pearson: 2:48

Yeah, exactly. So you emphasize the importance of engineers driving product vision. So not just being like responsive to enter the needs of the product team or the demands of the product team, but actually helping to drive that vision forward. So explain how like your time at SpaceX, like really influenced this belief.

Austin Spiegel: 3:09

Yeah, definitely. I had the privilege of working with a lot of great product managers at SpaceX. But about midway through my time there our organization actually eliminated all product management roles. And either some product managers moved on or some product managers transitioned to engineering. And of course this was a really difficult challenge for the remaining engineers because now they needed to take on product management responsibility. Yeah. And in some cases, some of those engineers left and others, stepped up to do that. So I think while we ultimately probably swung the pendulum too far in the other direction of not having product managers when we did this restructuring, we had product managers kind of writing specs for projects that were probably never going to get built. So I think really what the problem was, it created this abstraction layer between engineering who was solving the problems and the people they were solving the problems for. So we were building features that maybe missed the mark or weren't actually solving the problem that we were trying to solve and they weren't really being used. Growth from there was as I took on more product responsibility, I realized that being much closer to the problem and more importantly, being much closer to the users really helped us build solutions that were addressing those problems and not waste time on things that weren't, moving the needle for our customers. Yeah,

Ben Lloyd Pearson: 4:24

I love the idea of, some engineering people being able to step up into this new like semi product management role. Were there any like commonalities between the people you think? Both we're willing to step up, but also we're successful in doing so.

Austin Spiegel: 4:40

Oh, man. Yeah, that's a really interesting question. I think ultimately there's certainly no, no fault in being an engineer who just wants to go and solve a technical problem and spend more time in production. And like engineering. But what I noticed at SpaceX is the people that were successful kind of in this role were people who saw, really saw, engineering and building software as a means to an end. So they really saw it as a tool to go and solve a business problem and not necessarily as, just Something to build in and of itself. And I think that was the greatest quality. And it's really people that have a lot of customer empathy and get really motivated when their users are struggling or, are not I guess the best example would be, there's so many opportunities to save hours in the process of building a rocket. So the people that kind of look at that process and say, wow, if we go automate this process where we build this feature, we can now go and turn around a rocket in 10 less hours than before. Those were the types of people that really motivated by it and were successful in that organization.

Ben Lloyd Pearson: 5:44

Yeah.. So viewing software as a means to an end, like this is actually a very common I think, trait that I hear in a lot of hype, like teams that we would view as like high performing engineering teams and, I really think that like one of the surest sign that you have a really strong engineering culture is that. All of your engineers are considering like that end user impact, like they're going all the way through, whatever they're building, they're going all the way through to the end to understand how it impacts that user. If you're a, if you're A database engineer at Netflix that's building backend database stuff. Like you're actually thinking about how do these queries impact the actual use cases that our developers are going to be, or consumers will be like consuming this product. So yeah, I really love hearing like more stories, related to that. Yeah. Yeah, absolutely. I think,

Austin Spiegel: 6:35

I was thinking through what specific examples can I draw upon here? And something that I found really interesting, or I recall, and it's funny because my co founder actually worked on this project. There's a manufacturing process where you basically take two different parts. So in this case, it was. Two parts of the trunk that go on the Dragon Space Capsule. And you basically take these two parts and you drill holes in them. And then you separate those parts and they go through separate processes. But you actually have to bring these two parts back together and those holes have to match. So that whole process is called match drilling. And it's a fairly complex process. And we actually wanted to build a feature into our manufacturing execution system So that we could ensure that when these two parts came back together, they came back together in the right formation. And we spent with product managers, we spent a lot of time designing this solution. And almost trying to build software to solve a manufacturing problem. And ultimately we went out, we spent a lot of resources, we built this feature. And then six months later it was not being used by anybody. And I think that's the perfect example of something where, You know maybe six months, a year later, when we're in this world of kind of software engineers getting a deeper understanding of the problem and the product, they would realize, this is actually going to add a lot of unnecessary complexity to our system. And it's probably not going to really solve the underlying problem, which at the end of the day is more of a manufacturing problem than it is a software problem.

Ben Lloyd Pearson: 7:59

Yeah. That's rough having six months of work and not going anywhere. Yeah. I imagine that doesn't feel great. You've gone from SpaceX to go on and found your new company SIFT. I imagine you're probably not building everything yourself anymore, but I am curious, how has that mindset helped you or played a role in your transition to founding your own company? Yeah.

Austin Spiegel: 8:25

Yeah. That's a great question. I think something that people typically forget is that. SpaceX is nearly 25 years old. Elon Musk and SpaceX weren't household names less than a decade ago. So SpaceX actually wasn't building all of its own tools for the entire history of the company. And it wasn't fully vertically integrated for the entire history of its company. In fact, a lot of the software that SpaceX uses now wasn't built until after Falcon 1 successfully launched in 2008 and even later than that, like once Falcon 9 was flying in 2012. So I think sometimes companies will look at SpaceX and try to apply the SpaceX mentality when there may be, seed stage company. And that's probably the wrong lesson to, to take. I think ultimately like the lesson you want to take away is one moving quickly, but also really don't build everything, but build your kind of core competency, right? So what, what is actually going to make what is going to be a competitive advantage for your company? So the way that I look at it is, we're building a time series data platform for hardware sensor observability. So for example, for us, time storing, ingesting, storing, analyzing time series data is a core competency. So of course we're going to go and build a unique solution there. And the real benefit of that is now we have total control over how it's implemented and how we grow it. And we can really tailor it to address the problems that our customers are solving. But, maybe as an example, compared to SpaceX, SpaceX is now at the point where it has built its own HR system. I don't think that's something SIFT would ever do, and certainly we're not going to be doing at this point.

Ben Lloyd Pearson: 9:57

let's transition into a conversation about some of the thought leadership content that you've published that's out there. Not too long ago, you wrote this article title is the secret to better products. Let engineers drive vision. So let's talk about that. What inspired this article?

Austin Spiegel: 10:13

Yeah, definitely. Ultimately what inspired it was, we've managed to hire a really amazing team of engineers who are product oriented. But of course, I think that's a difficult skill set to look for and we wanted to publish this thesis to attract more like minded talent. So that's the primary reason for kind of, publishing the article. I think the other thing too is our customers really value working with people and vendors who understand their problems And, we want to build a culture here of customer empathy and of engineers who understand our customer problems. So that's, why we published the piece. And, ultimately I think like building a product management organization where product managers are expected to make all the product decisions just doesn't scale for an early stage company. Like we, we couldn't, we have a team of 12 engineers right now if we had, if we wanted to have a product management organization that was making all the product decisions, it would have to be like maybe a quarter of that or a half of that, a half of that size, and that just wouldn't be something that's feasible for us.

Ben Lloyd Pearson: 11:16

Yeah. And I imagine that's a massive competitive advantage too, right? If you're able to dedicate a lot more resources into building new value and enhancing existing features. That's massive for a company that's that small, It's like a cultural differentiator. this culture that puts engineers in the position to drive vision. So what is like, how would you describe what that actually looks like in the day to day? Like a developer, like ideally you want all of your developers to raise their hand and say, yes, we do believe that we're following this. So the ones who say that what would you expect them to be doing like in their day to day?

Austin Spiegel: 11:53

Yeah, definitely. I think the kind of the first thing that's really important is to have a lot of customer empathy and really think put the customer at the center of everything we do. So ideally that means having people on staff who, are your customers or would be your customers. We're really fortunate. We have a team of forward deployed engineers who kind of work on our core product and help extend our product for our customers. And all of those people are former flight software engineers that worked on the Dragon Space Capsule. So they have a really deep understanding of how these tools are used by customers, how these tools integrate with the customer application ecosystem. And then they can also really help inform our internal engineering team on how we want to build the product. So that's, that's number one really important. Then second, I think, is like including engineers in strategic decisions. which empowers them to make decisions about the product. So don't just create a roadmap and then throw that roadmap over the fence and expect your engineers to implement it. And of course there's certain situations where you need to do top down decision making, but in those cases that really ensure that the engineering team is brought on the journey and they understand, why they're building what they're building. Because ultimately what culture we want to foster is a culture where the engineers see a customer problem and then feel empowered to. Go and address it. And then finally I think it's like really emphasizing outcome over output. So it doesn't really matter how much time is spent in front of the computer. It doesn't matter even if we deployed a feature. What really matters is whether or not the customer is actually deriving value from the feature. So does it solve their problem? And if, and ultimately in order to figure out if it solved their problem, you need to go and, look at the analytics, talk to the customer and ensure that feature is actually doing what we expected it to do.

Ben Lloyd Pearson: 13:32

Yeah, I think that, including engineers in your strategic decision making, I think that's such a critical component that, A lot of organizations, they either don't do it or they think they're doing it and they don't do it completely. Like we often hear about this like dual mandate that engineering leaders face, like you, you want to be, you want to maintain like the highest levels of operational excellence that you can, but you always have this business like demanding things from your organization. So how do you have conversations where you. Can illustrate that like the business wants certain things, but the engineering organization has to do other things to make sure that we can be sustainable and we can actually support scalability and we don't get overwhelmed with tech debt and quality issues. Yeah. So I think, of those things that you mentioned, I think that's, in my mind, tends to be the one that really is the most important, but those are all great insights.

Austin Spiegel: 14:25

Yeah, definitely. I think that's it's pretty challenging. And something that I always say is we really want to align individual's goals with overall customer company goals. with the type of engineer that's product oriented, when you expose them to like the customer directly and the customer problems they tend to get motivated to solve those problems anyway. Yeah. And then it ultimately just comes down to, working in the things that that, maybe don't seem like they impact the customer, right? Like technical debt scalability. But ultimately, I think all these things actually do impact the customer. In our case, we have to scale our platform to ingest, petabytes of data. Technical debt impacts how quickly you can ship code. So I think all of these things can be spun in a way that, they're customer impacting. again. and can be prioritized as such. Yeah,

Ben Lloyd Pearson: 15:10

is if all you do is focus on new value feature enhancements and you're never focusing on like maintenance and keeping the lights on eventually your entire product roadmap just becomes like unexpected work, essentially. Having a framework to, I think having, engineers directly involved in that as a great way to just tighten that like individual to executive connection or strategic connection as you're explaining. So I'm gonna, I'm gonna take a little bit of a segue here and talk about, some of the current trends in software development, including LLMs and automation and AI. So how do you think that these types of things are going to impact the role of engineers moving forward?

Austin Spiegel: 15:49

definitely. I think for me, I was, prior to founding SIFT, I was looking for a new role, and I was interviewing as an engineering manager at a company that had used a low code tool to build some internal software. And, this software they were building had a lot of complicated business logic, but was technically quite simple. And Thank you very much. I came to this realization that, there's a lot of software that's very in that, never sees especially a lot of software that never is used by anybody outside of a company. And a lot of that software is very technically simple, right? So it's probably just a form sitting on top of a database. And I realized that because tools to build software are getting easier and easier to use. So low code tools, LLMs are obviously making it really simple to, to build apps. In fact, we just interviewed a product manager who was building their own mobile app using Cursor. It made me realize that the people who will write the best software will probably have a better understanding of the business domain. Of course, there's always going to be technically complex software that needs to be written by great engineers. After all, somebody has to go and build the LLMs or build these low code tools. But I think those roles will either, maintain their current availability or even become more scarce. So really having this kind of product oriented mindset is how you can, continue to thrive as an engineer.

Ben Lloyd Pearson: 17:16

Yeah. If you have generative AI tooling, like both making it easier to adopt new technologies because you can rapidly onboard new skills and knowledge a lot faster, but then also, we're seeing it remove a lot of the toil and nitty gritty details of having to produce software Yeah, it really does make sense that like it frees up the human to focus more on the problems rather than the actual technical capabilities that have to be implemented. Given that this is happening or this, you think this trend is happening how can engineers like bridge that gap and become more business savvy? If they want to start being more focused on end users, like how can they start that journey?

Austin Spiegel: 17:58

Yeah. Yeah. This is a really great question. I think, to start it really helps to work with great product managers. So for example, when I was at SpaceX, I worked with a group of folks who had previously worked in the manufacturing sector. So they had basically built software for automotive manufacturing aerospace manufacturing, and through them, I was able to learn a lot of the intricacies of the processes in that business. But also something else that I got at SpaceX was really firsthand experience. In my case, that was building software, building Walking on the factory floor, watching technicians use our software to build rocket engines, going up to them, asking them questions about it, observing them. And that really helped, I think, build a better sense for how the product should act. Here at SIFT, as I mentioned, we have a forward deployed engineering team that previously used tools like these. So that's another way that our team can get, first hand knowledge of how the tool should be used. So that's number one, which is trying to get, hands on or first hand experience. But secondary, it's like spending as much time with customers as you can. Now, of course, this is a little dangerous, you can always spend, you need to still go back to your desk and be able to get some work done. But ultimately, like getting in front of customers, whether that's whether that's visiting customers on site having, sitting in on meetings with customers. In our case, it's showing our projects to customers. Before we begin on them and then getting feedback as we're implementing them. And then having direct lines of communication with, communications with customers. Slack is actually a great tool for this. Slack Connect, being connected to all of your customers and being able to reach out to them directly. And then I think the final thing I'll mention here too because I have gone back and forth on this a lot, but, specializing in a business domain helps because there's a, you can just get deeper and deeper. So when I was at SpaceX, I worked on manufacturing problems and then I left briefly to work in the game industry, and that was a great experience, but ultimately I realized that kind of manufacturing, hard tech was where I wanted to build my career, and that's what we're doing here at SIFT, and I think ultimately that's probably where I'll end up spending most of my time.

Ben Lloyd Pearson: 20:03

Yeah, I love the, getting closer to your customers. But yeah, I think it is warranted to call out that it can be dangerous sometimes, right? Like engineers aren't like typically the person that is the most skilled at going in front of a customer and trying to be persuasive or stuff like that. Yeah. I'm someone who also has to go into to customer conversations quite frequently as in like a technical role. But, and there's other alternatives to that as well. You can use like data to be a proxy for your users, or I frequently love to watch. Calls that we have with our customers or with prospects just to see, like when they're being exposed to like our platform or to new things that we're doing, like, how do they respond to it? Do they actually want, seem to want to engage with it? So yeah, I think even if you don't get directly involved with a customer conversation, like maybe you're a developer that just like terrifies I think there are a lot of like new ways now to start, to at least get like proxies for that.

Austin Spiegel: 20:59

Yeah, absolutely. Our Forward to Flight engineering team is actually curating content from customer conversations to share with the engineering team. So that's a really great way of getting exposure without going and sitting in on a meeting. I think to your point too it's really easy to over index on maybe one customer, for example. And different companies have different ways of doing things. So if you're building a tool that is, going to be used in their internal processes, you could pretty quickly build a tool that maybe overfits to that company. It's important to both get a broad perspective, but then also cross reference that with what you mentioned, like analytics screen recordings, various tools you can use now to understand the total, get a really better picture of the customer and the user.

Ben Lloyd Pearson: 21:42

Yeah. So you mentioned that you have this like forward deployed engineering team in your experience, like what are the, like some of the traits or the qualities that you typically see in like the people who do that type of role versus like the other side of your engineering team?

Austin Spiegel: 21:58

Yeah, that's actually a good question. To be honest with you, this is not a function that I've previously worked with. So it's still trying to feel out, like where do you draw the line? And ultimately, I actually had a lot of hesitation in building a forward deployed engineering team because it always felt like something that would turn into more of a crutch, Than it would be an accelerant. Because we would ultimately, rely on these people to fill in the gap between where the product is and where the customer is. But what I realized was It has actually helped us learn more about our customers more quickly because we have a more touch points and a higher surface area with the customers. So what, what makes those people different or what are the traits that they have that our engineers don't? I would say generally, It's really more of a domain experience type thing. So these people, as I mentioned, have all worked, in this role. And actually, the type of software engineering that they were doing in that role is very different from the type of engineering that we do in our core engineering team. We're building a big data and full stack web application. And So the skill sets you need for that are inherently different than if you're basically writing code that runs on a spacecraft. So the Forward Deployment Engineering team, they have that spacecraft coding experience. They also have the experience of testing spacecraft so they can deploy or employ that engineering knowledge. But then what they bring to the table is actually the experience of doing that role. So if they were to come in, work in our core engineering team, they wouldn't necessarily have the skillset that's necessary to go and build a big data system, for example.

Ben Lloyd Pearson: 23:32

Yeah, and on your point with the, having more touch points from this forward deployed team, there's some products out there that just have much longer adoption cycles than other products. Often because there's some major technical challenges or customization, et cetera. And yeah, I, I do resonate with that a little bit that, you know, having that technical team more involved with the customer really gives them through, if you have a more extended cycle, it gives that customer a lot more confidence in your company's ability to actually deliver the things that you're telling them that you're going to deliver. Yeah.

Austin Spiegel: 24:08

Absolutely. Yeah. I want, we have very technical customers and also we have very many user personas. So we have people who are responsible for SIFT at their company and integrating their various tools with SIFT and then we also have software engineers who use SIFT. We have hardware engineers who use SIFT, manufacturing technicians who use SIFT. So we need to tailor our communication to each of them. And I think for many of those customers, it helps or they appreciate interacting with people that are highly technical.

Ben Lloyd Pearson: 24:40

Yeah. I'm interested out of all those groups you just listed, or any of them the ones where they benefit in particular from having this forward deployed team, or is it just across the board?

Austin Spiegel: 24:51

Yeah, good question. I think certainly if you're responsible for owning SIFT so just to maybe back up, typically what we find is our customers have built some version of this tool in house. So they have a small team that is building and maintaining that tool. And now that team can go and work on other problems that are more core to the business of the company. But somebody on that team might be responsible now for integrating Sift So of course they're very, really appreciated. The Forward Deployed Engineering team coming in and helping them get the various devices, vehicles, machines hooked up to SIFT. And then I think secondary to that, there's the Hardware Engineering team who benefits from the Forward Deployed Engineers because they get to see how to use a tool and they get help from the Forward Deployed Engineers in basically configuring the tool to help them find problems in their vehicles.

Ben Lloyd Pearson: 25:50

Yeah, I personally love meeting teams who have already built a solution that I help sell in house because those teams always know how big the problem is, and they also know that an expert can be a massive help to them. So they tend to be the easiest conversations, so I definitely understand that one.

Austin Spiegel: 26:11

Yeah, it goes back to having a unique perspective on a problem. And then, building a company around that. It's definitely been, it's made it, I don't want to say easier, but it's certainly been helpful in getting customers and ultimately helping them solve their problems.

Ben Lloyd Pearson: 26:27

Yeah. So do you have any other advice for engineering engineers or engineering leaders that want to transition into a more product oriented role?

Austin Spiegel: 26:38

Yeah, I thought about this because I feel like the whole conversation has been about this, right? Ultimately, I think it just goes back to. What is recognizing in yourself, like what makes you motivated and what makes you excited and happy to work? I don't necessarily think this needs to be a role for everybody. And as I mentioned, there are phenomenal engineers who would prefer to spend their time in deep technical problems. And there are plenty of opportunities for that. But if this is something that you're genuinely interested in I think ultimately spending more time with customers, spending time around great product managers as well. And getting experience from them. I think something that I thought of as well for maybe developing a product sense was being curious. So teaching yourself new things. If you're working on SAS products, like using different SAS products is actually a great way to build a better product sense. There's a big conversation I think about linear and how linear has been a much nicer user experience. And a much more opinionated user experience than Jira has been, for example, right? And I think, trying new tools like that to better conform what what is good or what is challenging or what challenges people is another good way to, to develop a good product sense. And then, yeah, that, that's how I would start this journey.

Ben Lloyd Pearson: 27:51

Austin, thank you so much for joining me today. We'll have some links in the show notes to some of the resources we talked about today. If people want to follow you, where should they head to?

Austin Spiegel: 28:02

they can follow Sift Stack on LinkedIn.

Ben Lloyd Pearson: 28:07

Wonderful. Thanks again. And that's it for today's show. If you're looking for more insight from engineering leaders like Austin, head over to the Dev Interrupted sub stack for weekly news and deep dives on the latest research in developer productivity and experience. And don't forget to subscribe to our YouTube channel, where we put all of our favorite moments from each episode. And we also deeply appreciate it when you give us a rating on your favorite podcast app, because that really helps us spread the word. Lastly, we also love to hear from our audience, so you can connect with me directly on LinkedIn at Ben Lloyd Pearson, or find this podcast also on LinkedIn at Dev Interrupted, and thanks for joining. We'll see you next week.