When code is cheap, the hard part isn’t building – it’s deciding what’s worth building, and building the systems and culture to recover when something breaks.
Sam Smith leads product and engineering at Motion, where a team of three-and-a-half people ships compliance software for college athletics.
AI didn’t make his job easier; it moved the bottleneck. The constraint used to be how fast you could write code. Now you can build almost anything in a week, which makes restraint, not speed, the skill that separates good engineering orgs from chaotic ones.
In this conversation, Sam and I get into what actually changes when building gets easy: why “just because you can doesn’t mean you should” is now a discipline you have to practice on purpose, how to slow down in planning so AI can let you move fast in execution, and why the goal shifts from preventing every bug to finding and fixing it before a customer ever picks up the phone. They dig into the safety systems that make speed survivable – feature flags, comprehensive test suites as living specs, error logging, and the trust those systems rebuild between engineering and the rest of the business.
If you lead an engineering team, build product, or write code for a living, this episode of The Hallway Track names the tension you’re sitting in right now.
Transcript
SAM SMITH
[00:00:00] Code is on the same level as talk and ideas now, everyone’s got them and everyone can produce it. Just because you can doesn’t mean you should.
CHRIS VANNOY
[00:00:12] Welcome to the Hallway Track. I’m Chris Vannoy. This week I’m talking with Sam Smith, who leads product and engineering at Motion Sports based out of Bloomington, Indiana. Sam runs a team of about, eh, three-and-a-half people building software for sports compliance in college athletics. It’s a market that’s shifting under their feet,
If you follow this space at all with, name, image, likeness or NIL, the house settlement and new legislation seemingly every week. That world is crazy enough that Indiana a national college football title, which is still mind-boggling. We get into what happens when AI makes code cheap enough that you can build almost anything in a week, because once you can, the hard part isn’t building, it’s saying no or saying not yet.
We talk feature flags, test suites, and why shipping fast safely is really about getting good at recovery instead of prevention. If your team just got a lot more capable and you’re realizing the bottleneck moved from writing code to deciding what’s worth writing, this one’s for you
Howdy, folks. Chris Vannoy again. Today’s guest is Sam Smith, who leads product and engineering at Motion. Sam, can you give a little bit more of like, uh, who you are and what Motion does and all that fun sort of stuff?
SAM SMITH
[00:01:27] Sure, no problem. Good to be with you, Chris. I’m Sam. Hi. I have been working in startups and tech for a little over 15 years now. I started working at a startup in Indianapolis, and I intentionally was looking for a startup that very quickly got acquired by, ExactTarget, and then very quickly after that got acquired by Salesforce.
So I went to work in the startup world and got this really quick intro to small, medium, and large businesses. and that was really eye-opening. I especially learned that I like working in small businesses the most. so I, went and joined a startup called Sigstr, which I believe you’re familiar with
CHRIS VANNOY
[00:02:06] Yes, that’s actually where you and I first met was at Sigstr.
SAM SMITH
[00:02:09] That was, that was a great move for me. I was much happier to be back in a smaller place. and, yeah, ha-have been working in that kind of mode, ever since really, just small company one after another. I like building stuff from the ground up. I’m a software engineer by trade, but, I like to think I’m a product builder end to end.
I like being able to listen to problems that people have, translate that into something that we can build and create for them. Ultimately, it’s just really fulfilling for me to see someone else’s job or life get easier based on something that I’ve built. so I’m doing that now for a company called Motion Sports.
We’re Indiana-based. We’re spread out a little bit. We’ve got an office here in Bloomington where I am. and we are trying to reinvent the world of sports compliance for higher education, institutions. And it sounds really unsexy and boring, but
There’s a whole lot to learn. Most of my career is in MarTech, so it’s a, it’s a bit of a pivot for me. But there are still a lot of lessons to be applied, and just with any business where you’re building and shipping software, a lot of that same discipline applies. It’s a fun time to be doing it
CHRIS VANNOY
[00:03:13] The world you’re working in is actually changing rapidly, especially right now with, like, house settlement and NIL payments and, like, all sorts of other stuff, right?
And so y’all, like, started this right in the maelstrom of all this change in the industry you’re actually trying to help. How has that impacted the way you’re doing development and actually trying to build product in that sort of environment?
SAM SMITH
[00:03:35] With a small business, you have a lot of moving targets and you have to pick what you want to build and what you want to go out first with, and that alone is a challenge. and then, yeah, you throw in the daily news briefs where so-and-so’s proposing legislation that’s gonna change something.
And that makes you kind of pause and go, “Are we still doing this? Should we… Is that the right way to go?” you have to find ways to be able to bring in that kind of external feedback loop and keep yourself flexible. We have definitely made conscious decisions to go in different directions or, or to, to not do something, or to put something on hold.
I’m finding in a lot of ways, finding the right way to say, No, but maybe we can do that later. No, but that’ll go on the backlog. No, but we think that’s a good opportunity when the right customer comes along.” That kind of mindset definitely helps when there’s a lot of things shifting.
CHRIS VANNOY
[00:04:29] Yeah, and that was kind of like for those who don’t know Sigstr, which I don’t know necessarily why you would um, so,
SAM SMITH
[00:04:35] There are– I still see some email signature with, with that.
CHRIS VANNOY
[00:04:39] Yeah. Yeah, every once in a while it still pops up. Um, so that was a lot of the way we worked there too, was, we would get customer requests coming in all the time, and a lot of your and my job sometimes was to say like, “Not yet.” Right? Like, um, “Maybe not right now. That’s a great idea, but maybe later.”
SAM SMITH
[00:04:57] Build up the critical mass of people asking for this, and then you have a better idea that it’s the right time to do it
CHRIS VANNOY
[00:05:03] Yeah. And I think we, we got into a workflow after a while where we were really good at, like, doing what I like to call, like, the simplest, stupidest possible thing to solve the problem, right? Just so we could find out if it was a problem that was actually worth solving. Lots of times, even in small companies, you’re working with both customers and internal folks who think they know what the, what they actually want, like what the right solution is for a problem.
And the thing is, they don’t. And that’s one of the things I realized.
There’s nothing more frustrating for a software engineer usually than working on something that no one uses, right? if you’re hiring the right software engineers, in my opinion at least, that is a thing that actually ticks them off worse,
It’s like, “I built something and it was a waste ’cause nobody ever uses it.” And so at Sigstr at least, I found it really helpful to think through how can we quickly find out is this the right thing? Is this something someone will actually end up using at all, right? Which sounds a little bit like you’re still carrying that philosophy forward into, Motion.
SAM SMITH
[00:06:02] Yeah, we try to. and I mean, you’re, you’re so right about… It’s one of the first things I think of when I’m looking at something that we’re going to build. And now, you know, it makes it easier if, if that idea is coming from a customer in the first place. Gives it some weight. but yeah, it’s really tempting to sit there and think like, “Is this just gonna go and collect dust in production?”
Maybe you just need to be able to advertise that you checked the box and you have the thing and it’s available, and it’s there if anyone ever needs it. but yeah, from a, from a kind of creative fulfillment standpoint, you want to see stuff get used. I kind of call focusing on that like some kind of like radical, radical focus on, and being ruthless about picking and choosing what you’re doing, but also how much and in what way you’re gonna do it.
And that was, that was back in a time where the robots were not writing the code for Js. And so we really had to be diligent about how much time we’re gonna spend on a thing
CHRIS VANNOY
[00:06:58] We’ll circle back to that in a minute, but how are you using AI? ‘Cause you’ve got a pretty small team to be able to support all this, don’t you? Could you get in a little bit about the team and how I- AI helps you keep that a little, little on the lean side these days?
SAM SMITH
[00:07:10] Yeah. Yeah, absolutely. we have a handful of builders on the team. and I, I would call that a small squad to work with, like, for any small business. but the, the rate at which we’re putting out stuff and serving customers and the surface area of everything that we’ve built and touched just in the last couple years, really feels like there’s a way bigger team behind it, which is part of the value of, of having AI in the mix.
It allows us to… I mistakenly said something like, “We can build anything in a week,” the other day. And I hadn’t thought about saying that out loud first, and I, I think I kind of believe it though. it shifts… It makes code cheap,
CHRIS VANNOY
[00:07:50] Yeah. Well, uh, code is al- The thing I’ve said is like code has always been the cheap part. Like it’s, it’s always been the easy part of the job is the actual like mechanical writing of code. And like a lot of my theories are that AI just makes the easy part easier, right? and then you’re, you’re already hitting at the next thing of like what actually gets harder is saying no, right?
Like, or again, not yet, or like maybe not right now. How are you navigating that? Like, as, as you’ve already mentioned, you realize like, “Oh God, we could build anything we want.”
Um, how do, how do you say no in that environment?
SAM SMITH
[00:08:25] Yeah. It’s, code is on the same level as talk and ideas now, for sure. everyone’s got them and everyone can produce it. I have written down in my notes as a reminder for myself, just because you can doesn’t mean you should.
CHRIS VANNOY
[00:08:39] What’s the Jurassic Park quote?
They realize that they can and never, you know, thought to wonder if they should. Like, you know, that sort of thing.
SAM SMITH
[00:08:46] That is one big pile of code, yeah.
CHRIS VANNOY
[00:08:48] Because that stuff is so cheap and easy to come by now and anyone can do it, what matters is the follow-through. It’s the execution. you shouldn’t execute on everything. but the stuff that you do choose to go and execute on, you have an opportunity to, to do it well.
SAM SMITH
[00:09:02] So for, for us, the cool part is, you know, AI’s not just running the whole thing, right? There’s still humans in every loop, and I think there always should be. and so it gives us a chance to do common engineering and good product building practices, build backlogs, groom tickets, think about what you’re gonna build, hold a ceremony or two, put some thought and planning and intention into it.
When you’re in the weeds of building something with AI, I always prefer to write a plan first, and that way I’m thinking through something, and the robot’s helping me put the right plan together. Whether you’re doing that on your own as an individual builder or with a team of people trying to figure out what to go and do and when, slowing down to speed up, a little bit more thought in that planning process so that when you’re ready to pull the trigger and really start going, AI AI can just let you run as fast as you want to go
CHRIS VANNOY
[00:09:51] Before we started today, you mentioned like yesterday was also a new sort of AI phenomenon, or I’ve seen it happen other places, but can you describe a little bit like what your day looked like yesterday?
SAM SMITH
[00:10:02] Yeah. So I, I, I’m in this fun spot where, you know, player/coach kind of situation. I’ve got my own things that I need to build, but I’m also helping my team ship and, and move and do things well. I have gotten into the habit of waking up and saying to myself, “Let’s do some code reviews,” because everybody needs eyes on whatever they’re shipping, and we’ve got to put things together the right way and move it through the pipeline.
And so I started doing code reviews, and I use AI to help me do that. and by the time I was done with one, someone else had the next one ready to go. And I thought, “Well, I can’t context shift and go into the thing that I want to build ’cause then I’m ignoring, you know, the rest of the team.” And I’m kind of bad at saying no sometimes.
So it just kind of snowballed. The day turned into a marathon of code reviews, and we got a lot of stuff moved. And somewhere along the way we were like, these are all kind of important changes. Can we get this into production?” which can sometimes be a challenge depending on your processes and what all you have in flight and is it feature flagged or not.
It was really cool to, to just be in that flow and have someone suggest, “Let’s put it out on prod ’cause it’s ready and it works.” and just kind of snowballed through a ton of code reviews, and I didn’t personally build what I needed to build yesterday. but man, we got a lot of stuff done, and it’s the kind of thing that would’ve been a week’s worth of work
CHRIS VANNOY
[00:11:24] That, that again is like from a small team, like how many total are we talking about? I… Like two or three?
SAM SMITH
[00:11:30] I’d say three and a half. Yeah. We’ve got a couple outside resources help- helping build in different ways too. But, yeah, full-time with us is,
CHRIS VANNOY
[00:11:39] Yeah. I’ve gotten into that flow before where you end up like with a whole day just doing code review, but that was with a team like four or five times that size, right? And that’s also a case where like you as the manager are still the bottleneck that has to review everything, which the, the coaching end of my business is usually where I coach people out of that situation.
You mentioned feature…
SAM SMITH
Pay for that.
CHRIS VANNOY
[00:11:59] Yeah, yeah. Um, you mentioned feature flags. that’s the sort of thing that I think about a lot where it’s like if you wanna move fast, right? Like you also have to balance that with like safety to a degree, right? And I’ve always thought of feature flags as being sort of this like if you’re a trapeze artist, it’s like the net underneath that can catch you if you fall,
Except in this case it can bounce you back up on the… Anyway, how have you found feature flags working in your system? How are you using them? What other mechanisms do you have so that you can work quickly without fear of like stuff’s gonna go wrong, stuff’s gonna break, or the ability to recover from it quickly?
SAM SMITH
[00:12:37] Yeah, fe-feature flags are, are pretty important for us. we have a homegrown solution. I built Rails apps for 15 years. Flipper was a very, very common, feature flagging solution there, and, I’m sadly not building in Rails anymore, full-time at least. And so I said to myself, “I’m gonna rebuild Flipper,” and I used AI to help me do that.
We’ve got our own version that lets us manage flags, manage who’s using them, and then the rest of the codebase knows how to hook in and look and see is this flag on for this person, this company, this customer, whatever it is. that gets pretty heavily used. and, in the course of trying to make sure that our velocity going to production is not too slow, we use that heavily so that we can push things out even if they’re not totally done, even if they’re not ready to turn on for a customer.
It allows us to safely push stuff out, and know that it’s not gonna be exposed in a way that impacts the user experience or impacts the system. and then it also gets used for, actual product rollout too. This thing is now out there and available. We can pick and choose who’s gonna use it so that we can do it in a little controlled way and get some feedback, or do it in a broad way and make something generally available for everyone.
Um, it, it’s a slippery slope though. It, it can dovetail into, pricing and packaging really quickly. it’s very, very tempting to cram a lot of things behind one flag. but you also have to, you know, as a– especially as a small business and we’re making changes, to the way we do things a lot, we’ve got to be able to do it at a granular level too and say, “Maybe this customer has these things, but a different customer has
CHRIS VANNOY
[00:14:10] Yeah. That’s, that’s one of the, one of the lessons I learned.we use feature flags a lot at Sigstr as well. that’s kind of Where I, first learned to love them, right? and we abused them, a couple of times for, like pricing and packaging. We had some flags that lived for way too long because they were essentially like licensing checks, And then it, it took a long time for everyone to realize, oh no, that, that kind of hurts. Um, that’s a little painful. And so then we ended up, you know, making new services and things like that. one of the use cases you also mentioned, like product rollout, right? I’ve worked with companies that treat feature flags as more like individual change level flags, and so they end up with lots and lots of little flags.
The way it sounds like you’re using and the way we used it at Sigstr oftentimes was that sort of like product release, where you have one flag for like a whole page or a whole section of the application, and then you can deploy underneath that flag like hundreds of times, right? And no one’s ever gonna see it.
There’s very little to no blast radius of the change, You’re not gonna mess up anybody’s day, you’re not gonna poop in anybody’s punch bowl. it’s just live and it’s in production and the- your engineers get the little dopamine hit, and you get it live and you get like it’s, it’s in production.
And the other nice thing is that then you can have the business actually look at it at some point and say like, “Is this what you meant? is this a good idea?” you can unlock beta customers. Like, it’s really fun once you get used to it. But as you kind of hinted at, and we learned the hard way, like you have to be a little disciplined about what you’re using them for.
Because they end up being a very powerful hammer in a lot of cases.
SAM SMITH
[00:15:39] It’s a very powerful hammer to swing. and it does create tech debt, you know? At, at some point you’ve got a bunch of flags that are just… They’re either on for everyone all the time, or every time you add a customer to the system, you’re turning that thing on. and so you got to make a note to go back and maybe clean that up so it,
You know, we don’t need it in there anymore.
Yeah, it, it’s, that’s an interesting, case you just mentioned with kind of the different ways that a flag can be used. And it reminds me, I, I forget the name of the law, but the, the theory that, systems we build reflect the people around them.
So it’s, it, it’s not surprising that, I have tended to use feature flags in the same way
CHRIS VANNOY
[00:16:17] Well, it’s also work history, right? Like, you find a tool and you realize, “Oh, this worked really well,” and it unlocked a way of working that, like, felt good, right? “This feels right. It feels like we can move really fast without making a public-facing mess.” Um, I’ll put it that way.
Um, like you hinted at, sometimes there’s mess on the inside you need to go clean up. but, like, it’s, it’s nice to be able to, like, unlock that, where you don’t have to review every change quite as closely, which worked well, again, going back in history, like at Sigstr, because we were putting advertising banners in email signatures, right? Well, it’s difficult to attract senior talent to be able to do that. so we had, like, a, a, an overseas team and, you know, I, I used to teach at a coding boot camp, so we were able to bring in a lot of very early career folks, and we were still able to move fast because we developed these sort of safety systems.
One of my theories is that as we move into AI, And AI gets compared lots of times with early career junior engineers, right? These same systems work exceptionally well there, and it’s actually interesting to hear that you’re using those same sort of systems. what else do you have to sort of, like, catch it when things might go unexpected?
Error logging? Like, what, what else you got working?
SAM SMITH
[00:17:33] This is what I tell myself at night to reassure myself that I’m a good engineer . I, I know I’ve been cutting corners in the past. AI now gives me a little bit more time and freedom and speed to say, “Hey, I’m not gonna cut that corner.”
A really comprehensive test suite is a fantastic fail-safe. in regards to what we’re talking about, it keeps you from shipping something out that shouldn’t go. but it’s also… I mean, code is a specification. it’s locking in here’s the way this thing is supposed to work, so that whether it’s a human or a robot coming by later to see how it works or to make a change to it, the coded test suite itself is a documented set of here’s what I expect this thing to do which is great, and you do have to be careful that you’re not just letting Claude go rewrite your entire spec test.
That is something that needs to be controlled and, and you need to put some thought into it. But, it creates a really nice set of rails and a framework for another builder, whether it’s a person or a robot, to operate within.
And if you hook that up into your code review and your deployment processes so you s- you see the test suite run, you see the lights turn green, it’s another safety net in the pipeline that tells
CHRIS VANNOY
[00:18:42] Yeah
SAM SMITH
[00:18:42] This, this is gonna be okay to push out.
CHRIS VANNOY
[00:18:44] Yeah. One of, one of the things, and I think either it’s gotten better or I’ve gotten better using AI to do this, is like it, you still need a human in the loop. You mentioned this earlier, because sometimes in this like test-driven sort of AI things, sometimes the way it will fix a failing test is by like removing security guards, um, right?
It’s like, “Oh, we, we can’t get to this because we get a 401.” It’s like, “Let me go remove the security authorization in front of that.” It’s like, “No, no, no. That’s, that, that’s not what we meant,” right? Again, I’m hitting that a little bit less these days, but like every once in a while it’ll slip one through that’s like, “Nope, that’s not…
No, that’s not how you wanna solve that.”
SAM SMITH
[00:19:23] I was actually interested in getting your perspective, on problems that you have seen from AI adoption within organizations. Kind of going back to that idea of like I think AI is making people builders when they otherwise wouldn’t be, making people more generalists when they otherwise would be specialists.
And for us, that presents a lot of opportunity, especially as a small business where you gotta wear a lot of hats anyway. but I’m– I can see places where it causes friction because now all of a sudden, well, there’s six people capable of doing this, and if they’re not all communicating, maybe we’re doing duplicate work,
And duplicate work can be good. It gives you something to AB test, but, it can also create a lot of waste, and you over-focus on things. I’m just curious, like in what you’ve seen with other companies, is there a similar level of friction popping up and how do you that kind of stuff?
CHRIS VANNOY
[00:20:16] Like we kind of hinted at earlier with the sort of like architecture ends up looking a lot like the team that built it. You know what I mean? Um, AI is an accelerant, generally speaking, right? It, it will accelerate the good, and it will also accelerate the bad, So a lot of my consulting work is often coming in and fixing the foundations,
So that when you do implement AI, it goes well, Because if you drop it in if you drop it into something where, like you mentioned, like people aren’t talking to each other, or people don’t have clear priorities, or people aren’t working in a shared context, in a shared working environment sometimes,
And you introduce AI into that, and then suddenly you just hit go and, you know, throw gasoline on that particular fire, right? You end up with people stumbling all over each other. You end up with like engineers sometimes that get upset that like their product person is actually pushing in code, and going like directly to production with it and stuff like that, that then they have to go and support,
So it, it takes oftentimes a conscious sort of effort or there’s– either that or there’s like a growing pain that comes with this, right? Because AI adoption in software engineering organizations will accelerate and expose whatever flaws and gaps you have in that system really quickly.
Which is why I think you’ve seen a lot of like even at big, big companies, right? It’s like they start like GitHub and AWS had an outage recently, like that sort of thing, If you don’t invest in the sort of safety systems—test we’re talking about, like suites and feature flags and error logging—it
If you don’t have those basics set up, will just accelerate the need for those things, Because you’re gonna push the production, and if you don’t have those systems in place, like you’re, you’re moving at a, a speed fast enough that like you can’t review everything all the time, right? Like you can, but it took you a whole day ,
And you’ve only got like three people, So it’s like companies have to build systems that let them concentrate more, this is my theory, and I’ve seen it work, concentrate more on, recovery than prevention, in the old human pace world, you could put a lot of time and energy in preventing bugs from ever happening. Now, you and I both know, and the listener, viewer probably knows too,
That’s actually an impossible goal. Like software is bugs. every line of code has a bug in it somewhere that somebody will find eventually, but you would invest in QA and a lot of this upfront sort of process to try and catch every bug before a user’s on that works great when you’re working at human speeds and human scales.
Well, great relatively, It doesn’t work with AI, right? Which is why you’re seeing this like pressure in the system In lots of these cases where like companies end up dropping QA, they end up dropping code review in some cases, Or they just code review it like is just driven by AI, is just doing the code review portion,
And then push everything into production and maybe a human did a, a quick thumbs up, let’s go to market, And then it went to prod and then it broke, this is the way code works,
If you don’t take the time to think through how your code gets to production, how your code lives in this overall ecosystem, you run into these things all the time. And this was true again, even at human speeds, like we were talking about our shared work experience, right? a lot of that system we adopted was because like stuff was on fire all the time,
It’s like we went through a period where customers are a little angry and stuff is broken a lot of the time and like everything else. And it’s like, how are we able to still move quickly and not have that happen, one of our goals we had, and I think companies should adopt even more now, is like we will be able to f-find and fix the error before a customer can contact customer support, right?
Like, because there’s nothing, there’s nothing better in the world than your customer support person saying like, ” Oh, cool. Thanks for reporting that. Could you refresh? We already fixed it,” It’s like if you could get your system so that that’s the goal, that’s what you’re doing, I think in this world especially, you’re gonna be in a better place,
Bugs will inevitably happen, right? So as engineering orgs adopt AI, you will break something, A hundred percent guaranteed you will break something sometime,
And so it is how do you and the company react to that breakage, Because if you as an engineering org don’t actually change anything, you’re just gonna keep breaking stuff. And then eventually each time you do that, you erode trust of the business as a whole. So that eventually what they do is they say, “We need QA.
Like this stuff’s broken all the time. Obviously, you can’t take care of it, so we’re gonna go hire other people to make sure that your stuff is quality,” Or they’re going to replace you, which is the other option, we’ll get people in who won’t break stuff all the time,
And at the same time, this is the weird part, like the same time the company wants you to go fast. This is the other thing I do lots of times is I’ll come into slower or bogged down software engineering orgs and help them realize, ’cause software engineers want to ship software,
They’ve been in this adversarial relationship for so long that they’re so afraid of making a mistake, That everything bogs down. And so introducing these systems allow you to rebuild trust because you’re fixing stuff before the business notices it’s broken in many cases.
Or with feature flags, you like turn it live, take a little peek over it and go like, “Oh, no sh*t, that’s broke.” Turn it back off, So then you rebuild that trust layer with the business as a whole over time so that software engineering can then deploy whenever you want, right? Go get that dopamine hit, ship the production as many times as you want, especially for little stuff.
Like if we’re changing the color on a button, I don’t need to do a weekly release for that, It’s just no. and so it’s helping software engineering orgs realize you want to move fast. The business wants you to move fast too, They just don’t want you breaking stuff.
Which is what a lot of these systems that even at a small size Motion you are implementing are what I think actually unlock speed even more than AI does, right?
Like AI without these, these safety mechanisms, like you’re just going fast and making a mess.
SAM SMITH
[00:26:17] Right. Going fast to what end?
I mean, it really does come down to, those kind of basic principles. AI is the hammer, and if you’re swinging it in the wrong direction or you’re swinging it too much, it’s just, it can cause a lot of problems.
CHRIS VANNOY
[00:26:30] we’re talking a lot in codebase, right? But what you hinted at earlier is it can also cause a lot of problems in product, how do you say no to a customer when what they’re requesting you could literally turn around in, like, a day or a week, Like, it was already difficult to keep product, disciplined in early-stage companies, right? It’s already hard. And that’s when it’s like, ” We’re gonna need to do six weeks of this,” and, you know, it was already hard to get them to not do stuff, But now it’s like, “What? You can just go back to your desk and this’ll be live in an hour and a half,”
How do you manage that?
SAM SMITH
[00:26:59] We could crank this out right now. Um, yeah, I think that’s where I’m trying to find the right ways to say yes on a prolonged timeline.
like not now, not today, not immediately. e-especially if it’s coming from a customer. Um, like one of the, one of the ideal spots I wanna be in is where I’ve shipped the first version of something, and I have two or three ideas of what could come next and where this could go.
But you have to snap the chalk line and say, “This is all we’re building for now.”
It’s really nice for me to have a customer send a feature request or mention something on a call, and it’s one of those three things that I thought was gonna be next. it’s nice to, be right about the guess, having that come from a customer to confirm this is the next thing that you should go and do is a really good spot to be in.
You don’t always have that feedback loop. Sometimes you do have to take the guess. I, I think it comes down to, building the right backlog of things to do, which can be harder now because it’s easier to– You’ve got a tech debt backlog from all the AI slop you’re shipping, and then you’ve got, feature requests piling up.
We’ve gotten in the habit of even using AI to write the tickets for us so that it’s documented and it’s got a plan in it. but at the end of the day, you can’t, or I don’t think you should, tell AI to just prioritize and execute the entire backlog.
I think you still have to sit down as a team and, I don’t think we’re in a place where we should implement sprints.
Things are changing too quickly for us to like, ” This work for two weeks.”
You still have to sit down and say, here’s at least the next thing or two that we’re gonna work on.” and the rest of it can kind of marinate, or you’ve got a separate grooming session to add some details to I think that’s the human in the loop from a product standpoint is just being super intentional about what you’re doing and when.
CHRIS VANNOY
[00:28:51] Yeah. And it’s being mindful… This is another, like, Sigstr lesson, being mindful of what I like to call, surface area, right? just how many different verticals you have compared to the size of team you have to support it, you can… Without having, strong focus from, an organizational, like, product level, you can say yes to a lot of things and end up building a sprawling product that has a whole bunch of stuff that’s, like, lightly used or barely used at all. And that ends up being a, a situation where oftentimes for engineering you have, like, pop-up fires, across the whole expanse of this. Where there’s, like, some forgotten corner of the application that you built, six months ago, right? That you forgot existed, that some customers stumble onto and like, “Hey, this thing isn’t working anymore.”
Oh man, I just… Like, theory, right, is that AI is actually gonna make that phenomenon more frequent because you have less emotional attachment to the code. So I think it is probably even lighter, Correct me if I’m wrong, like, lighter institutional memory, you used to be able to hold a whole codebase in your head more or less after you’d been there for a while, right?
And I think that’s probably harder now. So that when those pop-up fires happen, it’s like, “I… What? I don’t even remember that.” have you run into that at all? And, like, again, this is just a theory
SAM SMITH
[00:30:07] A little bit, yeah. we have a large surface area. and I think partly because of that reason, if, if we didn’t have AI helping us build, we would have a smaller product. We would offer less things. one, because there’s just, you know, it takes longer to build one thing.
CHRIS VANNOY
[00:30:21] Well, also in your, your market, like we mentioned up at the top, that’s rapidly changing underneath you, You’re almost naturally going to have a wide surface area because you’re gonna build things for one reality, and then it’s gonna shift underneath you, so then you got to go build something else, and then you get into the whole, like, sunsetting old applications that nobody ever wants to do.
SAM SMITH
[00:30:40] There’s a whole bunch of other ancillary products that plug into this, right? we’re dealing with college kids on campuses. Sports is a big reason why they’re there, and it’s an important part of their life, but we’re also serving the athletic department themselves. and then it can bleed into serving the rest of academia, right?
The rest of, that student athlete’s college experience. There’s a whole bunch of other ways that that can branch out. And I think without AI, we probably would’ve said no to building some of those other slightly related things. but it, it’s the danger of being able to say stuff like, “Yeah, we can build anything in a week,” and
CHRIS VANNOY
[00:31:16] Yeah.
SAM SMITH
[00:31:16] Put your foot in your mouth.
CHRIS VANNOY
[00:31:18] The upside of that is it lets small businesses, the type of small businesses that you and I tend to like, It makes them look a lot bigger than they used to be able to look. you can get a lot further, which I think is also interesting going back in the theories when if we were bouncing out of this and we were talking to business people instead of engineering people.
I think that has interesting effects on, like, venture funding and, like, how businesses get started I think we’re just starting to see some of the ripple effects of that, with a small team, you can get pretty big before you ever need more than that, right? You ever need to grow past that.
And I think that’s probably raising the floor on a lot of business-related stuff. That’s not our crew necessarily, but, like,
It’s something else is, like, I do more, networking events here in Indianapolis, And keep running into those circles and, keep hearing that same sort of refrain of, small teams can get a lot further using AI tools than they used to
SAM SMITH
[00:32:13] Yeah, I find myself remembering the phrase, “If you want to go fast, go alone, and if you want to go far, go together.” can go farther and faster with fewer people.
CHRIS VANNOY
[00:32:22] It breaks a lot of those pre, yeah, those earlier assumptions
SAM SMITH
[00:32:26] Yeah.
CHRIS VANNOY
[00:32:26] A lot of ways
SAM SMITH
[00:32:27] I did not answer your, your theory question directly, a-about the, the frequency of these pop-up fires.
You’re totally right. There’s a whole bunch of small things that we’ve built that go out of your head and you forget about them, and they’re not important until suddenly they are.
I think you’re right that if you have a larger surface area of stuff that you shipped, that kind of flow will happen more frequently.
But I think you’re also right, when you were talking about earlier the speed of reactiveness to that. They’re gonna happen more frequently, but they’re gonna be less on fire than they would’ve otherwise. one of the, one of the corners that I cut less now is just around documentation.
I’ll push out a big feature and then I need to go and document how that thing gets configured and used, and I’ve got a set of Word documents that I can go reference when someone says, “Hey, this customer needs to use this thing that you shipped,” and I forget, one, how it works, but two, how to also turn it on for someone.
Using AI not just to build and ship the thing, but to document onboarding processes is super helpful. but then also within the code itself, to document how a certain thing works or what a process is, so that when that little pop-up fire happens, whatever AI tool you’re using to go back and relearn how that works and fix it has the context that it needs directly in the codebase to be able to, to reopen that really quickly.
As compared to without that tool, you gotta go read a whole bunch of code and maybe some PRs from six months ago and, that’s way too slow.
CHRIS VANNOY
[00:33:58] Yeah. And that is almost precisely the sort of thing that, like, if you were trying to, like you mentioned, cut corners or get by with less, do more with less, that was documentation. Like, God, no. you and I both did Ruby. the whole idea was like self, self-documenting code. the code itself should be readable.
When a bug would happen, you’d open up a codebase and like, oh man, especially in Ruby apps, you end up jumping through eight different files and folders to trace the whole flow, and then it’ll be in the last place you look, like most things. some other time you and I should nerd out on, like you mentioned, we’ve both done Rails apps for a long time.
A well-formed Rails app, I run into people who’ve never done Ruby before that are using AI tools to build those. Because it turns out Ruby folks, it’s a highly opinionated framework that, like, there’s a right way to do things. It’s flexible enough that you can do whatever the hell you want, but if you follow the, the golden path, there’s a right way to do it.
And Ruby folks talked a lot and did a lot of open source code and explained what their code did a lot and talked a lot about how to write good programs. And it turns out that a lot of AI tools can read all that stuff. I ran into somebody, at a networking event last week that is day-to-day in like TypeScript land, because that’s what AI tools work really well in, that is on the side is building Rails apps,
Because it turns out AI tools work really well with Rails.
SAM SMITH
[00:35:19] That theory crossed my mind, way back in the past, I think. But it’s competing with, with the popula– It’s a popularity contest, you know? There’s so much more other JavaScript stuff to read and replicate. and if you’ve got a community that’s chasing that instead, I think the Rails world is a better structured input for AI to be able to replicate and work with.
But if that’s not where the people are, then it tends to kind of, not fall by the wayside, but it gets less attention.
CHRIS VANNOY
[00:35:53] I think at the end of the day, and again, this is like I used to be a coding bootcamp instructor, and I taught Ruby, and I taught Rails because I always felt it was the easiest thing for a human to learn, right? Because it’s a lot like writing. I think there’s an element of AI that also works well with that.
I know. It’s a theory right now. Um, bef- before we go, we already nerded out a little bit. Let’s just lean into that. What, what, actual tools are you and your team using? Like, what are you finding success with these days?
SAM SMITH
[00:36:21] That was one of my safety nets from, from earlier is a shared tool set. I coded in Vim for over half my life,
And Cursor was the thing that got me out of a text-based IDE. IDE is a strong word for Vim.
And I used Cursor for, I don’t know, over half a year, probably eight months.
Got me into the flow of working with AI tools and writing plans and executing them and s- getting into the phenomenon of, okay, I’m just gonna walk away from the computer now. and then we shifted to, uh, shifted to Claude. So we, we were in this state of like, we knew we, we wanted to use AI to expedite development, and it was kind of like choose your own adventure.
I found that, one of the other engineers who was using Claude, had a little bit better experience, was getting stuff done faster, more comprehensively. Claude Code being terminal-based felt a lot more at home to me. I’ve been using Claude predominantly.
We have shared skills that we use, with that. It’s nice that you can commit them into a repository and you can update them and, everyone who has access to that has access to the same tool set. that has also bled over into other parts of the business too. people using Claude for, you know, using the CoWork app, to do whatever they need to do, is nice, especially from a licensing standpoint.
You can get everybody on the same plan. it kind of wrangles, wrangles the business together in a good way. so Claude’s kind of the, the predominant one for us. we found a lot of good success with Linear. we tried Jira early on.
Linear’s got a great model where, the first 250 tickets are free and you can put as many people on you want it. So they, they get you hooked real quick, especially if you start using, y- whatever AI tool you’re using to write the tickets for you. create a plan, document it, shove it in Linear, and we’ll go look at it in our weekly meeting later to see if we should do it or not.
That workflow, uh, I think has paid off pretty well for us from a
CHRIS VANNOY
[00:38:17] Yeah.
SAM SMITH
[00:38:17] …standpoint.
CHRIS VANNOY
[00:38:18] Very cool. Um, cool. Thanks. Sam, thanks for chatting this morning.
Um,yeah, very much fun. It’s always great catching up with you. And, like, if I haven’t said it before, thanks for Sigstr, by the way. In, in case it isn’t clear, that was a very sort of formative experience in how I think about a lot of this stuff.
Like, I think we did really good work there together, and I… Yeah, email will never die. and I will leave you with one last thing that ties back into the conversation, that I also picked up from Sigstr. My favorite when will this be done thing that I picked up at Sigstr and I still use to this day, that feel free to use, is before the heat death of the universe.
Like, we will get to that eventually, but I’m not gonna give you a date right now. Sometime we’ll get to it.
SAM SMITH
[00:39:03] Ticket on the roadmap.
CHRIS VANNOY
[00:39:04] Ye-yeah, it’s in that same black hole at the bottom of the roadmap. It’s like, we’ll get to it eventually. All right, have a great rest of your day.
SAM SMITH
[00:39:12] Good to see you, Chris.
CHRIS VANNOY
[00:39:13] Good to see you.
That was Sam Smith, who leads product and engineering at Motion Sports Three things stuck with me. When code gets cheap, restraint becomes a skill. Just because you can build it in a week doesn’t mean that you should . The teams that move fast without making a mess invest in safety nets like feature flags and test suites.
So a bad change has a small blast radius. And the goal worth chasing isn’t preventing every bug. That’s impossible. You’re never gonna do it. It’s fixing it before your customer can pick up the phone. If this was useful, follow the Hallway Track wherever you’re listening so the next one shows up. I also write a weekly newsletter called Expedite over at getaxiomatic.com.
It’s more of this kind of thinking on a regular cadence. And if you’re in college athletics, go look up Motion Sports. Sam and his team are doing real work in a corner of the industry that’s rapidly changing and most people aren’t even aware of. So thanks, Sam, and thank you. See you next time.