How AssemblyAI’s Travis Kupsche Builds High-Impact AI Teams
March 25, 2025 24 min read
Startups don’t grow in a straight line. Travis Kupsche joined AssemblyAI when its teams were small and flexible. Now, he’s navigating the challenges of scaling while keeping knowledge flowing and silos from forming.
In this episode of Keep Moving Forward, Travis talks about the biggest problems of growing quickly. He explains how to keep teams on the same page and balance freedom with structure in making decisions.
Listen in as Travis shares insights on how AssemblyAI approaches team collaboration, hiring, and engineering culture in an AI-driven world—and what tech leaders need to prioritize as AI reshapes the future of work.
Scaling an Engineering Team That Can Adapt and Grow
Scaling an engineering team at an AI startup is nothing like hiring for a traditional software company. The demands shift constantly, and what worked six months ago may already be outdated. For Travis, the challenge has been moving from small, flexible teams to a structured, multi-team model—without losing the agility that made AssemblyAI successful in the first place.
“When I first started, there were a couple of teams, but they were really flexible. There was a lot of shared context. Everybody knew how to work together and were able to really achieve whatever the company's goals were,” he says.
But as the company grew and teams specialized, knowledge silos became an inevitable challenge. Individual teams developed deep expertise, but that came at the cost of broader visibility across the organization. To combat this, Travis has focused on creating strong feedback loops and ensuring that knowledge flows effectively between teams.
“It’s just a very iterative process. The biggest thing for me has been making sure that individuals and teams have clear avenues for feedback so they can surface exactly what’s going on,” he says.
One of the simplest yet most effective tools they’ve implemented is a lightweight, ongoing feedback system. Every week, AssemblyAI asks teams a few key questions to assess engagement, alignment, and potential blockers.
“We initially focused on a couple of questions for the teams we asked on a weekly basis… Literally just temperature checks,” Travis says. “‘How are you feeling this week? Were you productive? Do you have solid work-life balance?’”
Travis acknowledges that they’re still building out more sophisticated measurement tools, but for now, simple check-ins help the company quickly identify issues before they become roadblocks.
Balancing Autonomy With Structure
For engineering leaders, finding the balance between autonomy and alignment is one of the toughest parts of scaling. You want teams to move fast and take ownership of their work, but without the right guardrails, projects can drift off-course.
“It’s a little bit trial and error, and finding the right balance,” Travis says. One way AssemblyAI fosters autonomy is by giving engineers space to tackle bottom-up initiatives. If an engineer spots a way to reduce infrastructure costs or optimize a system, they’re encouraged to take action.
“Some engineers are so excited about driving down costs and making things more efficient. So we give them an opportunity,” he says. But at the same time, teams need clear alignment on company priorities. One way AssemblyAI keeps teams focused is through biweekly sprints and demos, where engineers present their work, share blockers, and get feedback from other teams.
“It's really showing that tangible piece of work that they did,” Travis says, “and then enabling other teams to ask questions so they can get the context that they need.”
Another way they drive collaboration is through deep-dive technical talks. These sessions allow engineers to present on niche topics, helping cross-functional teams develop a shared understanding.
“This has been particularly beneficial because it is enabling the research team to jump in on some of these pieces that are more interesting,” Travis says. “Recently, we went through why we choose the hardware that we do and what are their constraints and things like that. So as researchers are developing their models, they now understand a little bit more about the research and compare the engineering constraints around how their models are going to run.”
Rethinking Engineering Culture for the AI Era
One of the most unexpected challenges of scaling, Travis says, has been shifting mindsets within the engineering team itself. As teams become more specialized, it’s easy for engineers to develop a narrow view of what’s difficult or valuable.
Travis argues that engineering leaders need to push their teams to think beyond their immediate responsibilities. Too often, he says, engineers get locked into specific tech stacks or domains, limiting their ability to adapt and grow.
“Being too narrow with your focus is something that can really hinder you and not give you flexibility to adapt to [the] market or adapt to whatever the next job is,” Travis says. “And can, I think, sometimes even limit your happiness in general.”
At AssemblyAI, he’s focused on breaking down those silos and encouraging engineers to develop transferable problem-solving skills. This mindset shift, he says, is especially crucial in AI-driven teams, where technology moves fast and the skill sets needed today may not be relevant tomorrow.
Transcript
Travis Kupsche:
The biggest thing for me has been making sure that individuals and teams have clear avenues for feedback so that they can surface exactly what's going on and enable flexibility and sharing that knowledge with them of, "Hey, we're hearing you're not understanding the bigger context." That's a problem. That means the teams aren't aligned with moving forward and with whatever the company goals are, so let’s problem-solve that.
Caleb Brown:
Hey, everyone, and welcome to Keep Moving Forward, the podcast from X-Team for tech professionals who are passionate about growth, leadership, and innovation. I'm your host, Caleb Brown, and in each episode we'll dive into candid conversations with the tech industry's brightest minds, seasoned leaders, forward-thinking engineers, and visionary experts.
Today, I'm excited to welcome Travis Kupsche, Director of Engineering at AssemblyAI. Travis's career path is anything but conventional, starting in physics and naval acoustics analysis before transitioning into software engineering and AI leadership. His journey is a testament to the power of adaptability, continuous learning, and taking on complex challenges across industries.
In this episode, we'll explore Travis's approach to leadership and how his diverse background has shaped his problem-solving mindset. He also shares the strategies he's used to scale engineering teams in both startup and enterprise environments. We'll dive into the nuances of remote leadership, building a strong engineering culture, and navigating the rapidly evolving landscape of AI infrastructure. If you're looking for insights on engineering leadership, mentorship, or how to thrive in a fast-moving AI space, this conversation is packed with valuable takeaways. Let's dive in.
Very happy to have you here today, Travis. I had the opportunity to dive into your background and look at everything. Your background spans from physics to naval acoustics analysis, all the way up to leading engineering teams at Google and now being part of, I would say, one of the most innovative AI companies right now. So you bring a wealth of experience and like I said, very happy that you took some time to chat with us today.
Travis Kupsche:
Cool. Thanks, Caleb.
Caleb Brown:
Absolutely. So speaking of your background, let's go ahead and maybe start off that way, just learning a little bit more about you. Maybe you could walk us through a little bit of that unique career path that I was talking [about], from physics and mathematics all the way up to engineering leadership.
Travis Kupsche:
Cool. Yeah, so like you mentioned, I started off in an atypical path to get into software engineering. I did my bachelor's in physics with a theoretical focus and then a minor in math as well. This brought me, like you mentioned, into what was a physical science analyst role, which I ended up doing a lot of acoustic simulation. One interesting project we worked on was mapping out sound trajectories so the navy could avoid hurting the whales as they did their naval exercises. And that was kind of my intro into software engineering of building things a bit more scrappy than I now run things, but I learned a lot on the job and got a lot of experience. And then eventually, I got a call from Google, did the interview, and started at Google in 2014.
Looking back, I think that really shaped a lot of the ways that I approach teams in terms of mentorship, getting diverse backgrounds, and this idea of having space to fail and succeed. And then in my first portion of tenure at Google, I was focused on a lot of data pipelines, internal APIs, primarily in Java.
Midway through my career there, I switched to an SRE role for GCP, so I held the pager for that and just dove into reliability engineering for about, I think it was about two years. I moved back to Southern California, spun up a few teams focused on data pipelines, serving our customers and stuff there. I ended up [an] area tech lead for about three teams, 30 engineers, really focused on the technical direction of vision across those teams. All in all, I spent about nine years at Google.
Then in early 2023, I moved to AssemblyAI and took off from there. Yeah, and I can touch base a little bit more on my trajectory there, which was accelerated as things sometimes are in the startup world. I started off as a staff TLM for what is now the data infra team. About nine months after that, I moved into this director of engineering role, and now I'm partnering with the director of research, Takuya, and then the CEO, Dylan Fox, to focus on a lot of the roadmap and strategic planning for the teams. And now I'm leading a team of about five engineering teams. We have platform engineering, broad engineering, which is focused on our accounts and billing, and then Lemur, and then the MLP (machine learning platform) team, data infra team, and then our data ops team as well.
Caleb Brown:
You've covered so much and that's interesting, and we're obviously going to get more into that, but always just extra fascinated when folks have such a unique path that does all eventually come together. I'm interested in what inspired that transition from an individual contributor to more of the engineering leadership. What made you want to do that? Because I personally know folks that have gone both routes that love being an IC, and then folks that do want to go into engineering leadership. So I always like to ask folks like yourself, what inspired that transition?
Travis Kupsche:
It was a very difficult transition with a lot of questions and stuff. But as I interviewed at companies and throughout my career, my guiding principle is continuing to focus on hard problems. And my previous director at Google, I had a conversation with her about why she moved from an IC to getting more on the management director route. And she's like, "Well, there are still very hard problems to solve, they're just different." And that changed my mindset.
So I see it as a similar trajectory, all in all, going from physics to acoustics and just doing something hard and learning along the way. But now it's a different scale and different skillset needed to accomplish something, so continuing to learn and grow and build a different set of skills.
Caleb Brown:
Absolutely, that makes a lot of sense. I keep focusing on the fact that you have such a various domain history from naval acoustics to AI. How has that diverse background shaped your leadership style?
Travis Kupsche:
I think one of the big things of when I went from physics and I started from my physical science analyst background looking for other jobs and seeing what the opportunity was, there was a divergence of companies. Some companies would call you, find out you did physics, and then just back away and just end the call early. At Google, they gave a lot of space for people to grow and excel in their area, whatever their background was. And I think that was really important to me and has shaped the way that I approach structuring teams and have- what I look for as we're hiring and things. I want people that are flexible with what they can learn and what they're interested in as well as being able to excel at that.
Caleb Brown:
We talk a lot about scaling in different ways here, but we are typically talking to engineering folks that manage engineering teams and things like that. So I am curious… you talked about being involved in more of a startup environment but also being involved at Google and things like that and seeing different challenges. I'm interested in what the biggest challenge is you faced, from scaling from 20 engineers to 200-plus engineers, that process of scaling to that level of engineering, what challenges have you seen from that?
Travis Kupsche:
For me, the biggest challenge is because we're a startup and because the teams have started off so small, any sort of scaling ends up probably being close to, at least right now, as an order of magnitude change. When I first started, there were a couple of teams, but they were really flexible. There was a lot of shared context. Everybody knew how to work together and were able to really achieve whatever the company's goals were.
But now, as we've developed focus areas for teams, this does two things: On the one hand, it allows individual teams to develop deep expertise and go really deep and know their area really well. At the same time, there is now so much more knowledge that that team has that a shared context of all of that information isn't really possible for the other four teams that are there. So really continuing to find ways of sharing that information, making sure people aren't siloed but also not receiving too much information.
So it's just a very iterative process. So really, the biggest thing for me has been making sure that individuals and teams have clear avenues for feedback so that they can surface exactly what's going on and enable flexibility and sharing that knowledge with them like, "Hey, we're hearing you're not understanding the bigger context." That's a problem. That means the teams aren't aligned with moving forward with whatever the company goals are, so let’s problem-solve that.
Caleb Brown:
I'm interested in metrics maybe or indicators that you use to gauge team health when you are doing that rapid growth. You're in an interesting position, again, where there's a lot of innovation, a lot of building, so you have to be looking over that whole team and making sure team health is good or knowing when to jump in. So is there anything specific you look for in that situation?
Travis Kupsche:
I wish I could say that we have everything instrumented and measured and we know exactly what's going on, but I think initially as we're developing tooling and measurement and stuff that's consistent across the teams, what we initially focused on was a couple of questions for the teams we asked on a weekly basis to really debug things. It was literally just temperature checks, scale of 1 to 10, "How are you feeling this week? Were you productive? Do you have solid work-life balance?" And feeding that back.
And so you can see sometimes there'd be an uptick in whatever. With that information, we were able to action on it. There were some places for feedback and stuff for people to share exactly where those pain points are. We're starting to trend in a direction where we're now tracking incidents, we're breaking them down. We have some very light measurement around our CI/CD build times and process and stuff that we're building out. So really orienting around productivity on the one side as well as engineering pain points.
So building that out this quarter. And then we're also being really transparent with the teams about what metrics are we tracking and sharing, what our action items are, and what benefits they're getting as well. So that's the direction that we're going, and again, drop those roadblocks and get people moving smoother so they can focus on the stuff that you can't automate.
Caleb Brown:
No, totally. I wanted to talk a little bit about remote leadership as well as culture. And X-Team is a 100% remote company, so over the last years I've seen a lot of interesting things and initially, for me, adjustments of going into a fully remote team. So I was curious what challenges you've encountered doing that, leading a fully remote engineering team?
Travis Kupsche:
Yeah, it's been challenging… being able to find time to connect and find the right amount of time to connect. I think the technology team is really split probably close to 50-50 between the U.S. and Europe. We have a few people in India, a few people in other places, but that's generally the split. So there's about two hours where we have time to sync and it's early morning for the U.S., late in the day for Europe and stuff. So really, it's about finding avenues to get shared context and make sure that information travels. I think we focused very much on the remote-first and getting the talent that we needed.
And I think as we've grown, we've recognized the need to really have co-located pods of people that can communicate in at least the same time zone and have that shared context and execute effectively. So we're kind of orienting a little bit more around that, making sure that people can move that direction. I think there is some benefit and some threads from the GitLab… their guidance on remote work. I don't think we're close to being able to be fully…. wait a 24-hour cycle to get a response state that they're in, but kind of trending in that direction and helping everybody move more quickly wherever possible.
Caleb Brown:
Of course, communication is a huge part of this. I'm interested if you have any strategies for effective ways to maintain that clear communication even though the team is distributed?
Travis Kupsche:
Yeah, I think it is about having that shared personal connection. One thing that I've noticed as well that doesn't come up as often but sometimes it can is just cultural differences among how people communicate via Slack or in person. Last year, we did a training with the tech teams of just like, "Hey, this is how different cultures, different countries, different ways of approaching things might show up and how they might interpret our communication differently."
That's one piece. And then I think the other piece of a shared trust. Earlier this year, we did our engagement survey. I think it was 100% of the engineering team trusted everybody on the team, which is great, but it then gives you space to work through those interpersonal things rather than assuming mal-intent. You can jump in a call and be like, "Hey, I know you meant well by this, let's talk about it." So I think keeping that score up has been really important as well.
Caleb Brown:
Totally. And how about the more culture-building side of that, just building and maintaining that culture in a remote-first environment? Before I joined X-Team, I was a software developer actually in a more traditional office. And I think X-Team does it well, but it was interesting to see the very different ways that we built culture and part of that was annual offsites in person and things like that. But I'm just curious how you've continued to work on maintaining culture in a totally remote world.
Travis Kupsche:
One thing that I've really been thinking about is around how teams and individuals give feedback to one another. I think everybody in the engineering team is really excited to be here and has a very positive and upbeat attitude. I think where that can come in… in a more challenging aspect is that a lot of the team is very excited to give positive feedback but hesitant to give growth feedback.
Recently, we're rolling out a training around how to give effective feedback and the value of really surfacing some of those growth opportunities in a way that is well-received and is supporting everybody.
So I think including that. And I think that's from both a communication standpoint and a growth standpoint, that's going to be really important going forward.
Caleb Brown:
Absolutely, yeah. I wanted to pivot a little bit to talking about autonomy really and just engineering processes. I'm interested in how you strike that right balance between process and yet developer autonomy?
Travis Kupsche:
That is a great question. It's a little bit trial and error and finding the right balance, again, like adjusting as things move forward and as we scale. But really, it is a combination of, "We're a startup, we've got to hit some metrics, we've got to hit some product features," and things like that. So really being clear on what do we need to focus on as a company and then giving teams the expertise to work on that goal as well as some bottoms-up initiatives.
For example, I know some engineers are so excited about driving down costs and making things more efficient. So giving them an opportunity to like, "That sounds great. You're the expert that knows exactly how this audio flows through the system and know exactly where the pain points are. Just go write a design. Let's go do that." Yeah, so kind of a combination of both.
I would say the other thing, we're in this interesting space where we have both team-level goals as well as cross-tech goals. So enabling both fronts of the collaboration and teamwork, the big projects as well as the individual teams being able to focus on what they know is most important.
Caleb Brown:
Yeah. So here's the question that I wanted to circle back on, like I said, because you touched on it earlier, but I did want to drill in a little bit more. I'm curious what strategies you use to maintain that transparency while avoiding that information overload. You want to share everything with everyone, but sometimes that's not the best thing to do. So I'm curious your strategies for approach there.
Travis Kupsche:
We approach a few different avenues. We do biweekly sprints. So every two weeks, we're running sprints and then each team gets to update the rest of the teams on what they accomplished, what the blockers were, and then they give a short demo. So it's really showing that tangible piece of work that they did. And then enabling other teams to ask questions so they can get the context that they need because not all teams are going to know what all other teams need to know. It's kind of cursory. And then I've seen other teams connect with the tech lead and grab some more information off of them after the meeting. So I think that's all working as intended.
The other area that we've really focused on is having deeply technical conversations and think of them as your brown bag lunch and somebody will talk really deeply and go into all the details and Q&A and stuff for a specific area. I think this has been particularly beneficial because it is enabling the research team to jump in on some of these pieces that are more interesting. Recently, we went through why we choose the hardware that we do and what are their constraints and things like that. So as researchers are developing their models, they now understand a little bit more about the research and compare the engineering constraints around how their models are going to run and what our considerations are.
Caleb Brown:
Very cool. I'm interested how you promote continuous learning in such a fast-paced AI environment because I am not working at an AI startup, but as I read news every day, there's a lot, but obviously beneficial to take all of this in. So is there anything you do to promote continuous learning in that space within your teams?
Travis Kupsche:
Yeah. Organizationally, I do focus on making sure that teams know that there is horizontal mobility. For example, the billing team doesn't touch AI as much in an AI company and there is opportunity on the machine learning platform team to jump in there, do a rotation, or move on that team. So I think the longer-term career trajectory, that's a good path. The other area that we focus that we're trying to roll out is each quarter focusing on a week where we have a different initiative that we're focused on as companies are dropping the work.
We did a bug bash two quarters ago. This last quarter, we actually ran an all-company hackathon. And I think three of the ideas we're going to put into either production or internal tooling. One of them was just reducing the sandbox costs, so now you just spin up exactly what you need rather than the full stack. We came up with an entirely new playground that does automatic generation for the API. So it's great to see that cross-functional thing. So in terms of learning, jump in and do something new, and then as well as understanding what other people at the company do.
One of the requirements was that we had, I believe it was each team had to be composed of individuals from at least two different managers. So we really got a lot more cross-functional support that way and learning from that perspective. So yeah, so really focused on that. I'm working now with the tech leads to start a book club and learning club, learning forum, as well where they can understand a little bit more about leadership and learn from each other there as well.
Caleb Brown:
I'm interested in talking a little bit about the engineering mentorship and what strategies you implement to help senior engineers mentor junior team members and again, especially in a remote setting.
Travis Kupsche:
Yeah, this has been challenging coming from both the startup side and the remote side, and an active discussion because as a startup, we need to move quickly and want to make sure that if somebody more junior joins, they actually have the support that they need to... Right now, there's some ongoing conversations as to how to really implement this and make sure that it's effective as we start to hire more junior engineers probably next year and move into that space.
What we're centering around right now is making sure that if we do hire more junior people, there is a hub there. There is people that they can meet in person and actually talk to you and get support from. For example, our hub is mainly in New York and then we have a little bit of a hub at San Francisco, so those might be the first two areas where we really start to scale this up. We do want to make sure that somebody is ideally in-person when possible just because that back and forth seems so important. And then having those hubs where they can work together with other people and get that shared context that would be more challenging.
Caleb Brown:
Absolutely. Very cool. And it makes sense. I have a bunch of questions to start closing things out, but I have plenty more here and I really like to finish up talking a little bit about future outlook stuff and even personal feelings on the industry and things like that. So I'm interested in how you see AI infrastructure evolving over the next few years. I often will ask 5 to 10 years, but it's essentially impossible to look that far out. So I'm just curious how you see that AI infrastructure looking just in the next few years.
Travis Kupsche:
I think where we're looking right now is there are incredible models being built left and right, new capabilities all the time. And I think where we're looking at or focused on is they're expensive. They're incredibly expensive. So really looking at what does it look like to optimize and get this into the hands of more consumers and things like that.
So I think realistically focused on driving down those costs, whether that's through hardware or software implementations or even specific models that are trained to be a bit cheaper, a bit faster, and things like that. Granted, I am focused on the ASR space and then peripheral of the LLM world and everything. So that's what we're looking at and focused on.
Caleb Brown:
So from that, what emerging challenges do you anticipate for engineering leaders in the AI space?
Travis Kupsche:
For us, in particular, one thing that we're really thinking about is, "How do we scale?" Because as the GPUs get more efficient and we can drive down those costs, our products should get more adoption, people should be more bought into it and more used to it. So getting clear on what levers can we have to really reduce those latencies and those costs and be more efficient in general.
Caleb Brown:
I asked you a lot of remote questions over this because it's so fascinating to me truly just because I feel like… with a lot of companies now, remote's not so abnormal anymore and yet it's still a challenge and folks are still figuring out what works for their organization. So in this spirit of looking forward, I'm interested in how you think remote team collaboration will evolve with all of these evolving technologies that we've been talking about?
Travis Kupsche:
Oh, that's a really good question. Yeah. As somebody more senior, I really enjoy the remote work environment and the flexibility that it offers. And I also see some of the challenges on the more junior level. So I think as humans, I don't know if we can get away from, at least, initially in our career, having a lot more of that face-time and a lot more of that connection.
I think it's something that we won't ever really quite be able to get away from. There is such a different vibe for the month after an all company offsite where everybody connects, understands each other, and then just starts running with things faster than they did the month before. So I think it'll continue to be a combination of the two and figuring out exactly what those avenues are to support people in their growth is going to be really important.
Caleb Brown:
Awesome. Yeah. So going back to the top of our chat, I'm interested if you have any advice that you would give engineers that are in that typical engineering role looking to transition into leadership roles as you've done? I'm just curious, any advice, anything that you can give to folks in that position?
Travis Kupsche:
Yeah. I think the one thing that really opened my eyes was probably, it's called An Elegant Puzzle by Will Larson. And it's this really nice book, very structured, so it's very much easy to consume as an engineer, a lot of references, but took this amorphous thing of what is management, what is leading teams, what's important, and added some structure around it so it wasn't this mushy space that I had to operate in and gave me some initial frameworks and some initial readings. So I'd highly recommend that.
And definitely if you're exploring the other side, read Staff Engineer, the same author, but they're a nice pairing to go together. And then talk to your senior leaders. I think that is such an underutilized resource… Yeah, it's always such a great conversation when you could ask someone more senior than you what they think. And everybody's always been excited and interested in giving feedback and coaching and everything. So really leaning on people, even if it's your skip-level, they're probably excited to touch base with you and see what you're doing and give some guidance.
Caleb Brown:
Awesome. And one of the questions I typically ask everyone that I chat with here, and I do think it's an interesting one and may take a little bit reflecting, but if there's one thing you could change about engineering culture industry-wide, what do you think that would be and why?
Travis Kupsche:
What would I change about engineering culture? I'm going to share this, which I've been mulling over quite a bit lately. I think there's an over-focus on the specifics. And I guess what I mean by that is, we have a data infrastructure team and then there's the production platform team. There's various teams, they all are doing difficult things. And as I got some feedback from some of the ICs around the data infra team and thinking they're almost a team that don't do hard things and recognizing everybody's doing hard problems and they're all challenging.
You get to a certain point where it is all about moving and transforming data in different ways and at different scales. So I think… recognizing that, I think being too focused—too narrow with your focus—is something that can really hinder you and not give you flexibility to adapt to market or adapt to whatever the next job is. And can I think sometimes even limit your happiness in general of feeling like you need to work on a front-end system and maybe that role isn't available but there's super challenging stuff that could translate later on or grow your career in a different direction. And I think being okay with that will set yourself up for more success.
Caleb Brown:
That's a great way to answer that. I just have a few more to wrap up and they're a little more casual, personal, however you want to put it. But I'm interested, like we said earlier about how there's just so much stuff coming out. If you're watching AI news and everything, there's just so much. But I'm curious… from everything from the professional business side to just consumer apps, what in the AI space recently has really caught your eye? Just something you thought was cool or fun or interesting or helpful? I'm just curious because I read it every day, but you're even more involved certainly than I am. So I'm just curious from someone's perspective like yourself.
Travis Kupsche:
I will tell you something that I've really enjoyed or found surprising… Because I want to be such a high-performing individual and be a perfectionist in what I do, it can be really hard to write that policy doc or that process doc to the teams and everything. And I think it's been incredibly helpful, the number of LLMs that are out there and finding a specialized one, not that this should be leveraged for all of the details, but getting something on paper of like, "Hey, these are my general ideas, can you throw this into words?" And as an engineer, I think that's lowered the bar so much for me to get started on things that it has been absolutely incredibly helpful.
Caleb Brown:
Awesome. Very cool. Forget tech here. Before we even hit record, I was saying how awesome your background is right now. And for anyone just listening, Travis has a very cool setup behind him with a lot of awesome coffee stuff. Will you talk coffee a little bit with me? Will you tell me a little bit?
Travis Kupsche:
My teams are tired of hearing me talk coffee, but I'm happy to. Yeah, this is a new audience. I will tie this back to some of our conversations and then I'll dive into the coffee. One of my biggest values is growth, so I've translated that into coffee, of like, "How can I make the best coffee?" So I have the EG-1 over here on the left, I have the Stagg kettle, all of these things. So I'm very focused on getting the last mile of coffee flavor out in my setup. Probably end up too caffeinated too much of the time. And I don't know if you can see, I have The Physics of [Filter] Coffee back around here and then The [World] Atlas of Coffee as well. So I'm very interested in understanding all of those pieces.
Caleb Brown:
That's awesome. I love that. I'm actually a big tea guy. I do drink coffee, but I'm a big tea guy. And what got me into it, which I think is probably similar to you, was the ritual behind it. Just the whole process, just a fine, delicate, beautiful process that is.... I started in my career as being a programmer. There's something nice about having that flip side, something that's so not tech, right? Drinking leaves always felt good to me. But yeah, cool to see a coffee connoisseur and I just wanted to point that out. But yeah, that's everything I have today. This was really interesting and helpful. Travis, thank you so much for joining today.
Travis Kupsche:
Yeah, thanks for having me, Caleb. This was a great conversation.
Caleb Brown:
What a fascinating conversation with Travis about navigating engineering leadership, scaling teams, and fostering a culture of innovation in the AI space. One thing that really resonated with me was Travis's emphasis on adaptability. How his background in physics and naval acoustic shaped his problem-solving mindset and ultimately led him to AI leadership. His journey is a great reminder that technical excellence and leadership are both about continuous learning and embracing new challenges.
I also appreciated his insights on scaling teams without losing sight of transparency and collaboration, as well as his approach to remote leadership and building a culture of trust. His perspective on balancing process with developer autonomy, and encouraging feedback-rich environments, is something that all engineering leaders can take to heart.
Thank you, Travis, for sharing your experiences in leadership philosophies and for the thoughtful lessons on growing both as an engineer and as a leader.
And thank you to our listeners for being a part of this conversation. It's stories like these that remind us why we keep moving forward. Join us next time for more insightful conversations with tech leaders who inspire us to grow, lead, and innovate, find us on Apple Podcasts, Spotify, or YouTube Music. And don't forget to share this episode if it resonated with you. Until next time!
SHARE:
