


LH: LinenMaster’s been around since 1995. Are you still working with that original code?
JM: Definitely. But we’re not rewriting everything from scratch. We use a strangler pattern, refactoring high-impact areas one by one. Our software runs mission-critical operations for hospitals and commercial laundries. We can’t afford downtime, so modernization has to be incremental and data-driven.
LH: What’s your approach to AI across your org?
JM: We run two tracks: a reliable path for the broader team and an exploratory track for innovation. AI won’t solve all our problems, especially not our 30-year-old C++ code, but it can improve processes like summarizing field notes or aiding code generation on modern stacks.
LH: How do you assess candidates who might be using AI in interviews?
JM: I don’t mind if someone uses AI, as long as they can walk me through their thinking. We look for engineers who can explain decisions and collaborate, not just generate code. Curiosity and communication are harder to teach than syntax.
LH: How do you measure engineering success?
JM: Metrics can help, but they’re incomplete. I once saw our best glue engineer ranked lowest by an activity-tracking tool. She wasn’t writing the most code, but she was the key connector between teams. Those soft skills don’t show up in dashboards.
LH: What philosophy guides your leadership?
JM: Extreme Ownership by Jocko Willink. Every situation can be influenced, even if you’re not at fault. That mindset shifts you from blaming to problem-solving, and it’s changed how I lead teams, ship code, and even parent.
LH: Any unexpected uses of AI?
JM: Honestly, I’ve started using AI to reduce decision fatigue. Whether it’s choosing gear or brainstorming, it helps clear the mental clutter so I can focus on what matters, solving the real, ambiguous problems tech leaders face.
LH: Any media that’s changed how you think?
JM: Extreme Ownership helped me rethink leadership. On the fiction side, The Nightingale reminded me how different paths can still come from shared values. And I loved The Three-Body Problem for its first-principles approach to complexity.
Host: Lucas Hendrich, CTO at Forte Group
Guest: Jeff Miller, Head of Technology at Linenmaster; former CTO at Yello and NCSA
Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group.
Welcome to the podcast. Today we're talking with Jeff Miller, Head of Technology at Linenmaster and previously CTO at Yello and NCSA. We're happy to have you here.
Jeff Miller: Happy to be here.
Lucas Hendrich: Everyone likes an origin story. Your roots are in Idaho…
Jeff Miller: Iowa.
Lucas Hendrich: Sorry, Iowa.
Jeff Miller: No worries.
Lucas Hendrich: And if I have this right, you worked in the family business, a hardware store.
Jeff Miller: Yes. When I was about six months old, my parents decided to go the entrepreneurial path and started a hardware store in a small town in Iowa. It's where they both grew up, central to both of their families. It was a great experience growing up. There was the hard-work aspect and the entrepreneurial aspect: you have to keep growing revenue, offer different services, try new ones out, and retire the ones that aren't working. I learned a lot from that. And then I decided to move to the big city.
Lucas Hendrich: What's an example of something you learned there that you apply now as a technology leader?
Jeff Miller: Without trying to be too trite, it's the roll-up-your-sleeves approach. If there was a job to be done and no one around to do it, I'd find my mom or dad doing it. I try to live that today. Whether it's a project that needs doing or a process that needs optimizing, if no one else is around, I roll up my sleeves and get dirty.
Lucas Hendrich: Constant founder mode, or was it more pleasant than that?
Jeff Miller: Definitely more pleasant. They had a stable business. It wasn't a growth business like a tech firm, but it provided a good living for the family and was a staple in the community. So it wasn't always scrounging. But they did work six or seven days a week at times.
Lucas Hendrich: It strikes me that that kind of business isn't so different from a laundry business, for example, which is now your customer.
Jeff Miller: Exactly.
Lucas Hendrich: These are necessities. I don't foresee them being easily replaced by AI, or even by 3D printing or manufacturing.
Jeff Miller: When I started, we did releases on specific release days. When I got there, we asked why we were even doing releases on those days. It's a legacy code base without much unit test coverage, so why release around the first of the month?
Our customers are small and medium-sized businesses, and either way, we don't want to interrupt invoicing or payments. Our software is there to help these businesses grow and thrive. So we put small freeze windows around the first of the month.
I can just imagine my parents around the first of the month, sending out invoices, and some banking or tech problem preventing them from going out. I hope that entrepreneurial background helps me translate that into what I do today.
Lucas Hendrich: They're also good sectors to be in.
Jeff Miller: That's true.
Lucas Hendrich: As long as there's a need for clothing…
Jeff Miller: Or hospitals. It would be a very bad problem if someone went into surgery and there were no sheets for the bed.
Lucas Hendrich: Or dirty sheets.
Jeff Miller: Or dirty sheets — even worse. So it's a critical business, and not likely to be totally transformed by AI.
Lucas Hendrich: Same with hardware, as long as humans want to tinker.
Jeff Miller: Exactly. The beauty of small hardware stores is that, while you might get a better price elsewhere — they do their best to stay competitive — what you really get is guidance. It's mentorship, just like for a junior engineer or someone joining a business for the first time. You bought your first house, you have a leak under the sink, and you don't know what to do. It's really nice to consult with someone there.
Lucas Hendrich: It makes me think: we're all using LLMs for everything — explain this, explain that, bring me up to speed.
Jeff Miller: Yes.
Lucas Hendrich: But I still go to YouTube when I need to see something done. I guess that will eventually be AI-generated too. It's a great example, though. In a hardware store, someone can walk you through it and tell you the inside story. I can see walking junior engineers through similar problems, especially when there's ambiguity about which tool or approach to use.
Jeff Miller: Or interns. We just had our first intern cohort at Linenmaster. You learn a lot in college, but applying it in the real world is slightly different. Having someone walk you through it is a much more enriching experience for both parties.
Lucas Hendrich: I'll jump to something you just made me think of. When I interview engineers, people are obviously incorporating LLMs into everything, including their answers, which can complicate things. I'm trying to find leverage in it, though.
Jeff Miller: Yes.
Lucas Hendrich: I'll even tell candidates exactly what I'm going to ask them in person.
Jeff Miller: Yes.
Lucas Hendrich: "Go ahead and use your best LLM ahead of time, then walk me through it." I think of it like being questioned about a crime. "What did you do last night?" "I went to the store." "What did you buy? Why did you go?" You can easily have an alibi, but you can tell very quickly when someone can't walk you through their approach and the thinking behind it. How are you using AI in screening candidates now, and what are your thoughts?
Jeff Miller: I think interviewing is one of the things we'll have to figure out as an industry, but you're on the right path. A number of years ago, I pivoted to take-home challenges instead of having someone hover over your shoulder watching every line of code you write.
I'd often get asked, "What if someone has somebody else do the work?" It came back to exactly what you're describing. We didn't just review the work and send feedback. The next interview step was a line-by-line walkthrough with a senior engineer to interrogate the decisions. Why did you go this way? Why this language? Why this framework?
This year with the interns, I didn't even feel like making them do extra work. I said, "Bring the code you're most proud of," and we walked through it. What made you proud of it? That showed me their passion. How would you test it, if it didn't have tests? Why did you structure it this way? You don't always get that context from the LLM.
Lucas Hendrich: Can you imagine a world where the answer is, "I structured the prompt this way to get this result"?
Jeff Miller: That's a very fair point, and it's definitely coming. This will be an evolving conversation for sure.
Lucas Hendrich: We'll obviously talk more about AI. But I was curious about something arguably more challenging than incorporating AI: how you deal with legacy code bases.
Jeff Miller: Yes.
Lucas Hendrich: As I understand it, Linenmaster has been around since 1995.
Jeff Miller: Thirty years.
Lucas Hendrich: Is there still code from that era?
Jeff Miller: There's definitely still code from that era.
Lucas Hendrich: Don't worry — we're all friends here.
Jeff Miller: A number of years ago, I was at a B2C lender, hired onto the shiny new project. It was meant to be a from-the-ground-up rebuild: we'd hit the end date, migrate all the customers, and it would be bliss. Of course, that didn't go well.
About a year into my role, there was a need in the most legacy part of the code. When I was pitched to run that team, the message was, "This is making us three-quarters of a billion dollars. We should invest in it." At the time, it was entirely outsourced to an offshore firm. So I embraced it.
The whole point of writing any technology, for me, is the business result. I do try to keep up with the cutting edge, but I'm not the type who says, "Rust just came out, I have to build an app in Rust to see what it's like." I'll learn its characteristics and where we might leverage it. Rust always seems to be the shiny new technology.
Lucas Hendrich: That's what it is right now.
Jeff Miller: Right now, yes.
Lucas Hendrich: We'll see in six months.
Jeff Miller: Exactly. Anyway, my point is that I embraced it, and at Linenmaster it's the same. This software runs the vast majority of our business, so we can't just announce a big rewrite that will take 12 to 24 months. We're on a PE timescale, and that would eat up much of the time we have.
So we're embracing it. We're taking the strangler fig approach: carving out small pieces at a time, isolating the most impactful, most beneficial, or most problematic areas of the code, and addressing them little by little.
Lucas Hendrich: Small chunks. This will sound crazy, but do you remember the show That's Incredible!? Were you old enough for that?
Jeff Miller: I don't remember that show.
Lucas Hendrich: It was one of those shows about incredible feats. One guy actually ate a small airplane.
Jeff Miller: Piece by piece?
Lucas Hendrich: Piece by piece. It's the perfect analogy for these monster code bases with millions of lines of code. How do you digest them? It's very incremental if you're going to do it at all.
Lucas Hendrich: I'm curious: have you started using LLMs to speed that process up — to understand the spaghetti and its intent?
Jeff Miller: We've gone through quite an evolution in the last 12 months, from being pretty constrained and conservative about AI to being as forward-looking as we can.
We essentially have two AI paths. Most of the team is on the tried-and-tested AI tools we can trust. Then a couple of senior engineers and I are on a more exploratory path, trying to identify tools that make processes more efficient and areas we could integrate into the platform itself.
Our software, like a lender's, requires precision. We can't say, "Your invoice was roughly 20 bucks last month." It has to be exact. One challenge I've had in previous roles is getting the organization to realize that while many people view code as deterministic — if this, then that — AI doesn't work that way. You put in an input and get a result that's probabilistically correct, but that doesn't mean it's absolutely correct. We need to balance that.
So we're looking at opportunities like summarizing conversations. Typically there's a business owner or plant manager with people in the field or in the plant — it's a factory-like environment. Someone will say, "I visited Bob's Burgers today. Bob wasn't happy with our service. Here were his complaints." Today, they document those things and meet with the plant manager at the end of the day to go through them. We're looking to automate that by summarizing those conversations. That's one place we can inject AI, along with the code generation process itself.
Believe it or not, AI isn't very good at interpreting our 30-year-old C++ code. It's better with some of the more modern code created over time, like our JavaScript. So we're trying to start where it's easiest and expand into the more difficult areas.
Lucas Hendrich: That seems to be a common theme: it's really good in some languages and not in others. I guess the foundation models had to use whatever data they could. It's unfortunate, because many legacy code bases are like that. We're facing a similar project right now: 30 years old, 3.3 million lines of C++.
Jeff Miller: Exactly. We run into errors week to week, and I tell my customer service team, my CEO, and the executive team that we shouldn't have to deal with these problems. Unfortunately we do, because of tech debt, the legacy code base, whatever you want to call it.
When we hit one of those scenarios, we try to migrate it as much as possible. We can't always, so sometimes we fix it in place. But we're essentially writing our own code for managing database connections, for instance. That's a solved problem.
Lucas Hendrich: Yeah.
Jeff Miller: It makes you bang your head against the wall.
Lucas Hendrich: How do you approach the buy-versus-build equation, especially when you're building something fairly generic but tailored to a specific industry? Do you have a model for that?
Jeff Miller: I tend to always look for buy or open source first. But it has to feel like a unified experience. If we buy something with a freemium-ish model that will eventually steal our customers, that won't work. And if we can't white-label it or make it feel unified, that won't work either.
So we look at commodities. Our industry is very specific: people like things the way they like them. I'm sure that's true in many places. So we look for commodities, like a CRM, and then heavily customize them for our industry and for our onboarding team, which helps clients figure out their specific needs and make the software work for them.
Lucas Hendrich: Here's something interesting. I was fortunate to work for many years at a startup that became PE-backed and went through several transactions, and then I worked directly with PE as an interim CTO adviser. I love the tension here. Niche software with a lot of legacy code is very attractive, because it was written once and could ostensibly run forever.
And yet there's entropy over time. Eventually the ecosystem around you evolves, or things get deprecated, and you have no choice. So what's your filter? This tech debt is an existential risk if we don't attack it; this tech debt we can live with and just shore up. It no longer scales vertically, so maybe we try scaling horizontally. How do you approach those decisions?
Jeff Miller: We try to use data wherever possible. For us, that mostly means adding logging and monitoring in particular areas. And I'd add one thing to your balance: use cases change too. We have an API endpoint that now gets far more volume because the customer's use case changed. We had to take a look at it and refactor it quite a bit.
As for the existential stuff: we were one of the first major players in our industry to move to the cloud. That seems like a big deal for our industry, though we all know it's a ten-year-old decision. But it adds different constraints. We can't just tell customers, "Upgrade your on-prem server," or "Don't upgrade, because we haven't yet." We're now dictated to by AWS and the other cloud providers: "We no longer support this. You have to move."
Lucas Hendrich: Not to mention the cost.
Jeff Miller: Not to mention the cost. We just made one of those decisions. The public version of an API will no longer be supported, but you can pay for advanced support. When we did the cost-benefit analysis, it wasn't worth redirecting our roadmap to rewrite it right now. We'll get to the rewrite in the next 12 months, so we'll pay for one year of support and then migrate off.
It always comes back to an owner's mentality: I can have five people distracted for two months, or I can pay $4,000.
Lucas Hendrich: I sometimes sense people don't realize how much desktop software…
Jeff Miller: Still exists.
Lucas Hendrich: …still exists. Whether it's on-prem or some hybrid cloud model…
Jeff Miller: Yes.
Lucas Hendrich: …there's still some shipped component that someone has to install.
Jeff Miller: For us, on-prem doesn't mean a nice rack server in a data center. It generally means a commercially purchased server in a server closet in a commercial laundry.
Lucas Hendrich: Yes.
Jeff Miller: And these commercial laundries aren't coin-ops, laundromats, or dry cleaners. They're essentially factories, with huge multimillion-dollar tunnel washers, nothing like the washers you'd have at home. A hospital will drop off thousands of pounds of laundry to be laundered and returned on a predictable schedule. As I joked earlier, hospitals can't run out of scrubs. That's what our software is there to help manage.
But one of the highest operational risks of running these businesses is fire: lint builds up, it ignites, and boom, your factory goes up in flames.
Lucas Hendrich: I'm picturing the dust bunnies.
Jeff Miller: Exactly.
Lucas Hendrich: I'm always yelling at my kids to clean the dryer filter.
Jeff Miller: They have to do that on a commercial scale. I've heard one owner joke, "We do our best to keep it clean, but if that ever happens, I'm running to the server room first."
Luckily, the previous owner of our software had the foresight to go with a thin client and a thick back end. So he moved it to the cloud: C++ code wrapped in a .NET wrapper, running in the cloud. It's a unique architecture.
Lucas Hendrich: That makes observability a bit challenging too, right?
Jeff Miller: Exactly. But the point is that the customers' data and all the actual logic are in the cloud, with a thin client on-prem. We're now moving much of that experience to the web and to mobile apps, so they'll have even more separation from that.
Lucas Hendrich: Here's a highly general observation. You start a company around a specific problem people may or may not realize they have. You create a need, get adoption, and generate transactions, volume, and revenue. That's the first thing. And when people talk about data as an asset, it's typically, "Once we hit this milestone, we'll start a roadmap for that. We'll figure it out."
I assume you're dealing with tons of very valuable sensor data. And now, with the ability to train models, that data has a whole different value proposition. Whatever you can share about how you're approaching that.
Jeff Miller: It potentially does. Right now it's very operational. Laundry comes in and gets weighed or counted. Some customers count by scanning barcodes or RFID, but the vast majority work by weight. So we're integrated with floor scales, handheld barcode scanners, and so on, and right now we use that data very operationally.
I don't want to say we have bigger fish to fry, but we need to improve the software before we can get to those second-level problems. I definitely think there's an opportunity in looking at incoming volumes.
Right now we're looking at helping laundries reprioritize orders. Today it's essentially a FIFO queue: first in, first out. If a high-priority order could be reprioritized without a human making that decision, that's probably our next step toward helping them with load management, and potentially staffing. Staffing in these environments is very challenging. If they don't need people during certain hours, let's give workers a break and have them come in when they're really needed. Those are our next steps in optimizing things for owners.
Lucas Hendrich: What about the data architecture behind this legacy application? How are you modernizing it, and what's your thinking?
Jeff Miller: Again, incrementally. We have a relatively modern operational database and a modern data warehouse.
Lucas Hendrich: Do you mind sharing the stack?
Jeff Miller: From a data perspective?
Lucas Hendrich: Yes.
Jeff Miller: MySQL on the operational side and Snowflake for the data warehouse. Snowflake pulls all the plants together. Each plant operates a bit differently, even with the same owner in a region. It's tightly coupled to the staff and the physical environment — whether orders come in on the left or the right and go out on the left, and so on. A lot is specific to individual plants. But if you own multiple plants, you want to report across them, and that's where Snowflake and our analytics tools help.
The operational side, though, was written by someone who wasn't a trained software engineer. He was doing exactly what you described: solving a problem, doing his best to get it done on time, and meeting customer needs. So we do have challenges there.
But rather than throwing the baby out with the bathwater and worrying about data migrations and syncing, we're choosing to work with what we have. One trivial example: an engineer is currently moving images from being stored in a database table to S3 and saving the link instead. Basic stuff, just cleaning it up over time.
Lucas Hendrich: And S3 is relatively inexpensive.
Jeff Miller: It is.
Lucas Hendrich: You're decoupling your storage. That's good.
Jeff Miller: Exactly. Adding indexes, adding relationships — all these things, a little at a time.
Lucas Hendrich: For the analytics user — the owner of several plants — are you designing a semantic layer in Snowflake that works for most of your user base? Or is that a big challenge?
Jeff Miller: It's a bit of a challenge. Some users are quite technical. Others want the data and really respect the need for it, but don't have the staff or skills. We're trying to find that balance.
Our current provider — I won't name them — is just a little too techy for most of these laundries. So we've brought in a new vendor whose tool feels like a spreadsheet. Behind the scenes, it builds the Snowflake queries in the most optimized way, saving us on cost and performance.
Lucas Hendrich: Isn't it funny? The spreadsheet will never go away.
Jeff Miller: I know. It's the most ubiquitous programming language we have.
Lucas Hendrich: I feel that's where ChatGPT is going — becoming ubiquitous.
Jeff Miller: Yes. I heard someone on another of your episodes talk about Copilot in Excel and how it's starting to pull out insights.
Lucas Hendrich: It's not quite there yet.
Jeff Miller: I haven't used it yet, but I think we'll get there.
Lucas Hendrich: Before we started recording, we were talking about your time at NCSA, and about hiring and leading talent. The world of sports — or SEAL teams, for that matter — is all about putting teams together. We mentioned Moneyball and how you pair different attributes. What insight did you get from building that platform about making decisions, finding talent, and putting teams together?
Jeff Miller: NCSA is a Chicago-based company; the name stands for Next College Student Athlete. It matches high school student-athletes with college coaches, and the parties on each side of that transaction have different needs.
The lesson I carry forward is about segmenting customer bases and driving requirements in a way that satisfies both sides, without getting super niche for either one, if that makes sense.
We had a similar experience at Yello, which was a different kind of recruiting: mostly helping Fortune 100 companies and the federal government hire entry-level talent. Some of those organizations needed very highly vetted individuals. Others needed more of a volume approach and would identify the talent they wanted over time, through assessments or individual interviews.
So the platform was very configurable. You could do many different things, which made it very hard to write all the unit tests. That was a big focus while I was there: getting as much covered in an automated way as possible so all our releases were more predictable. The real shift was from thinking in code paths to thinking in user segments or cohorts.
Lucas Hendrich: Interesting. I also think about the matching element. Why a coach chooses someone and why someone chooses a coach is very similar to… we did QA work with Tinder, so there's another paradigm. How do you think we could make engineering hiring more efficient, and how are you starting to incorporate AI into it?
Jeff Miller: That was definitely relevant at Yello. I was there when ChatGPT launched, and my CEO was very tech- and AI-forward, so he wanted to find any way we could use it.
One challenge, both for us and for the organizations we supported, was moving from a deterministic mental model to a probabilistic one. When clients, internal product managers, or even the customer service team thought about engineering, they thought in terms of "if this happens, do that." Very deterministic. AI isn't that way. You put in some inputs…
Lucas Hendrich: Well, generative AI — what most people think of as AI these days.
Jeff Miller: Correct. You put in inputs, you get an output, and it's probabilistically correct. But that doesn't necessarily mean it's good enough for the users.
So we tiptoed around it. We did some deterministic matching, like you mentioned — breaking a resume down into skill sets. That was a buy-versus-build decision too. We went with a partner because they had years of experience training models. They eventually switched from a deterministic model to an AI model, so we got that AI shine through the vendor.
We were also helping candidates prepare. We built interview prep materials, because one of our clients' biggest complaints was that interviewees came in totally unprepared — about the company, about the industry, or about how to answer certain questions. So we tried to help candidates as well.
Lucas Hendrich: This may sound like a crazy question, but when you think about the ideal engineer on your team, how would you weight attributes so a model could detect them? What do you index on?
Jeff Miller: I'll answer with a side story. A number of years ago, I worked for a CEO who came from a sales background, and she wanted very solid engineering metrics. My view on engineering metrics is that whichever one you choose, you'll optimize for a characteristic, and I'm not sure it will be the right one — whether it's lines of code or anything else.
So we brought in a tool that analyzed Git and Jira activity and tried to stack-rank engineers. We ran a trial, and one of the best-known, best engineers on the team landed in the bottom quartile. I looked at the results and said, "We could use this tool, but look at the bottom." Everyone asked, "How is she down there?"
It's because she was the glue player. She was so good at floating between groups, hearing about a challenge on team X and translating it for team Y: "Oh, you need to do this. Talk to this person, because they know that part of the code base really well."
That's what it is. You need a certain amount of technical acumen and curiosity, but it's really about being the connector who pulls people together toward a shared result. So if you're asking me to optimize an AI for that, I'd struggle to answer. It's these intangibles.
Lucas Hendrich: That's great. There's the tangible and the intangible, and there are parts of a team that you can't capture by focusing on individual attributes.
I've mentioned this before: it's part of why I think hiring, and the labor market generally, is so inefficient. We look for a kind of recommended daily allowance. You have to be good at this and this. You don't have to knock it out of the park, but you have to be competent across many things, and most people aren't. Most people excel in one area, and the trade-off is weakness in another.
Jeff Miller: I think AI is smoothing that out for sure. It's helping with the learning curve and growth path for a lot of those tangible skills. That makes me think you need to optimize even more for the intangibles.
I've sometimes been asked at Linenmaster why we chose our new web stack — modern C# on the back end, modern React on the front end. "Why C#? You've never worked in the Microsoft stack." And I said, "That's the team we had." I can learn it. I can translate concepts: I'd do it this way in that language; how would I do it here? I drive those conversations, and obviously I use AI to help me learn too. So I think some of those tangible skills are honestly becoming commoditized.
Lucas Hendrich: I like an analogy about where you want to burn mental calories.
Jeff Miller: Ah, great.
Lucas Hendrich: If you can reserve your mental calories for the really hard stuff and give everything else to AI to spin on, you'll be solving more interesting problems in that ambiguous space where most people are uncomfortable. That's where the intangibles really matter.
To navigate ambiguity, you have to be emotionally attuned, but you also have to distance yourself. There's a book I like, The Scout Mindset, about constantly broadening your picture. And you have to satisfice — make complex trade-offs. I think those skills will come more to the surface.
There are a couple of views. One, which I don't agree with, is Malthusian: eventually AI will get good enough to do the hard cognitive work too. I tend to think there are just so many problems to solve.
Jeff Miller: There are, and the priorities aren't necessarily straightforward.
Lucas Hendrich: Precisely.
Jeff Miller: We had a generative AI conversation in the office yesterday, and my thoughts came back to decision fatigue — how Steve Jobs or Mark Zuckerberg avoided it by wearing the same clothes every day. I see myself doing something similar with generative AI on somewhat more challenging decisions.
I had to buy a projector for an upcoming presentation. Normally I'd spend maybe an hour deciding which one to get. This time, I found the top five I cared about, threw them into an LLM, and took the recommendation. What's the harm? That decision is no longer really a decision for me. Well, a little — I read the reasoning. But eliminating all those lower-level decisions so you can think about the harder problems is probably the right approach.
Lucas Hendrich: And there will be an evolution here. I have an idea for a business, and I literally produced a business plan in under 30 seconds. All the components were there after two or three prompts, and I was pretty happy with it.
Whoever reads that plan might currently wonder whether it was AI-generated. Do I care, if the idea is good? Maybe in the future there won't be a plan at all. It'll be so concise, because an LLM will ingest it first and say, "Just tell me the value proposition. How much money will I make, and what's the probability?"
Jeff Miller: It could get that far.
Lucas Hendrich: Will we eventually cut through all the chaff?
Jeff Miller: It's very possible. I've been experimenting with similar prompts at the executive level. You see clickbait headlines like "Should the CEO be replaced by AI?" So I put questions in and look at how it formulates its thought process. I'm not necessarily taking the results, but I look at how it would reach an answer, how we're thinking about the answer, and whether there are gaps we should address.
Lucas Hendrich: Exactly. It's great at finding blind spots. Wherever I have a point of view, I now vet it, because you're essentially checking it against the probabilities. It's like the chess database: if you play chess online, you can take a 98% move or a 2% move, and you'd better have a damn good reason for the 2% move.
Jeff Miller: It also challenges paradigms you wouldn't expect. When I was coding hands-on every day, I was a big fan of tiny commits and very small pull requests — as much volume as you could manage in small chunks. That's the same thing we're doing now at the architecture and systems design level.
But now I'll run my thought process through an AI model — Cursor, OpenAI, whatever — and it produces more comprehensive answers that consider use cases I hadn't thought of yet. I probably would have after three or four commits, but now my commits, or our chunks, are getting larger. I have to be OK with that, and figure out ways to be OK with it.
Lucas Hendrich: I guess if you're using output from prompts, it's more likely to be readable and commented — it does the things lazy people don't like to do, and it follows a pattern.
Lucas Hendrich: I think those are all positives. I've put out a couple of videos on vibe coding, which I love doing. It's a faster way to get to a prototype. It creates a canvas you can throw things at.
Jeff Miller: Yes.
Lucas Hendrich: We'll probably create a lot of junk and a lot of throwaway stuff. I think that's great. I guess we're burning energy somewhere, though.
Jeff Miller: That's true. Which type of energy, right?
Lucas Hendrich: Which type of energy we're burning.
Jeff Miller: I pooh-poohed metrics a bit earlier, but I definitely think they're important; they're just different in every context. We recently came up with a set of metrics we're going to track. Normally I'd have to write custom software to pull them from different systems and marry them together. I built that app almost entirely with vibe coding — I think I wrote 10 lines of code. It's not production, but it's gathering important metrics for us. Something that might have taken me a month or two before took literally a day.
Lucas Hendrich: And the end result is better decision-making. Again, solving the big problems without spending a lot of time building scaffolding just to reach a conclusion.
Jeff Miller: Exactly. Business moves fast, and these might not be the metrics we want forever. So keeping the investment low is important.
Lucas Hendrich: Imagine waiting for a monthly report.
Jeff Miller: Or a quarterly one. Those timeframes are out the window these days.
Lucas Hendrich: Which is good. So many decisions are based on what — the movement of the planets? Why do we do things on this cadence? Can't we work in smaller increments?
Jeff Miller: Exactly.
Lucas Hendrich: Of course, publicly traded companies wouldn't want to publish a daily shareholder report…
Jeff Miller: I don't know if they would.
Lucas Hendrich: …unless you count their daily stock performance as a kind of report.
Jeff Miller: Then it becomes a signal-to-noise problem.
Lucas Hendrich: Exactly.
Jeff Miller: It can be hard to tell whether something is a momentary blip or a trend you need to follow.
Lucas Hendrich: With all the uncertainty, my personal response — and what I'm trying to implement in our organization — is that, within certain guidelines, we should be engaging with this stuff all the time. There's no harm in it.
I was just speaking with someone for an upcoming episode who used the word "stigma": the sense that if I'm using AI, I'm somehow cheating. In education, obviously — I'm going through it with teenage kids — no one knows how to sort this out yet.
Jeff Miller: Yes.
Lucas Hendrich: It's happening too quickly. I tell them, "If you didn't get it when they put it on the board, absolutely ask ChatGPT to break it down for you."
Jeff Miller: For sure.
Lucas Hendrich: It'll find your learning style.
Jeff Miller: I was just going to say that. In some contexts I'm really good with audio, and in others I just can't keep focus. Hands-on really helps me. Taking concepts from one environment and reapplying them differently in another is so important.
I do think people feel that stigma of cheating. When Rails came on the scene, it felt like cheating that you could go from nothing to a functional website in less than an hour. But the reframing is: now I can do what's important. I don't have to worry about wiring routes to controllers to models; all of that is taken care of. It's about changing the mindset to focus on what matters.
But it's also not black and white. We have an AI policy, and we expect all employees to follow it. In certain contexts, though, let's throw it out the window, experiment, and figure out what we're doing. We're running a hackathon right now.
Lucas Hendrich: That was the other thing I wanted to ask you about.
Jeff Miller: The hackathon is meant to cement our mindset shift from being conservative about AI to being aggressive about it. It's all-in on AI. Every team is either incorporating AI into its feature or leaning heavily on it to build its tools.
We temporarily suspended the AI policy, since none of this is going to production. Let's just see what we can do. Then we'll present the findings to the executive team and the company, and we've committed to productionizing one of the projects. After that, we'll work on bringing it back into alignment with the policy.
Lucas Hendrich: So there's a product focus and some boundaries. I've seen hackathons run different ways. Some are blue-sky, new-product exercises. Others fill a percentage of the roadmap and feed into prioritization. I assume yours is the latter.
Jeff Miller: Yes. Each team has a business stakeholder, and they happen to come from different perspectives, which wasn't intended but worked out really well: one is very revenue-focused, one support-focused, and one more purely product-focused.
Each team also has a technical lead with either high technical competence — to separate the wheat from the chaff and say whether an idea is feasible — or a lot of company context, or both. We're keeping the frame as wide as possible for what they can do, but we're committing to put one of these on the roadmap, even though it's pretty packed.
Lucas Hendrich: Last question, a random one. What's the last book, podcast, show, or anything else you've consumed that fundamentally changed the way you think about something?
Jeff Miller: It's not a new book, but the one I come back to whenever I'm giving guidance — mentoring another tech leader, mentoring people on my team, or advising a friend — is Extreme Ownership by Jocko Willink.
Every example in it comes back to: How is this my fault? "Fault" is a loaded term with lots of negative connotations. The better question is: How can I influence this situation toward the outcome I want? There's so much inadvertent blame out there: "I can't do this because of this person or this roadblock." Well, what can you do to make it happen? That self-reflection and adjustment of my own behavior is so empowering, and I use it in daily life.
And to avoid the news and the noise out there, I've found the BG2 podcast with Brad Gerstner and Bill Gurley to be a nice balance of what's happening in tech and business, without some of the partisan stuff.
Lucas Hendrich: I totally agree. I've cut down my news diet significantly. That's not an indictment of any media outlet; it's just really hard to find objectivity.
Jeff Miller: Yes.
Lucas Hendrich: It's probably more about incentives than anything else.
Jeff Miller: That's right.
Lucas Hendrich: I get a lot through podcasts, because it's a more natural, observational, among-friends way of discussing things. At best, it's entertaining too.
Lucas Hendrich: How about a work of fiction? Again, it could be any medium.
Jeff Miller: Interesting. The one that comes to mind is The Nightingale. It's a really impactful story about two sisters who go down different paths. It reminds me of my relationship with my brothers: we've gone different ways but share some of the same core values.
Lucas Hendrich: That's wonderful. I'll share an author I discovered, though I feel late to the party. I'm not a big science fiction reader, but of all fiction, especially where it overlaps with technology, I like science fiction that's plausible from first principles — the laws of physics — not the Star Wars world where you can go into space and not float. I found a writer who goes by the name qntm.
Jeff Miller: Interesting.
Lucas Hendrich: I'm reading a collection of stories, and there's a novel coming out soon that I'll read as well.
Jeff Miller: Nice. The Three-Body Problem is the one that stands out for me there, and I was definitely late to that party. What I took away was problem-solving under different rules — how they have to navigate those three bodies. I have different rules to play by now, so how do I think about the problems?
Lucas Hendrich: It's interesting, because that book changes the first principles, and you have to reframe all those concepts.
I'll leave one more. Have you heard of Ted Chiang?
Jeff Miller: Yes.
Lucas Hendrich: In his collection Exhalation, there's a story called "The Lifecycle of Software Objects."
Jeff Miller: OK.
Lucas Hendrich: It's about AI, but AI embodied and brought into the natural world through these creatures — imagine furry stuffed animals with roughly a toddler's intelligence. It's wonderful, insightful, and heartbreaking. The main character is a former zookeeper, because who better to work with these AIs than someone used to training animals?
Jeff Miller: That's really interesting. That book is definitely on my Goodreads list — I think it got there from a Tim Ferriss recommendation at some point. I'll move it up the queue.
Lucas Hendrich: That story in particular. From the title, you expect something else, and it's just wonderful and heartbreaking.
Lucas Hendrich: Jeff, it's been a real pleasure. Thanks for coming by.
That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.