TechPod Talks: Episode 2 Recap

If Coding Is No Longer the Bottleneck, What Is? Lessons Learned from Francisco Trindade

Every engineering team today can write 10 or even 100 times more code than they could the year prior, but very few of them are actually shipping 10 times the value. That gap between code production and value delivery is where the real leadership challenge lives, and it requires a fundamentally different way of thinking about teams, systems, and what software engineers can really do in a day.

In Episode 2 of TechPod Talks, EverOps CEO Stephen Koza sits down with Francisco Trindade, an engineering leader whose career has spanned continents and company stages. He co-founded his first startup in Brazil while finishing his master's, spent years shipping code across dozens of client engagements at a consulting firm in London, built a grocery delivery platform in Melbourne, and now leads product engineering at one of the fastest-growing consumer engagement platforms in the world.

Meet Our Guest

Francisco is currently the VP of Product Engineering at Braze, where he leads engineering across the product organization. He joined in 2021 and has been promoted three times as a result of the company scaling into one of the most established names in customer engagement software to date.

Francisco's career arc is unusually broad. He started in Brazil, where he studied computer engineering (hardware and microelectronics, not software), then co-founded his first company while finishing a master's in computer science. That early startup experience revealed how much he still needed to learn about building software at scale, which led him to join ThoughtWorks, a consulting firm whose books he had been reading for years. He ended up spending six years there shipping code across dozens of client engagements in London. From there, he moved to Australia, where he co-founded YourGrocer, a grocery delivery startup serving independent grocers competing against the country's dominant supermarket chains. After a couple more positions at various tech companies, he joined Braze in 2021, where he has since been promoted three times. 

Francisco is also an active writer and conference speaker and is currently working on a book focused on engineering leadership. The thread connecting it all is a deep, career-long focus on how to make software teams work effectively.

Episode 2: Key Takeaways

• Why coding has never been the bottleneck in software delivery, and why AI is making that truth impossible to ignore
• How to think about engineering leadership as managing the system of the team, and why optimizing for individuals first often backfires
• Why the principles behind agile are resurfacing in the AI era, even as the label itself fades
• What happens when 500 agents are writing code on a 2-million-line codebase, and why that's an engineering problem, not just an AI problem
• How Francisco's grocery delivery startup taught him a lesson about customer understanding that he still applies at Braze today

If you lead an engineering team that's trying to figure out how AI changes your workflows, your hiring, your code review process, or your team structure, this is a conversation worth your time. Francisco has lived through multiple technology revolutions across startups, consulting, and enterprise SaaS, and his perspective is grounded in what actually works when you're responsible for shipping software that generates revenue.

Why Coding Was Never the Bottleneck in Software Delivery

The central argument Francisco makes in this episode, and one he has written about extensively, is that coding has never been the primary bottleneck in software delivery. Reviews, testing, rework, waiting, and the misalignment between what the product wants and what engineering builds are where value gets lost most often. While AI has dramatically accelerated code production, it has also made non-coding bottlenecks more visible and urgent.

Francisco sees this clearly at Braze. With 350 engineers running a revenue-generating platform that can't afford downtime, he poses a hypothetical that captures the scale of the challenge: Imagine 100 engineers, each with five agents running alongside them. That's 500 agents writing code on a 2-million-line codebase. How do you maintain coherence? How do you maintain quality? Those are engineering leadership challenges that no amount of faster code generation solves on its own.

He draws a direct line to the original principles behind agile methodology, while acknowledging he tends to avoid the word itself these days because too many engineers carry scar tissue from agile transformations that never delivered on the promise. The principles themselves, though, remain intact. The core idea behind agile was always that coding was at the bottom of the value chain, and that the harder work was understanding the customer, collaborating across disciplines, and delivering iteratively.

This is the fork in the road that Stephen opened the episode with. AI has flooded the system with more code than humans can possibly review, which leaves engineering leaders with two options: figure out how to safely remove humans from the loop, or watch a competitor do it first. The companies that solve for architectural coherence, testing infrastructure, and agent orchestration at scale get to pick the first path. The rest will be reacting to somebody else's answer.

"What software engineers were doing before and are doing now hasn't changed… to deliver value through software. That's something we're still going to need to continue doing."

For startups, the calculus is different, and the companies that invest in those systems now will have a structural advantage over those that don't.

Managing the Team as a System Vs a Collection of Individuals

Francisco shared a line from his own writing that Stephen highlighted during the conversation: "Engineering leadership is managing the systems in the team to make people within it successful, instead of the other way around." Leaders should think about the team as the unit of output and adapt the work to the people they have.

The alternative, which Francisco sees frequently, is managers who start with individual preferences and try to assemble a team structure around them. That approach creates a constantly shifting puzzle that rarely produces consistent results. Francisco gives an example of this from his work at a previous company, where he had an engineer who was brilliant in bursts but struggled to keep up with the team's day-to-day rhythm. Because the team was delivering strong results overall, Francisco had the freedom to create a custom arrangement in which that engineer took on moonshot projects while the rest of the team maintained the core delivery cadence.

The same principle applies to understanding the customer, which is where a story from Francisco's earlier career lands. At YourGrocer, he and his co-founder assumed their customers would look like them, young, single professionals who liked to cook. However, after conducting in-home interviews with actual users using the Jobs to Be Done methodology, the pattern became obvious by the third visit. Every customer was a parent with young children, and their entire target market assumption was wrong, which they only discovered by physically showing up. 

Francisco notes that this exact level of misalignment rarely happens at established companies, but subtler versions happen constantly. Communication gaps between product, design, engineering, and data mean engineers often build against an incomplete picture of the problem. Managing the team as a system requires both treating the team as the unit of output internally and treating customer understanding as the input that determines what the team builds.

"The way for you to have no one paying attention to what you're doing is you just deliver the results that we ask you to deliver. Because that is the main goal. On the other hand, if you fail to meet the results, then you get a lot of scrutiny in what you're doing, and you're probably going to get a lot of opinions about how you manage your team."

That freedom only existed because the team was effective as a system. Delivering results as a team unlocks a virtuous cycle. More results lead to more trust, more trust leads to more freedom, and more freedom creates more opportunities for the individuals within the team.

Why Conviction Matters More as You Advance in Leadership

Francisco identified a challenge that many engineering leaders recognize but rarely articulate clearly. The higher you rise, the less structure and direction you receive, and the more your organization depends on your personal conviction about how things should work. At the manager level, there are rules and frameworks to follow. At the director level, meaningful decisions start landing in your lap with less guidance attached. Then, at the VP level, people give you broad direction, but how things get done is almost entirely your responsibility. Without a strong conviction about the principles you operate by, you risk building an organization where different teams follow different philosophies, and no consistent standard holds anything together.

Francisco connects this directly to his concept of the "micro CTO." A CTO owns the technical strategy, architecture, and outcomes of an entire organization, and Francisco's point is that every manager should own their team with that same level of end-to-end responsibility. The more a manager behaves like a CTO of their own domain, the more empowered they feel to change what needs changing and adapt as circumstances require. That ownership mindset, he notes, is one of the strongest predictors of success he sees at Braze. Former founders, former startup CTOs, and people who have operated with full ownership over a product or team tend to thrive because they already know how to take an ambiguous problem, structure it, build a plan, and align a team around it.

"Leadership is making the invisible visible. It's really about understanding a problem that is maybe opaque and putting it through a structure that you can solve."

Early in his career, Francisco would take on every problem that came his way, especially after proving he could solve a few. The result was spreading too thin and becoming ineffective across the board. The discipline of limiting the number of problems you tackle at any given time, doing fewer things well rather than many things poorly, is something he now considers essential to sustainable leadership.

Careers Make More Sense By Looking Backward

Francisco closed the conversation with a piece of career advice that reframes long-term planning for engineering leaders. He once attended a talk in which the speaker argued that careers only make sense when looking backward. You cannot predict what jobs will exist in five years, so planning a rigid path toward a specific title is inherently fragile. The better approach is to decide what you want to do now, do it as well as you possibly can, and let the accumulation of those experiences make you uniquely qualified for whatever comes next.

Francisco finds this especially relevant for junior engineers who are anxious about whether their skills will remain valuable in the AI era. His perspective is practical. He has lived through multiple technology revolutions, from the days when six people spent a week building a build server just to commit code, to the rise of cloud infrastructure, to agile transformations, and now to AI. Each revolution changed the tools and the workflows. None eliminated the need for people who can organize work, understand problems, and deliver value.

"You don't know what job is going to exist in five years. So what's the point of trying to say you're going to be something in five years? Decide what you want to do now, do that as best you can, and the accumulation of your experience is going to make you unique in the future."

His advice for junior engineers is simple: learn from the process, get comfortable building things, and trust that the skills you develop along the way will compound into something valuable regardless of how titles and role definitions shift.

How to Apply These Insights Today

1. Audit where your actual bottlenecks live: If your team has adopted AI coding tools, map where work is actually getting stuck. Code reviews, spec clarity, testing coverage, deployment friction, and cross-team alignment are the most common culprits. Solving those will unlock more value than generating more code.
2. Evaluate your team as a system: Ask yourself whether you're optimizing for team output or individual preferences. If your most effective engineers are constrained by rigid processes and your under-performers are shielded by a manager who prioritizes individual advocacy over team results, the system needs to be adjusted.
3. Talk to your customers (literally): Schedule five conversations with actual users of what your team builds, whether those are external customers or internal stakeholders. Use open-ended questions, even. The misalignment you discover will almost certainly change your priorities.
4. Define your leadership principles and write them down: If you're at the director level or above, your organization is shaped by your convictions, whether you've articulated them or not. Writing them down forces clarity and gives your teams something consistent to follow.
5. Limit your active problem set: Pick the two or three most important problems you can solve this quarter and commit to those. Say no or "not yet" to everything else. Spreading across ten priorities is a reliable path to being ineffective at all of them.

Keeping Up with TechPod Talks

If you found this conversation useful, we have good news because TechPod Talks is just getting started! We highly encourage you to subscribe now so you don't miss what's coming next. Every episode features a practitioner who's actually in the arena, sharing what works in platform engineering, cloud, DevOps, and technical leadership today.

Subscribe to any of these to tune in:

Apple Podcasts | Spotify | YouTube | EverOps Podcast Page

Follow for additional clips, behind-the-scenes content, and future episode announcements:

• https://www.linkedin.com/in/stephenkoza/ 
• https://www.linkedin.com/company/everops/

Books and resources mentioned:

• The Lean Startup by Eric Ries: The methodology Francisco applied during his startup years and later in enterprise innovation labs at ThoughtWorks
• Jobs to Be Done framework: The customer interview methodology Francisco used at YourGrocer to discover their actual target market
• Francisco's blog on Medium: Where he puts all of the things mentioned in this episode and so much more into perspective for his readers. 

Connect with our guest Francisco on LinkedIn today: https://www.linkedin.com/in/franciscomt/ 

Frequently Asked Questions

What is TechPod Talks?

TechPod Talks is a podcast hosted by EverOps CEO Stephen Koza featuring candid conversations with technology leaders, engineers, and operators. Each episode explores how real teams build, scale, and operate modern systems, with a focus on practical takeaways.

Who is this podcast for?

The podcast is designed for CTOs, engineering managers, DevOps and SRE professionals, platform engineers, and technical operators, especially those at companies navigating cloud optimization, modernization, and AI adoption.

Where can I listen to TechPod Talks?

TechPod Talks is available on Apple Podcasts, Spotify, YouTube, and the EverOps website. Episodes are released in both audio and video formats.

What topics does Episode 2 cover?

Episode 2 features a wide-ranging conversation with Francisco Trindade covering how AI is reshaping software development workflows, why coding was never the real bottleneck in delivery, how to manage engineering teams as systems rather than collections of individuals, lessons from founding a grocery delivery startup in Australia, the increasing importance of leadership conviction at senior levels, and practical career advice for engineers navigating uncertainty.

Who is Francisco Trindade?

Francisco Trindade is VP of Product Engineering at Braze, where he leads engineering across the product organization. He has co-founded two companies (one in Brazil, one in Australia), spent six years consulting at ThoughtWorks across London and other markets, and has been promoted three times since joining Braze in 2021. He writes regularly about engineering leadership on Medium and is currently working on a book.

How does this episode relate to EverOps' work?

EverOps works with engineering organizations navigating the same challenges Francisco discusses, such as adapting team structures and workflows to new tooling, maintaining quality and coherence at scale, and building systems that deliver reliable value. The principles in this episode align directly with how EverOps approaches client engagements.

How often are new episodes released?

After launch week, TechPod Talks follows a consistent every-two-week release cadence. Follow EverOps and Stephen Koza on LinkedIn or subscribe on your preferred podcast platform to stay updated on new episodes.

Can I suggest topics or be a guest on the podcast?

Yes. You can share topic suggestions by reaching out on LinkedIn or on the EverOps website, which includes a guest request form for speakers interested in joining future episodes.