Lessons Learned: Extending Terms, Tailoring Projects, and Creating Support Systems to Turn Interns into High-Impact Team Members
Let me tell you a secret: I was a terrible intern.
I spent half my time wandering the halls of a government office, looking for something—anything—to do. My managers didn’t seem to know what to do with me, and honestly, I didn’t know what to do with myself. My degree was in Engineering Physics, and I knew absolutely nothing about roads and public transportation. I thought my lack of direction was just a symptom of working in a large, bureaucratic institution.
But here’s the thing: my internship wasn’t an indicator of the success I’d have later in my career. A decade later, I became a Technical Director. And along the way, I learned something crucial about internships: they’re not just about the intern. They’re about the environment you create for them.
A few years after that aimless summer, I landed my first real software development gig. I was thrilled. For the first time, I had ownership over a project—a real-time inventory management system for new builds and condos. I was the only developer on it, and that freedom allowed me to grow into the software engineer I am today.
But it wasn’t until my next role, at a software consulting company, that I truly understood the potential of interns. This time, I wasn’t the intern—I was the experienced developer watching them. And what I saw completely changed my perspective.
These interns were nothing like I had been. They were eager, hardworking, and showed an attitude toward their work that I hadn’t seen before. They were actively seeking opportunities to learn, contribute, and grow. It was clear: the difference wasn’t just about them— that played a big role — but it was also about the environment we created for them.
Fast forward to today. I’m now part of a company that has turned many of its early co-ops into team leads. I’ve seen firsthand how a great internship program can transform not just the interns, but the entire organization.
But getting here wasn’t accidental. It took intention, structure, and a lot of lessons learned. Here’s how I’ve approached building a program that turns interns into future leaders—and why it’s one of the best investments you can make for your team.
Flying While Building is a reader-supported publication. Want to learn more about building successful internship programs? Subscribe for weekly tips and strategies!
What I Do Differently Now: Lessons Learned from Working with Interns
Here’s the framework I developed to turn our co-op program into a talent pipeline:
1. The Turning Point: From Temporary Help to Future Leaders
I started by extending our co-op terms from four months to eight or even twelve months. Four months is not long enough for a new coop or an experience coop to learn business context, get updated with HR policies, understand the project(s) they are put in, and being to deliver. It’s simply too short.
I had an coop student join us, and we had him first join a web application project with a team, but overtime, we spoke and I found over the months, that
2. Match Projects to Experience Levels
Not all co-ops are created equal. Some are first-timers who need a lot of hand-holding, while others have previous experience and are ready to tackle complex problems.
I learned this the hard way. Early on, I threw a first-time co-op into a vague, poorly defined project. He struggled, and I could tell he felt lost. It was a wake-up call.
Now, I tailor projects to their experience level. For first-timers, I assign well-defined tasks with clear mentorship. For more experienced co-ops, I give them complex projects that challenge them to grow.
Pro tip: During interviews, ask co-ops to walk you through a past project. Pay attention to how they describe challenges and solutions. Did they ask for help when they needed it? Did they take initiative? These are the traits that matter.
3. Build a Support System That Works
Co-ops need support, but it’s easy to underestimate how much. At one point, I saw co-ops flounder because they didn’t have access to centralized documentation or clear onboarding processes. It was a mess.
So, I made changes. I set up centralized documentation, created a clear onboarding process, and assigned dedicated mentors to each co-op. I also made it clear that it’s okay to ask for help.
I’ll never forget one co-op who helped rebuild our mono repo after eight months of growing technical context. He wouldn’t have been able to do that without the right support structures in place.
Pro tip: Reinforce the message that it’s okay to ask for help. Say something like, “If you’re stuck, don’t sit there spinning your wheels. Ask for help. We’d rather you ask a ‘stupid’ question than make a costly mistake.”
4. Treat Them Like Future Leaders
When we shifted to longer terms and better support, something amazing happened. Co-ops started taking ownership of projects, mentoring others, and even suggesting improvements to our processes.
One co-op went from basic PR reviews to leading major technical initiatives. By the end of his term, he had mastered our codebase, mentored new co-ops, and converted to a full-time role.
The key was giving them time to develop deep context while providing clear growth opportunities.
Why This Approach Works
Longer Terms Accelerate GrowthTechnical skills grow exponentially, not linearly. What takes three months to learn in the first term takes three weeks in the second. By extending terms, you capture the high-growth period after the initial learning curve.
Psychological Safety Unlocks PotentialWhen co-ops know they have time to grow, they take more initiative. Instead of playing it safe with small fixes, they tackle complex problems that drive real value.
They Internalize Your CultureLonger terms mean co-ops understand not just what to do, but why you do it that way. This creates future leaders who can maintain and evolve your technical culture.
The Payoff
When you treat co-ops like future leaders—not temporary help—you create a virtuous cycle of growth. They master your systems, innovate on your processes, and become ambassadors for your company’s culture. And when they join your team full-time, they hit the ground running, saving you time, money, and headaches.
Your Turn
Don’t wait for the next hiring cycle to make these changes. Start today by reevaluating one aspect of your co-op program. Whether it’s extending a term, assigning a mentor, or improving onboarding, every small step moves you closer to a program that delivers real value—for your co-ops and your company.
From Casual Internships to Strategic Growth: How to Build a Co-op Program That Cultivates Future Leaders.
A lot of companies treat co-op internship programs like cheap labour, and discounted researchers. If you are running an engineering organization, consider this: if you’re not investing in their growth, you’re not just wasting their potential—you’re sabotaging your own internship talent pipeline. Why waste potential, and why not spend a little time to set them up for success and a great long-term reward?
the future leaders?
Having some requirements and some guidelines that follow should help with setting up a solid co-op internship pipeline. And unlike outsourcing or rushing to hire full-time employees, this won’t cost you months of lost productivity and cultural misalignment. Instead, use this dead-simple framework for maximizing the value of your co-op program.
Why Co-ops Should Be Treated Like Future Leaders, Not Temporary Help
When we shifted to longer terms and better support, one co-op went from basic PR reviews to leading major technical initiatives. They mastered our codebase, mentored others, and eventually converted to a full-time role. The key was giving them time to develop deep context while providing clear technical internship support.
But why does this framework actually work? Here are the three reasons this approach delivers consistent results:
1. How Longer Terms Accelerate Co-op Learning and Growth
Technical skills grow exponentially, not linearly. What takes 3 months to learn in the first term takes 3 weeks in the second. By extending terms, you capture the high-growth period after the initial learning curve. For example, I had a co-op who struggled with Git in the first month but was teaching others how to use it by the sixth month — one of the clear advantages of a well-structured co-op internship program.
2. Why Psychological Safety is Key to Co-op Success
When co-ops know they have time to grow, they take more initiative. Instead of playing it safe with small fixes, they tackle complex problems that drive real value. The safety to fail and learn transforms them from task-takers to problem-solvers. I’ve seen co-ops who were afraid to ask questions at first but became confident problem-solvers by the end of their term. This is what great mentoring for co-op students enables.
3. How Longer Terms Help Co-ops Internalize Your Company Culture
Longer terms mean co-ops internalize your engineering culture and practices. They understand not just what to do, but why you do it that way. This creates future leaders who can maintain and evolve your technical culture. For example, I had a co-op who started by following our coding standards but ended up suggesting improvements that we adopted company-wide — a clear payoff of investing in internship growth.
Subscribe to Flying While Building
Building software that flies while solving problems we didn’t even know we had.
How to Build a High-Impact Co-op Program That Actually Works
Here’s how to transform your co-op program from a resource drain to a strategic internship talent pipeline.
Why Four Months Isn’t Enough: The Case for Longer Co-op Terms
Four months is barely enough time for a student to learn your codebase. I learned this the hard way. At my first company, we hired co-ops for four-month terms, and by the time they were finally getting up to speed, they were gone. It was frustrating for everyone involved.
What to do instead: Aim for 8-12 month placements that allow co-ops to truly contribute. Give them time to grow from “what does this do?” to “here’s how we can improve this.” For example, I had a co-op who joined us for a six-month term. The first month was spent learning the ropes, but by month three, she was contributing to the project. By month six, she was owning a significant portion of the work. And guess what? We hired her full-time.
Pro tip: Consider bringing successful co-ops back for multiple terms. This allows them to build on their knowledge and become even more valuable.
How to Assign Co-ops Based on Their Experience Level
Not all co-ops are created equal. Some are first-timers who need a lot of hand-holding, while others have previous work terms under their belt and are ready to tackle more complex projects. The biggest mistake? Throwing inexperienced co-ops into unclear projects without support.
Here’s what I do now: I look for co-ops with previous work experience for complex projects. For first-timers, I place them on well-defined tasks with clear mentorship. For example, I had a co-op who was interested in AI, so I put her on a project building a machine learning model. She struggled at first, but with the right support, she ended up owning the project — an ideal case of mentoring co-op students into contributors.
Pro tip: During the hiring process, ask co-ops to walk you through a project they’ve worked on. Pay attention to how they describe the challenges they faced and how they overcame them. Did they ask for help when they needed it? Did they take initiative to find solutions? These are the traits that matter.
The Support Systems Every Co-op Program Needs to Succeed
Co-ops need support, but it’s easy to underestimate how much. At one company, I saw co-ops flounder because they didn’t have access to centralized documentation or clear onboarding processes. It was a mess.
What to do instead: Set up centralized documentation and clear onboarding processes. Assign dedicated mentors who can provide regular feedback. Build psychological safety so co-ops feel comfortable asking questions. For example, I had a co-op who helped rebuild our mono repo after 8 months of growing technical context. He wouldn’t have been able to do that without the right internship support structures in place.
Pro tip: Reinforce the message that it’s okay to ask for help. Say something like, “If you’re stuck, don’t sit there spinning your wheels. Ask for help. We’d rather you ask a ‘stupid’ question than make a costly mistake.”
The Payoff:
When you treat co-ops like future leaders—not temporary help—you create a virtuous cycle of growth. They master your systems, innovate on your processes, and become ambassadors for your company’s culture. And when they join your team full-time, they hit the ground running, saving you time, money, and headaches — the real value of a well-run co-op internship program.
Now it’s your turn: Don’t wait for the next hiring cycle to make these changes. Start today by reevaluating one aspect of your co-op program. Whether it’s extending a term, assigning a mentor, or improving onboarding, every small step moves you closer to a program that delivers real value—for your co-ops and your company.
The future of your internship talent pipeline depends on it
Some learned truths about balancing startup job risk, startup equity rewards, and timing in early-stage startup careers
As a Technical Director who’s navigated both startups and enterprise, I’ve seen how startup decisions get made from both sides of the table. When my friend called about his offer, I knew exactly which startup job compensation questions weren’t being asked.
A friend recently called me about joining an early-stage startup. He’d been offered significant equity, a salary cut, and the chance to build something from scratch. The conversation that followed revealed hard truths about startup decisions that rarely make it into the glossy recruitment pitches.
Understanding Startup Compensation: Beyond the Equity Number
Stock options aren’t extra compensation — they’re lottery tickets. When a startup offers you “$100k in equity,” that number means nothing until you understand three crucial details: your exercise price, vesting schedule, and liquidation opportunities. Your 1% could be worth millions or nothing.
When evaluating startup offers, here’s what matters: Can you live on the base salary alone? At my friend’s startup, they offered a $35k pay cut with substantial equity. But you can’t pay rent with stock options. Unless you have significant savings or another income source, you need a base salary that covers your living expenses — plus enough to exercise those options when the time comes.
Everyone knows most early-stage startups fail. But that’s not the real risk. The real risk is a life-timing mismatch — joining a startup just when your personal life needs stability. My friend was planning for marriage, and kids, and dealing with housing issues. A startup’s demands don’t care about your milestones.
Take a hard look at your next 2-3 years. Planning a family? Buying a house? Caring for parents? The startup’s “it’s a marathon, not a sprint” motto sounds great until you’re the only person who can fix a production issue during your child’s birth.
You need a personal exit strategy for startup roles before day one. That means knowing:
How long you can afford to stay if things go sideways
What percentage of your options you’ll exercise if you leave early
Your minimum runway for finding the next opportunity
How much risk you can actually absorb
The startup might exit in 2 years or 10 years. But your life won’t wait. Have clear triggers for when you’ll walk away, and know exactly what you’ll do with your vested options.
Five Essential Questions for Startup Decision-Making
After hours of discussion, we developed a simple startup compensation framework for making the decision:
Can you live comfortably on the base salary alone?
Are you willing to lose 100% of any money you put into stock options?
Does your life stage allow for high work uncertainty?
Do you believe in the founders’ capabilities (not just their vision)?
Would the experience be valuable even if the company fails?
You need “yes” answers to all five questions. One “no” should make you seriously reconsider.
The startup world loves to talk about “changing the world” and “massive opportunities.” But as we’ve seen, the reality demands a more nuanced analysis. Your decision isn’t just about equity versus salary – it’s about aligning career opportunities with life stage, risk tolerance, and personal goals.
Before you make your choice, write down your answers to our five framework questions. Be brutally honest, especially about living on the base salary and your life stage compatibility. If you’re getting anything less than five clear “yes” answers, take time to understand why. The right startup opportunity at the wrong time is still the wrong opportunity.
Remember: You’re not just evaluating an offer — you’re designing the next phase of your career. Make that design intentional, with clear triggers for both staying and leaving. The best startup decisions come from understanding exactly what you’re trading and why you’re making the trade.
What kind of unique trade-offs have you made in your lines of work? I’d love to hear your stories of balancing opportunity with life stage timing.
Note: Names and specific details have been changed to protect privacy, but the insights remain unchanged.
Why Software Projects Often Miss Their Deadlines (And How to Fix It)
After a decade of building everything from challenger bank mobile apps to nuclear industry systems, I’ve watched countless software projects fail. The failures often share common patterns — patterns that, once recognized, can be avoided in modern agile project management.
The Requirements Trap: When Unclear Vision Meets Technical Debt
Picture a development team hunched over their keyboards, furiously coding what they think the client wants. Three months later, they proudly present their work, only to hear, “That’s not what we meant at all.” It feels like a balloon pops. And then begins the thing that you really don’t want, a loss of confidence and trust. I’ve seen this scene play out dozens of times, and it always stems from the same root cause: unclear requirements and a lack of frequent communication.
I was part of a team that was building a logistics application and was highlighting that there was a prevailing feeling amongst the developers and the product managers that the initial scope of what we were building may not have been really what the client wanted. The initial scope was to build a simple tracking system, but without clearly defined boundaries, the requirements kept shifting. One week the client wanted real-time GPS integration, the next week they needed complex routing algorithms, and the week after that they wanted AI-powered predictions. The development team kept pivoting, accumulating technical debt with each change, until the codebase became an unmaintainable mess. The project ultimately failed, not because of technical limitations, but because no one had clearly defined what “done” looked like.
Breaking Down the Wall Between Developers and Problems
Throughout my years as a developer, I’ve seen firsthand how weekly demos in software development transform projects. During these sessions, clients would point to specific features on the screen and say things like “That workflow needs an extra confirmation step” or “Can we make this button more prominent for our power users?” These weren’t abstract requirements—they were immediate, concrete improvements we could implement right away.
In a medical records application, our weekly demos revealed that nurses needed a different patient history view than what we’d originally designed. During another project for a retail tire company, the client spotted that customers needed to compare tire specs side-by-side—a feature that wasn’t in the original requirements. Instead of waiting months to discover these mismatches, we caught them within the first few weeks. These regular check-ins created a rhythm: demo, gather feedback, implement changes, repeat. No tickets languishing in a backlog, no requirements lost in translation—just direct feedback leading to immediate improvements.
The key is keeping these demos focused on working software and real user scenarios. When clients can click through actual features and test real workflows, they spot issues and opportunities that would never emerge from a written specification — a common root cause in software project failure.
Time Estimates: The Art of Realistic Planning
“How long will it take?” It’s the question every client asks and the one most project managers get wrong. The mistake? Providing estimates without understanding how their team actually operates. I’ve found two effective approaches to tackle this challenge, depending on the project’s scope and stage.
For initial planning and large feature sets, I use what I call the “T-shirt method.” An experienced developer can quickly size features using small, medium, large, and extra-large classifications. Each size corresponds to story points in a Fibonacci sequence (0-99), giving stakeholders a realistic ballpark without getting bogged down in specifics. A Small might represent a simple form update (2-3 points), while an Extra Large could be a complex integration requiring multiple sprints (40-99 points). This approach provides enough accuracy for budgeting and roadmap planning while building in natural buffers for complexity.
For detailed estimates or smaller projects, nothing beats getting the whole development team involved. Recently, when planning a critical system update, we gathered our developers for a planning session. Each team member brought unique insights: the frontend developer spotted integration challenges, while the database expert identified potential performance bottlenecks. Their combined expertise produced an estimate that wasn’t just a number—it was a realistic assessment based on real-world constraints and opportunities.
This method helps eliminate the dreaded “we’re going to miss the deadline” conversations and replaces them with productive discussions about priorities and trade-offs — an essential part of agile software development.
But the only way to avoid that conversation is to always communicate and make sure your main stakeholder is aware of the progress and issues coming around the corner. The best way is through weekly demos and consistent agile communication practices.
The Agile Reality: Embracing Uncertainty
The most successful projects I’ve led didn’t have end dates — they had milestones. This is a key mindset shift in agile project management.
A software project is fundamentally a project involving the opinions and decisions of many humans. From decisions on what the best language and coding patterns are to how a project is run and how a product is defined. There are a myriad of factors that can affect the product. It’s difficult to predict precisely when a product will “finish.”
The act of taking it week by week, measuring progress (velocity), and doing proper roadmap planning and estimating will give you a more accurate picture of how the story will play out — and prevent software project failures caused by poor planning.
The best way?
Put people first.
Trust your developers, connect them directly with problems, and measure success by actual impact rather than arbitrary deadlines. In software development, the shortest path between two points is rarely a straight line — but it’s always through clear communication and trust.
Ten years ago, I stood in front of a room full of agricultural business stakeholders, proudly presenting an elaborate technical framework that absolutely nobody cared about. That moment changed everything I thought I knew about successful software development.
One of the most challenging lessons I’ve learned in my software engineering career centers around developer perfectionism—that tendency to set down principles as incontrovertibly true. Even today, as a technical leader where people look to me for guidance and assurance, I still wrestle with this challenge.
Blueprints vs. Buildings: A Critical Distinction
What I’ve discovered is surprising: most software development projects don’t actually require rigid, dogmatic principles to be successful. This might sound counterintuitive, but the criteria for success in many projects isn’t necessarily rooted in having a high-quality codebase.
Just because you wrote a really excellent codebase does not mean you’re left with good software. While code quality and philosophical consistency are crucial elements of maintaining excellent code, they don’t automatically translate to a high-quality software product.
This distinction between code quality and software usability is crucial.
A codebase is merely the infrastructure that creates an application – it’s like the blueprint, not the building itself. At the end of the day, what matters to users is the application, not the codebase. The codebase facilitates the application but isn’t the application itself. This is a stumbling block that many developers, including myself, have tripped over.
A Humbling Leadership Lesson
Let me share a story…
I had just started my first role as a lead developer. I launched into an extensive discussion about technical choices: Tailwind vs. Bootstrap, React vs. Angular… all from the mindset of a developer chasing perfection.
This project showed me how wrong that assumption was. While I was deep in the weeds of technical frameworks and paradigms, my audience included project managers and business stakeholders who cared about creating a usable product. My technical focus created a disconnect between what I was saying and what was actually needed.
The situation was further complicated because we were collaborating with the client’s existing development team. In laying out our company’s fundamental principles for how the software should be built, we failed to consider their perspective and preferences. This revealed another critical flaw in dogmatic thinking: the assumption that your way is the correct way.
Looking back, I realise I was focused on developer perfectionism—assuming that great code naturally results in great software. But software usability and end-user value weren’t part of that narrative.
Engineering Is the Art of Compromise
What I’ve come to understand is that software development leadership is fundamentally about compromise—in time, in code quality, and in philosophy.
Engineering is inherently a discipline of compromise. If you tried to create the most perfect software product in the world, you’d probably never finish it.
This has become one of the most important lessons of my career: in software development, there’s no room for dogmatism. Principles, philosophy, and rigid rules must all remain flexible and negotiable. Our job as software developers isn’t to create the perfect codebase – it’s to create the best possible software application within our real-world constraints.
Our job isn’t to create the perfect codebase—it’s to deliver good software that works in the real world. That means setting aside perfectionism in favour of progress.
Leading with Context, Not Dogma
Today, when I mentor new technical leads, I share this fundamental truth: our ultimate measure of success isn’t the elegance of our code, but the value we deliver to users. This doesn’t mean abandoning technical excellence – it means pursuing it thoughtfully, within context.
First, start every project by understanding what success means to your stakeholders, not just your development team. Then, maintain open dialogue about technical tradeoffs, explaining them in terms of business impact rather than philosophical purity. Finally, approach technical decisions with flexibility, asking “What serves our users best?” rather than “What’s technically perfect?”
A decade after that humbling presentation, I’ve learned that true technical leadership isn’t about enforcing rigid principles – it’s about making informed compromises that balance code quality with real-world constraints. When we let go of dogmatism, we free ourselves to build software that doesn’t just satisfy our engineering principles, but actually solves problems for the people who use it.
Today, I teach new technical leads:
Define what success means for stakeholders
Speak in terms of business value, not frameworks
Ask, “What serves our users best?” rather than “What’s technically ideal?”
This is how we escape developer perfectionism and build software that matters.
What was the humbling experience that changed how you approach technical leadership? How did it reshape your perspective on balancing technical ideals with practical needs?
Why Software Projects Often Miss Their Deadlines (And How to Fix It)
After a decade of building everything from challenger bank mobile apps to nuclear industry systems, I’ve watched countless software projects fail. The failures often share common patterns — patterns that, once recognized, can be avoided in modern agile project management.
The Requirements Trap: When Unclear Vision Meets Technical Debt
Picture a development team hunched over their keyboards, furiously coding what they think the client wants. Three months later, they proudly present their work, only to hear, “That’s not what we meant at all.” It feels like a balloon pops. And then begins the thing that you really don’t want, a loss of confidence and trust. I’ve seen this scene play out dozens of times, and it always stems from the same root cause: unclear requirements and a lack of frequent communication.
I was part of a team that was building a logistics application and was highlighting that there was a prevailing feeling amongst the developers and the product managers that the initial scope of what we were building may not have been really what the client wanted. The initial scope was to build a simple tracking system, but without clearly defined boundaries, the requirements kept shifting. One week the client wanted real-time GPS integration, the next week they needed complex routing algorithms, and the week after that they wanted AI-powered predictions. The development team kept pivoting, accumulating technical debt with each change, until the codebase became an unmaintainable mess. The project ultimately failed, not because of technical limitations, but because no one had clearly defined what “done” looked like.
Breaking Down the Wall Between Developers and Problems
Throughout my years as a developer, I’ve seen firsthand how weekly demos in software development transform projects. During these sessions, clients would point to specific features on the screen and say things like “That workflow needs an extra confirmation step” or “Can we make this button more prominent for our power users?” These weren’t abstract requirements—they were immediate, concrete improvements we could implement right away.
In a medical records application, our weekly demos revealed that nurses needed a different patient history view than what we’d originally designed. During another project for a retail tire company, the client spotted that customers needed to compare tire specs side-by-side—a feature that wasn’t in the original requirements. Instead of waiting months to discover these mismatches, we caught them within the first few weeks. These regular check-ins created a rhythm: demo, gather feedback, implement changes, repeat. No tickets languishing in a backlog, no requirements lost in translation—just direct feedback leading to immediate improvements.
The key is keeping these demos focused on working software and real user scenarios. When clients can click through actual features and test real workflows, they spot issues and opportunities that would never emerge from a written specification — a common root cause in software project failure.
Time Estimates: The Art of Realistic Planning
“How long will it take?” It’s the question every client asks and the one most project managers get wrong. The mistake? Providing estimates without understanding how their team actually operates. I’ve found two effective approaches to tackle this challenge, depending on the project’s scope and stage.
For initial planning and large feature sets, I use what I call the “T-shirt method.” An experienced developer can quickly size features using small, medium, large, and extra-large classifications. Each size corresponds to story points in a Fibonacci sequence (0-99), giving stakeholders a realistic ballpark without getting bogged down in specifics. A Small might represent a simple form update (2-3 points), while an Extra Large could be a complex integration requiring multiple sprints (40-99 points). This approach provides enough accuracy for budgeting and roadmap planning while building in natural buffers for complexity.
For detailed estimates or smaller projects, nothing beats getting the whole development team involved. Recently, when planning a critical system update, we gathered our developers for a planning session. Each team member brought unique insights: the frontend developer spotted integration challenges, while the database expert identified potential performance bottlenecks. Their combined expertise produced an estimate that wasn’t just a number—it was a realistic assessment based on real-world constraints and opportunities.
This method helps eliminate the dreaded “we’re going to miss the deadline” conversations and replaces them with productive discussions about priorities and trade-offs — an essential part of agile software development.
But the only way to avoid that conversation is to always communicate and make sure your main stakeholder is aware of the progress and issues coming around the corner. The best way is through weekly demos and consistent agile communication practices.
The Agile Reality: Embracing Uncertainty
The most successful projects I’ve led didn’t have end dates — they had milestones. This is a key mindset shift in agile project management.
A software project is fundamentally a project involving the opinions and decisions of many humans. From decisions on what the best language and coding patterns are to how a project is run and how a product is defined. There are a myriad of factors that can affect the product. It’s difficult to predict precisely when a product will “finish.”
The act of taking it week by week, measuring progress (velocity), and doing proper roadmap planning and estimating will give you a more accurate picture of how the story will play out — and prevent software project failures caused by poor planning.
The best way?
Put people first.
Trust your developers, connect them directly with problems, and measure success by actual impact rather than arbitrary deadlines. In software development, the shortest path between two points is rarely a straight line — but it’s always through clear communication and trust.
A business case/system design in a rare instance where I think AI is being used correctly.
It’s 1am, halfway through a 12-hour road trip, and you’re starving. You see those sweet Golden Arches and think, “I could go for a Big Mac right now.” You drive up.
“May I take your order?”
You respond instinctively, not realising—you just spoke to an AI.
This kind of problem really excites me. I see a clear successful use case for AI and related models. The problem is going to be to understand if this is worth doing. I’ll explain how McDonalds with drive-thrus work, and how they can benefit from this correct use of AI and speech to text models, how to fix it, and what to expect next.
But first, let’s talk about the why.
WHY
Why would a fast food chain look at replacing at least 1 full time employee at each restaurant across the country?
This amounts to a total expense of ~$217M CAD/year on salary alone for all Owned and Franchisee Operated McDonalds.
The benefit to the owner is obvious.
It’s basic mathematics.
McDonald’s Corporate Strategy
What was Corporate McDonald’s incentive to consider AI in drive-thrus? Based on McDonald’s own Business Model deck for investors: their main revenue comes from Rent and Royalties – rent paid by franchisee owners for properties and royalties based on sales percentage.
But an AI Drive Thru Attendant doesn’t generate more sales. You can’t have more people drive through McDonald’s just because you added AI Drive Thru Attendant. Only one car fits in that lane.
The AI Drive Thru Attendant serves a different purpose:
Eliminating employee training costs for Corporate McDonald’s
Standardizing quality for a more consistent value proposition
If McDonald’s can deliver the same fries, burger, and taste worldwide – from Canada to Saudi Arabia to India to Japan – it also aims to deliver the same experience. The most difficult consistency challenge is human-human interaction. McDonald’s has a specific image for each employee it wishes to maintain so guests know what to expect.
The McDonald’s app and Kiosk represent the first step toward a consistent universal experience. I can use the same familiar Kiosk in Spain as in Canada. Why not the same drive-thru experience?
The Guest Experience Factor
Why use a drive-thru at all? Today, you can park in a designated spot, order through the mobile app, and wait without risking drive-thru accidents.
My assumption: people still prefer talking to order, don’t like using apps, or want to maintain movement momentum. I have no data showing if drive-thru usage decreased since app introduction, but I still use the drive-thru when I want to keep moving. It feels effortful to restart after parking.
So drive-thrus remain valid as long as people have vehicles, places to go, and want food quickly. The convenience factor is unparrallelled.
But what if you could:
Speak to the box in any language?
Just speak, and it recognizes exactly who you are?
Reduce harassment and verbal abuse risk to employees and guest?
An AI Drive Thru Attendant can deliver all this.
If it works properly, guests can speak any language, enjoy voice-activated authentication, and get their order 100% correctly every time, with consistent voice experience at every McDonald’s. For corporate, this means quality assurance perfection, with a lower risk of employee harassment and training. For franchisees, it eliminates payroll expenses and increases profits.
Building the AI-Driven Drive-Thru
What’s needed to build this system?
Our goal: replace all attendant actions with an AI attendant performing a one-to-one match.
The AI attendant must:
Take orders
Respond to guests
Know current menu, promotions, and upselling techniques
Send orders to Kitchen and Payment Processing
Let’s make a generalized assumption about the problem scenario. I’m not an expert on McDonald’s internal processes, but here’s my take on a typical drive-thru interaction:
Guest enters property and approaches drive-thru
Guest enters drive-thru queue
Guest approaches voice box
Attendant begins Order Transaction
“May I take your order?” prompt delivered
Customer responds
Interaction continues with:
Initial Order
Order Clarification
Promotion Prompting
Customization Requests
Order Confirmation
Upsizing Offers
Price Confirmation
Attendant gives Final Confirmation
Order formatted for Kitchen/Payment API
Customer prompted to proceed to payment
Transaction ends
This requires five components:
1. Speech-to-Text Service For capturing guest voice input
2. Large Language Model To interpret speech-to-text input, recognize orders, understand context, process order steps, and communicate with McDonald’s order creation API
3. Text-to-Speech Service For responding to guests in the McDonald’s voice
4. Order Processing Service A single event sender called by the LLM to communicate with all relevant systems
5. Data Warehouse For storing all audio files.
Now let’s examine some of these services, their feasibility, accuracy, and assess the full system under ideal conditions.
The Speech-To-Text Model.
I’m not certain what technology McDonald’s and Wendy’s actually use, but some speech-to-text model must be involved. Speech recognition has existed in Computer Science since the 1970s – long before Claude and ChatGPT. The technology has been viable for decades.
In 2025, creating a fast-food-specific speech-to-text model with sub-5% WER is feasible. Let’s assume a 5% order error rate due to speech recognition issues.
This amounts to 1.875 million/day that are drive thru orders. At ~37.99sec for a drive-thru order, this is 71.2 million seconds/day of audio. Let’s also assume, half that audio, is the intake, speech to text.
This amounts to a cost of $9888/day. Let’s keep it simple and say $10k/day.
This amounts to ~$3.65M/year.
The Text-to-Speech Model
This is 100% achievable in 2025. Numerous companies offer text-to-speech synthesizers with variable speech, tone, and language capabilities. You can even find free options online.
Text to Speech by Microsoft is $15 per 1M characters.
Above, we determined approximately 1.875 million/day that are drive thru orders.
This amount to 177.18M words for all orders each day. Half that is the response at 88.59M words for all orders each day.
Each year we are looking at 32B words for the year. We assume the average character count of an English word is 5.
We are looking at 161B characters/year.
This amounts to ~$2.4M/year.
The LLM Model
I propose a custom-trained LLM specifically designed as a McDonald’s drive-thru attendant.
This is a weak point in my own abilities to execute, but I know what is feasible for an experienced developer in this speciality can achieve. These conditions may also be available out the box in a few months.
This LLM needs training to:
Access current menu information
Know when to offer “Would you like to make it a large?”
Know when/how to finalize orders for kitchen preparation
We don’t need advanced coding or math abilities (the payment processor handles calculations). Just high-school-level knowledge and reasoning will suffice.
Let’s assume approximately 95% accuracy – a very generous assumption.
As defined above, we are looking at 161B characters/year.
This amounts to 40.25B tokens/year.
This amounts to $40k/year.
Not bad, if I did my math right.
Note: I did not include costs to training the model. I will assume that is the bulk of the cost, but is an initial setup cost. I’m looking at regular running costs.
Data Warehouse
This is to store all the audio files that are generated.
Above we determined, 71.2 million seconds/day of audio. Which is about 25.9B seconds/year.
Somewhat negligible in comparison to the other costs so far.
Final Costs
Speech-To-Text: ~$3.65M/year.
Text-To-Speech: ~$2.4M/year.
LLM Costs: ~$40k/year.
Audio Storage Costs: ~$62k/year.
A Class 5 estimate, I would begin to start considering is about ~$6M/year to operate the basic technology behind it. And this base operating cost is most likely to decrease over time.
I think the bigger cost would be the development team of this project. McDonald’s doesn’t have to hire IBM or Google to build this out, they could hire a whole in-house development team. Considering that they are saving total expense of ~$217M CAD/year on salary alone across their franchise members, a team of 10, (Devs, QA, AI Dev, Project Mangers etc) could pull this off.
At an approximate expense of running a team like this at ~$2-5M/year, assuming highly competitive wages and the operating costs: my estimate on a final technical operating cost per year could be ~$11M/year (-50%/+100%).
This assumes perfect conditions – no snowstorms disrupting speech recognition, all accents understood, slurred speech interpreted correctly, and handling all voice recognition variables that humans manage effortlessly.
This suggests our current technology stack could theoretically achieve 90% accuracy with off-the-shelf components.
How does this compare to other attempts and the human attempt?
Using completely off the shelf technologies, a bit of plumbing, a whole lot of data and add speech-to-text input and text-to-speech output and you have a working prototype.
My Final Thoughts and Next Steps.
So what’s next? We’ve established theoretical feasibility and a strong financial feasibility. How do we implement it?
McDonald’s and the other chains can’t focus solely on technical execution.
They must consider:
Legal implications
Customer Compliance
Regulatory Requirements
Ethics board approval
Training requirements
Franchisee roll-out plans
Transition strategies
Data storage contracts
Data processing agreements
Many legal challenges exist, but they’re solvable. While not my expertise, I could advise different groups on their requirements.
McDonald’s isn’t abandoning the concept – just IBM. They’re quickly seeking another vendor (sounds like it’s Google), clearly recognizing the value and feasibility.
I could elaborate further on these points or provide a cost breakdown for the team and resources needed, but that’s material for another article.
There are a few more things I haven’t spoken about, like a feedback loop mechanism, referral to other orders, voice recognition with repeat customers etc. These are all additional value adds that can improve the guest experience and the AI solution.
This thought exercise on business-technology intersection has been fascinating. I hope you’ve learned something about fast food and AI applications. Perhaps it will inspire you to discover your own use case.
I was sitting at home listening to my HR manager talk about zzzt, a member on my team*.* They had been on my performance improvement list for many months, close to a year, but I had only just recently, a few weeks ago, given them a formal PIP.
A Performance Improvement Plan. HR’s signal to an employee that they are facing termination unless serious changes are made. Almost all the PIPs I have engaged with have ended the relationship between employee and employer. Either because the employee has already given up and gets the message, or because they fail to improve.
I hoped for the first one, selfishly. I already had no hope they would improve.
But, zzzt, had chosen to stay and try to show improvement.
I put my palms to my face and pull my head down. This was not an easy situation to be in. It never has been, especially when you were responsible for hiring them.
“zzzt has shown initiative to improve, but in my professional opinion, given what we are expecting from them after these years, the growth is not there.”
This was a startup, with limited resources, and limited slots. When we hire developers, co-ops, juniors and intermediates are usually targeted because from an expense side they are cheaper, but also from a growth prospect side, we can see them grow with the company. They become part of the essence of it. It’s not enough to just be the same developer from a year ago. Especially if there is no criticality of the work you’ve done.
Unfortunately for zzzt, they hadn’t grown professionally or technically in the two years since I had hired them. I had interns who had joined who are fielding their own full projects and thriving. But zzzt was stuck unable to take lead, technically or from a project side. They were unable to self-direct in a chaotic environment. This was not a medium-large enterprise, where you can hide performance issues. They were visible, and in a health startup, performance is demanded by your own coworkers.
“But I think they can get there…”
“Kevin, if you had a choice to interview zzzt again, would you rehire them?”
I thought about our current interview process. We had redone the interview because of this particular hire, to include a code reading assignment. A few years ago, the interview process included a take home assignment, and we hired anyone who would be able to do it. But we found this would only filter for people who can write, and extract code from pre-existing code. This was precisely the problem with zzzt. They lacked the ability to read, understand and comprehend code. And it wasn’t getting better.
I thought back to the day we made the hire for zzzt. The team was small, and I was excited to finally get another developer to help me out, and work side by side with. But quickly within the first few weeks, I found that I did not hire a peer, but a person to mentor and level up. Concepts like hooks, context, provider, recursion, data structures in a React Codebase, things we saw in the interview, were struggles for zzzt. This took time away from my own ability to execute, time away from delegation, and loss in confidence they could do the job.
Maybe I gave the wrong expectation as a lead to them? Maybe I wasn’t clear enough? Maybe I didn’t spend enough time with them? Maybe if I gave them a few more weeks.
I didn’t want to make that call.
I didn’t want to end their time here. I started it for them, I saw them progress the last two years.
I didn’t want to think about their personal life, how it would be affected. I remembered the time I was suddenly let go from a startup I gave a few years of my life to. Suddenly, my life shifted, time schedules had a gap, the people I spoke to for 40 hours a week, no longer there anymore. The immediate loss of money. The anxiety of finding another role.
“I’ve given zzzt direct verbal feedback. I’ve sent them an email. I’ve reiterated this feedback over months. I feel like I’ve given all I could to clearly help and provide resources. I have sent them a PIP once before, and yet we are still here. I think, yes, we should move on.”
I saw where this company was going. I saw the caliber of people it attracted. The eager interns, juniors who dived eagerly into the work and problems, and came with a can-do attitude. The self-sufficient people who I lead, who asked for direction when they did not know where to go. Those who I saw needed their own projects to level up, who clearly spoke of what they wanted and needed. Those who would be the future leaders. This was the culture that this particular startup needed.
How you work, how you perform, how you learn, is all a function of your self-identity. It’s a part of you. As a manager, I try to fit the work, and teach people based on who they are, to find the translation to the company’s own identity. If I am successful, I can make the match. If not…
I did not want to change a person to fit the culture. I don’t think I should or could. Nor do I think people should change to fit a culture.
You are as you are. The company you join is the same.
You shouldn’t erase your own identity for a dollar. And you can’t act forever.
Who you are will be valued at some position, in some company. And if you can’t find it, you can always make that company.
Easier said than done.
“Kevin, send them a message and let them know you want to chat.”
I knew this wasn’t going to be easy. Felt like we were ambushing them.
It had to happen one way or another.
Or so I tell myself each day.
“When you are on the call let them know that HR will be joining, and call me in. First you’ll say….
The hard truth about job searching in 2025 that no one wants to admit
Disclaimer: Job searching is mentally exhausting. If you’re feeling depressed or overwhelmed, please reach out to your support network or professional help. Your value as a human being is not tied to your work.
90% of job seekers are spending 40 hours weekly on job applications, yet only one person I interviewed landed a job through applying online. The other successful candidates? They relied on referral-based hiring strategies.
Thanks for reading Flying While Building! This post is public, so feel free to share it.
The Harsh Reality I Discovered After Speaking With 100 Job Seekers
As a hiring manager who’s designed interview pipelines and reviewed thousands of resumes, I wanted to understand what challenges job seekers face today. So I flipped the script.
I reached out to over 100 people on LinkedIn who had previously applied to roles I was hiring for. I asked them one simple question
What challenges are you facing in the current job market?
The responses were overwhelming and revealed a truth that most career advisors and job search strategy blogs won’t tell you.
The average person submitted 300+ online applications
Almost all who found jobs did so through referrals
Only one person landed a job through the traditional application process
This clearly shows how modern job searching in 2025 has shifted away from platforms and toward network-based hiring.
Flying While Building is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
The Online Application Black Hole
Every single person described the same painful reality: spending 40+ hours weekly crafting custom resumes and cover letters that disappear into the void. These online applications often fall victim to AI resume screening tools, which means they’re never even seen by a human.
The brutal truth: applying for jobs online is like shooting in the dark, and you need at least 300 well-targeted attempts to get a few interviews.
AI Has Made Everything Worse
With automated hiring systems and AI-driven resume filters, you’d think the process would be more efficient. Instead, it has created a perverse game where candidates optimize their materials for algorithms rather than people.
As a hiring manager, I now see dozens of AI-generated resumes that are practically indistinguishable from one another. Ironically, this makes the “bad” resumes, with personality and authenticity, stand out.
Because at the end of the day, an AI is not going to be your manager.
No matter how advanced technology becomes, one thing stays the same: a human will hire a human.
The Secret That Actually Works
Here’s what no one tells you in most career coaching articles:
Your next job will come through someone vouching for you.
Every company has internal referral bonuses. There are political, financial, and social incentives for employees to recommend people they know. Companies are essentially professional social groups, and culture fit matters more than candidates realize.
The people who stood out most in my conversations? Those who asked for a coffee chat. These quick, informal conversations revealed more than any resume could.
It’s Brutally Hard for Juniors
Half the people I spoke with had less than a year of experience or were trying to break into the tech industry. These candidates faced the most rejections and spent the most time searching.
As a hiring manager looking at junior talent, I have no experience, reputation, or portfolio to judge you by. The risk is higher, which is why employee referrals become even more crucial at the entry level.
I only broke into my first few jobs through referrals and leveraging professional networks.
What Actually Matters in 2025
Despite new tools and tech, the core hiring question remains:
“Do we trust you to do the job?”
When I open a position, I receive hundreds of applications, but I only forward ten. Anyone who comes recommended through referral-based hiring gets more of my attention because someone’s putting their reputation on the line.
Candidates who understand the business context—not just the job description—stand out dramatically. Don’t just be a cog in the machine. Understand how the machine works.
Finding a Job Is Selling Yourself
And sales in the job market aren’t just about flashy CVS. It’s about understanding your value and packaging it in a way that builds trust.
Master the skill of selling yourself, and it will pay dividends for the rest of your career.
Take Care of Your Mental Health
The universal message I heard: job searching is incredibly stressful.
Take care of yourself. Lean on your network. Remember, your worth is not tied to your employment status.
Looking for work is often harder than the job itself. But understanding the real rules of the job market in 2025—that connections matter more than applications—might just save you months of frustration.
Before submitting your 301st online application, ask yourself:
Speech Recognition and Computer Vision the forgotten siblings in the AI conversation today.
There are two other pieces in the AI landscape that I do not believe are getting the attention they deserve: speech recognition and computer vision systems.
Are you thinking just about how an LLM (large language model) can code your new app? Or how you can have it rephrase that sentence you were going to send to your investors? Maybe you’re asking it to be the Tony Robbins of business development, seeing if it can create a new path for that division in your company that’s not doing great.
Generative AI can do that, but if you’re asking your team to focus only on text-based LLM tools to improve workflows, you’re leaving out powerful AI use cases in 2025 that involve speech recognition and computer vision.
By the way, all this is commercially available through the cloud. Azure, AWS, and GCP all provide high-quality versions of these technologies ready through an API.
🎙️ Speech Recognition (Voice and Ears)
Automatic Speech Recognition (ASR) and Voice-to-Text technologies technologies have been around for a very long time. (I even wrote about how McDonald’s can use it). Combining this with LLMs, the accuracy to understand intent and context is much higher.
This is a hugely underused AI technology, especially in Latin America, Africa, and the Middle East. Voice notes or messages are common for both personal and business communication. Even in North America, when you’re driving or working in a noisy warehouse, wouldn’t it be better to use voice commands powered by speech recognition systems and get accurate outcomes?
👁️ Computer Vision Systems (Eyes)
So you want to identify if something is a hotdog or not? What about if that is a car or a motorcycle? Or how to pull text from an image (reCAPTCHAs are a version of reinforced learning used to train models in classification).
Variations of this have been around for quite a while, and I’m sure there are few old texts, financial records, archival data that is just sitting around in a cupboard. Why not analyze them and combine the learnings into an LLM that can become your companies archivist?
Don’t leave these two out of the AI conversation. You might be missing out on practical, high-impact applications of AI that aren’t being fully leveraged.
