Engineering Evolved

About Engineering Evolved

Where business meets innovation and technology drives transformation. Concept to Cloud is the podcast for leaders navigating the forgotten ground between startup chaos and enterprise bureaucracy. If you're building and scaling teams at organizations in the middle — where startup rules no longer apply and enterprise playbooks are far too large — this show is for you. Hosted by Tom Barber, each episode explores the real challenges facing today's engineering leaders: scaling systems without breaking them, building high-performing teams, aligning engineering strategy with business goals, and making technical decisions that drive measurable impact. Whether you're a Director of Engineering, VP of Technology, CTO, or an IC engineer stepping into leadership, you'll find practical insights drawn from real-world experience — not theoretical frameworks that only work on whiteboards. Topics include: Scaling engineering teams and systems for growth Building effective engineering culture Bridging the gap between technical and business strategy Leadership tactics that actually work in the messy middle Making architectural decisions with limited resources Navigating organizational complexity Concept to Cloud — guiding today's leaders through the evolution of engineering. New episodes drop weekly. Subscribe now and join the conversation about what it really takes to lead engineering in the modern era. Subscribe to our newsletter: https://newsletter.concepttocloud.com/

Publisher

Tom Barber

Category

technology

Language

en

Explicit

No

First episode

9 Nov 2025

Latest episode

26 Aug 2026

Latest episodes

18 episodes in the feed.

1. 

   26 Aug 2026

   Tack On, or Rebuild?

   Tom rebuilt Saiku - an open-source analytics platform he first shipped years ago - and got 97 new installs. He also found roughly 180 people still running the old one. He can't email them. He can't see them. Two-thirds of them are on a version that nee...

2. 

   8 Jul 2026

   From Napkins to Agents: How AI Rewired Product Design

   In this episode of Engineering Evolved, Tom sits down with Amelia Prasad, Director of Product at Concept to Cloud, to trace how AI has reshaped the day-to-day of UX and product design. Amelia — who came to product from astrophysics and climate science — walks through the shift from manual research, whiteboards and "back-of-the-napkin" sketches to building zero-to-one products directly in Claude Code. It's not a hype reel. Amelia is candid about the friction: learning version control from scratch, bloated six-thousand-line files, the designer-to-developer handoff problem, and the diminishing returns of heavy token usage in tools like Claude Design and third-party wrappers such as Lovable. Her current answer is a marriage of tools — passing work back and forth between Claude Code and Figma via MCP — so prototyping speed and real usability, accessibility and design-system rigour can each live where they belong. They close on what the next 12 months might hold: more human-led user research, not less, and why juniors and design intuition still matter in an industry tempted to hire only senior builders. Chapters 00:00 — Welcome & introducing Amelia 02:53 — From astrophysics to product design 03:33 — The pre-LLM UX workflow: manual research & competitive analysis 05:23 — Old-school tooling: Figma, Miro, Maze, pen & paper 06:56 — The lost art of napkin sketches and paper prototyping 07:57 — Meeting at Princeton: first exposure to LLMs 08:52 — AI workflows before AI building: the interview note-taker 11:02 — Stepping into Claude Code as a non-developer 13:45 — Handing off code on a small team: value and limits 15:17 — Guardrails, context and the handoff problem 20:02 — Lovable, Cursor and the trouble with wrappers 21:05 — Claude Design: token cost and diminishing returns 22:45 — Figma's MCP and the two-way handoff 24:50 — A suite of tools: knowing when to hand off to which 29:06 — Why active engagement in Figma beats waiting on the terminal 33:02 — The next 12 months: user research, systemic processes, robustness 38:16 — Will design jobs disappear? Juniors, intuition & human-in-the-loop 41:27 — Wrap-up & thanks Key takeaways AI adoption in design was gradual — automating admin and research before it could build whole products. The real skill now is orchestration: knowing which tool (Claude Code vs. Figma) does which job best. Speed doesn't replace craft — usability, accessibility and design systems still need a designer's hand. Human intuition and user research grow more important as products become AI-native. Cutting junior roles is short-sighted: today's juniors build the intuition tomorrow's products depend on. Enjoyed this one? Find us at conceptocloud.com and on LinkedIn. Subscribe to Engineering Evolved so you don't miss the next episode.

3. 

   24 Jun 2026

   The $13K Company Backlog: Private Equity's Capital Return Crisis in 2025

   Private equity firms are facing an unprecedented challenge with a backlog of 13,000 companies. The biggest issue for 2025 isn't raising capital or sourcing deals—it's successfully returning capital to investors after buying at market peaks. Show Notes Episode Overview A concise analysis of the private equity industry's current crisis: managing a backlog of 13,000 companies while struggling to return capital to investors. Key Topics Covered The 13,000-Company Backlog Unprecedented number of portfolio companies awaiting exits Industry-wide challenge affecting firms of all sizes Redefining what success means in private equity The Capital Return Challenge Why returning capital has become the #1 priority for 2025-2026 Shift from traditional metrics of success (fundraising and deal flow) Impact on limited partners and fund performance Market Timing Issues Consequences of buying at market peaks The "top of the bubble" problem Current valuation challenges and exit environment Key Takeaways The private equity industry faces a structural challenge with 13,000 companies in the exit pipeline Capital return has superseded fundraising and deal sourcing as the primary challenge Firms that bought at peak valuations are particularly vulnerable The traditional definition of private equity success is being rewritten Relevant for: Private equity professionals Limited partners and institutional investors M&A advisors and investment bankers CFOs and business owners considering exits Financial market analysts Chapters 0:00 - Introduction: The Private Equity Challenge 0:11 - The 13,000-Company Backlog Crisis 0:19 - Capital Return: The New Priority 0:28 - The Peak Valuation Problem

4. 

   16 Jun 2026

   Your Users Don't Care If It's AI - They Just Want Results

   Tom Barber challenges the AI hype cycle, arguing that users care about outcomes, not architecture. Learn why slapping an 'AI-powered' label on everything is the wrong approach, and discover how to thoughtfully integrate LLMs into products without falling into common pitfalls like dependency on unstable APIs or unnecessary chatbot interfaces. Show Notes Episode Overview Tom Barber returns with a critical examination of AI integration in modern software development, challenging teams to focus on user outcomes rather than jumping on the AI hype train. Key Topics Covered The AI Marketing Problem Why 'AI-powered' labels are often meaningless marketing The difference between machine learning (which has existed for decades) and modern LLMs Examples of invisible AI: spam filtering, fraud detection, map rerouting Users grade products on consistency, not on the impressiveness of the underlying model Engineering Considerations for LLM Integration Choosing the right model for your specific use case (Opus, Sonnet, GPT-4, etc.) Tradeoffs between cost, speed, and inference quality Building evaluation systems and fallback paths Managing latency budgets and graceful degradation Handling API outages from providers like Anthropic and OpenAI The risks of depending on frontier models that can be deprecated Trust and Transparency AI as a potential trust liability Managing user expectations around hallucinations The importance of data provenance and quality (garbage in, garbage out) When and how to disclose AI usage to users The ethical obligation to be transparent when AI makes consequential decisions Product Strategy Why you can't charge an 'AI tax' on top of existing pricing Pricing based on outcomes, not on the technology stack How to use LLMs to deliver genuine efficiency gains Reducing user overhead and friction through thoughtful AI integration Beyond Chatbots Why chatbots may be the most inefficient way to interact with LLMs The challenge: How to integrate LLMs without forcing users to type everything Asking 'What's now instant that wasn't?' instead of 'How do we add AI?' Innovation opportunities for those who can solve the chatbot problem Key Takeaways Users care about reliable outcomes, not whether you're using AI Engineer for model availability issues and API outages from day one Select and tune models specifically for your use case rather than defaulting to frontier models Be transparent about AI usage, especially for consequential decisions Focus on delivering value through AI rather than adding an 'AI-powered' label for marketing The future belongs to products that leverage LLMs without relying on chatbot interfaces Resources Mentioned Various LLM providers: Anthropic (Claude/Opus/Sonnet), OpenAI (ChatGPT-4) Example of model deprecation: Fable model being pulled Connect Engineering Evolved is hosted by Tom Barber. If you found this episode valuable, please leave a rating and review to help other leaders discover the show. Chapters 0:00 - Introduction: Users Don't Care If It's AI 1:01 - Machine Learning Has Always Been Here 2:19 - The AI Marketing Problem: Selling Architecture vs Outcomes 5:16 - Engineering Realities: Models, Consistency, and Reliability 10:11 - The Cost of the AI Label: Trust and Pricing 14:39 - When Users Do Care: Transparency and Consequential Decisions 17:15 - Beyond Chatbots: The Future of LLM Integration

5. 

   15 Dec 2025

   The Trio Model: Breaking Down Business-IT Walls for Better Engineering Collaboration

   Engineering leaders learn how the Trio model can eliminate the blame game between business and IT teams. Discover practical strategies for cross-functional collaboration that actually work. The Trio Model: Breaking Down Business-IT Walls Key Topics Covered The Business-IT Dysfunction Problem Why blame games develop between business and IT teams The 'technical purgatory' of mid-sized companies (200-1000 employees) Common symptoms: endless backlogs, shadow IT solutions, demoralized engineers Why Traditional Fixes Fail Hiring more managers: Adds abstraction without context Adding more engineers: Brooks' Law in action Better ticketing systems: Makes misalignment visible but doesn't fix it More meetings: Creates 'status theater' without decisions The Trio Model Explained Three core roles: Business owner, technical lead, designer/analyst/ops lead Co-ownership of outcomes, not just task handoffs Clear decision rights to prevent gridlock Not a committee: Explicit authority assignment Implementation Strategy Which problems warrant a trio (high ambiguity, cross-functional dependencies) Decision rights framework Shared metrics and accountability Starting with 1-2 pilot areas Leadership Requirements Stop bypassing trio processes with 'urgent' requests Protect trio time and focus Hold business owners accountable for outcomes Accept timeline realities Key Quotes "If every request is urgent, there's no way for IT to prioritize" "Shared ownership of the outcome doesn't mean you can point at someone else when your part goes wrong" "The trio owns it can quickly become no one owns it" Action Items Identify 1-2 high-friction problem areas Form pilot trios with clear problem definitions Establish shared success metrics Review and iterate after one quarter Chapters 0:00 - The Business-IT Blame Game Problem 1:56 - Life in Technical Purgatory 5:29 - Why Traditional Fixes Don't Work 10:09 - Introducing the Trio Model 15:51 - Implementation and Decision Rights 23:42 - Measuring Success with Shared Metrics 24:50 - Leadership Changes Required 29:25 - Getting Started: A Practical Approach

6. 

   10 Dec 2025

   Why Your Team Rituals Are Optimized for the Wrong Thing

   How many meetings moved your team forward last week? Tom explores why most team rituals fail at building trust and alignment, sharing lessons from NASA JPL and startups on creating ceremonies that actually work. Why Your Team Rituals Are Optimized for the Wrong Thing Key Topics Covered The Missing Middle Challenge Why mid-sized companies (200-1000 employees) face unique coordination challenges Too big for startup osmosis, too small for enterprise playbooks The need for distributed decision-making without dedicated alignment teams Two Contrasting Standup Experiences NASA JPL: Nightly standups across three time zones that built trust and enabled handoffs Medical Startup: Transactional daily standups that created artificial harmony What made the difference: optimization for relationship building vs. status updates The Five Dysfunctions of a Team Framework Absence of Trust - Vulnerability-based trust, not competence trust Fear of Conflict - Artificial harmony vs. productive disagreement Lack of Commitment - What happens when people don't feel heard Avoidance of Accountability - When standards become suggestions Inattention to Results - Individual ego over team success Three Practical Shifts for Better Rituals Shift 1: Surface Vulnerability Leadership modeling uncertainty first Structured moments for admitting what you don't know Moving from posturing to problem exploration Shift 2: Practice Disagreement Red team rotations in roadmap reviews Making challenge a role, not a personality trait Ensuring friction happens constructively in the room Shift 3: Build Shared Context (Not Just Information) The difference between "here's the roadmap" and "here's the trade-off I struggled with" Smaller cross-functional context sessions vs. large all-hands presentations Enabling distributed decision-making through understanding reasoning Key Questions for Diagnosis How much time was spent on information transfer vs. relationship building? Did anyone admit uncertainty without it being a problem? Was there constructive disagreement that led to better outcomes? Do people understand the reasoning behind decisions, not just the decisions themselves? Resources Mentioned Patrick Lencioni's "The Five Dysfunctions of a Team" (2002) Concept of vulnerability-based trust Red team methodology for productive conflict Next Episode Preview Episode 14: The Product Trio Model - Making it Actually Work in Engineering-Heavy Organizations Chapters 0:00 - The Meeting Problem: Status Theater vs. Real Progress 2:20 - The Missing Middle: Mid-Sized Company Challenges 4:21 - Tale of Two Standups: NASA vs. Startup 11:15 - The Five Dysfunctions Framework 16:13 - Three Practical Shifts for Better Rituals 23:55 - The Compounding Effect of Trust 28:39 - Diagnostic Questions and Next Steps

7. 

   30 Nov 2025

   Why Kubernetes Is Probably Wrong for Your Mid-Sized Company

   Engineering leader Tom Barber challenges the default adoption of Kubernetes, sharing why simpler alternatives often serve mid-sized companies better and how to make pragmatic infrastructure decisions. Episode 12: Why Kubernetes Is Probably Wrong for Your Mid-Sized Company Key Topics Covered The Kubernetes Reality Check Why most mid-sized companies don't need Kubernetes complexity The hidden costs: maintenance, YAML management, and developer experience Real-world example from NASA: when impressive engineering doesn't solve business problems Understanding Kubernetes Context Origins from Google's Borg system designed for massive scale Core benefits: fault tolerance, auto-scaling, declarative infrastructure Why these benefits require significant investment to realize The Real Downsides Complexity: Even cloud vendors are building products to hide Kubernetes YAML Everything: Config management becomes a people and process problem Cost at Scale: Engineering hours, infrastructure, and mental health costs Developer Experience: High barrier to entry and friction in feedback loops Portability Mirage: Cross-cloud deployment still requires deep vendor knowledge When Kubernetes Makes Sense Genuine scale requirements (dozens/hundreds of services) Multiple teams with dedicated platform engineering capacity Complex deployment patterns that serve real business needs Practical Alternatives VMs with Docker: Boring is good, boring is maintainable Managed Container Services: ECS/Fargate, Cloud Run, Azure Container Apps Serverless: Lambda, Cloud Functions for event-driven workloads Simple Deployment Scripts: Often cheaper than cluster management Decision Framework: Do You Actually Need Kubernetes? What specific problem are you solving? Do you have dedicated team capacity? What's your actual scale (services, teams, traffic)? How frequently do you deploy? Have you exhausted simpler options? Resources Mentioned Free Download: "You Actually Need Kubernetes" Checklist (available in show notes) Consulting: Concept Cloud - Pragmatic infrastructure decisions for mid-sized companies Website: www.conceptcloud.com (http://www.conceptcloud.com) Contact: tom@conceptcloud.com (mailto:tom@conceptcloud.com) Next Episode Preview Episode 13: "Why Your Engineers and Product Managers Still Don't Talk to Each Other (And How to Actually Fix It)" Engineering Evolved is the podcast for engineering leaders at mid-sized companies who are tired of getting advice that only works for startups or enterprises. Chapters 0:00 - Introduction: The Kubernetes Controversy 3:00 - A Personal Story: Getting It Wrong at NASA 4:58 - Understanding Kubernetes: Context and Core Benefits 7:07 - The Real Downsides: Complexity, Cost, and Developer Experience 10:49 - When Kubernetes Actually Makes Sense 13:39 - Practical Alternatives to Kubernetes 15:51 - Decision Framework: Do You Actually Need It? 18:36 - Wrap-up and Next Episode Preview

8. 

   16 Nov 2025

   You Don't Need Kubernetes: Right-Sizing Platform Engineering for Mid-Size Companies

   In this episode of Engineering Evolved, Tom Barber discusses the pitfalls of over-engineering platform infrastructure, particularly for mid-sized companies. He shares insights from his experience at NASA's Jet Propulsion Laboratory, emphasizing the importance of right-sizing infrastructure to match team needs and capacity. The episode covers the build versus buy framework, the challenges of internal tooling, and the significance of documentation and automation in maintaining efficient operations.

9. 

   9 Nov 2025

   How to Sunset a Legacy System Without Destroying Team Morale

   Summary In this conversation, Tom Barber discusses the challenges organizations face when dealing with legacy systems and the importance of recognizing the human element in system migration. He emphasizes that migration is not just a technical project but a transition that impacts people's identities and roles within the organization. Takeaways Think about your current environment for a second. Do you have systems running that are older than some of your engineers? Maybe it's that monolithic application written in a language nobody wants to touch. Maybe it's hardware that needs special handling. Or maybe it's just tribal knowledge locked in the heads of three people. Not if, but when, that time comes. You can treat it like a purely technical project. It's a transition that affects people's identities. A transition that affects people's identities, their expertise. Their sense of value to the organization. (00:00) - Intro (00:32) - Title (01:16) - The Challenge of Sunsetting Legacy Systems (06:11) - Principals for Successful Legacy Migration (12:04) - Creating a Culture of Evolution

10. 

    9 Nov 2025

    The First 90 Days of Your Modernization Initiative

    Summary In this episode of Engineering Evolved, Tom Barber discusses the critical first 90 days of a modernization initiative for engineering directors. He emphasizes that success is not solely about technology but about understanding the business pain, building trust, and navigating organizational dynamics. The episode provides a week-by-week action plan, highlighting the importance of quick wins, effective communication, and avoiding common pitfalls in modernization efforts. Takeaways The first 90 days will make or break your initiative. It's about trust, momentum, and not declaring war on allies. Understand the business pain that led to your hiring. Your job isn't to fix everything but to prove you can be trusted. Conduct a 10-day discovery sprint to clarify needs. Weeks one and two should focus on listening and mapping. Identify a quick win that builds credibility. Stay engaged during the execution of the quick win. Communicate your vision and reset expectations with leadership. Avoid common pitfalls like ignoring the human side of technology. (00:00) - Intro (00:31) - Title (01:13) - The Crucial First 90 Days (07:48) - Week-by-Week Action Plan (14:10) - Communicating the Vision (19:49) - Conclusion and Next Steps

11. 

    9 Nov 2025

    DevOps for the Skeptical VP: Building Your Business Case in 30 Minutes

    Summary In this conversation, Tom Barber discusses the challenges of managing feature requests and the importance of strategic deployment to enhance team efficiency. He emphasizes the need to prioritize time-consuming tasks to free up valuable hours for the team, ultimately leading to increased productivity without additional hiring costs. Takeaways We are overwhelmed with feature requests. Starting with the most time-consuming deployment is crucial. Every deployment can save significant time for the team. Strategic deployment can lead to substantial time savings. Freeing up hours can feel like hiring another engineer. Time management is essential in engineering teams. Prioritizing tasks can improve overall productivity. Efficient deployment processes are key to success. Reducing deployment time can enhance team morale. Investing in efficiency pays off in the long run. (00:00) - Intro (00:50) - Title (01:33) - Introduction to DevOps ROI Challenges (05:29) - Building a Compelling Business Case (13:25) - Handling Objections Effectively (19:34) - Post-Approval Steps and Checkpoints

12. 

    9 Nov 2025

    Cloud Migration Without the Chaos - A Product Manager's Approach

    Summary In this episode of Engineering Evolved, Tom Barber discusses the critical aspects of cloud migration, emphasizing that many migrations fail due to poor planning and execution. He contrasts successful migrations, like Netflix's, with failures like TSB Bank's, highlighting the importance of treating migration as a product launch. Barber introduces the Strangler Fig pattern as a preferred migration strategy, outlines the six Rs of cloud migration, and stresses the need for effective communication and monitoring during the process. He also provides rollback strategies and discusses the importance of chaos engineering in ensuring resilience against outages. The episode concludes with key principles for successful cloud migration, urging listeners to prioritize discipline over speed. Takeaways Half of all cloud transformations are abject failures. Successful migrations treat infrastructure like a product launch. Big Bang migrations are no longer viable. The Strangler Fig pattern allows for gradual migration. Companies should focus on replatforming rather than refactoring. Product managers should lead migration efforts, not project managers. Rollback strategies are crucial for successful migrations. Monitoring during migration is essential to avoid blind spots. Communication failures can lead to migration disasters. Speed in migration can lead to costly mistakes. (00:00) - Intro (01:02) - Title (01:45) - The Cost of Cloud Migration Failures (09:06) - The Six Rs of Application Migration (14:21) - Fall Forward Architecture and Recovery Strategies (18:54) - Monitoring During Migration (28:25) - Communication Strategies for Successful Migration

13. 

    9 Nov 2025

    The Three Types of Technical Debt Your Finance Team Actually Cares About

    Summary In this conversation, Tom Barber discusses the significant impact of technical debt on American companies, highlighting that it costs them $1.5 trillion annually. He emphasizes that many executives are unaware of this issue, which often remains hidden within organizations, particularly in engineering payroll. Barber explains how technical debt can lead to lost deals and increased risk exposure, likening it to a ticking time bomb that can have severe consequences when it detonates. Takeaways Technical debt costs American companies $1.5 trillion annually. Most executives are unaware of the impact of technical debt. Technical debt is an invisible concept for many organizations. C-suite executives often do not understand technical debt. Technical debt hides within engineering payroll. It contributes to losing deals to faster competitors. Technical debt increases risk exposure for organizations. It's like a ticking time bomb within companies. The consequences of technical debt can be severe. Addressing technical debt is crucial for organizational success. (00:00) - Intro (00:27) - Title (01:10) - Understanding Technical Debt (09:43) - Revenue Blockers and Their Impact (21:18) - Operational Drain: The Hidden Costs (27:06) - Catastrophic Risks Of Ignoring Technical Debt

14. 

    9 Nov 2025

    The Architecture Decision Framework - When You Actually Need Microservices (Spoiler: Probably Not Yet)

    Summary Most midsize companies are making terrible architecture decisions because they're copying Netflix instead of solving their actual problems. This episode cuts through the hype and gives you a practical framework for deciding when you need microservices, when you don't, and everything in between. We talk about why "microservices" is a terrible name that encourages bad decisions, the five factors that should actually drive your architecture choices, and the spectrum of options between monolith and distributed systems that nobody tells you about. Plus, specific signals that tell you when it's actually time to evolve. In This Episode: Why a 12-person team with 47 services is a disaster waiting to happen, and what they did to fix it. The naming problem with "microservices" and how chasing "micro" destroys your ability to ship. Why that address CRUD service with its own database and deployment pipeline is architectural malpractice. The distributed transaction nightmare: how turning a 50-line function into seven networked service calls creates a distributed systems PhD thesis. The five-factor framework: team size and structure, deployment frequency and blast radius, data ownership and consistency, independent scalability needs, and technology heterogeneity. Conway's Law isn't a suggestion, it's gravity: why your architecture will mirror your org chart whether you want it to or not. The rule of thumb for team size: 1-5 engineers means monolith, 5-15 means modular monolith, 15-30 means a few services, 30+ means you can start thinking about real service-oriented architecture. Why deploying all 12 services together with the same version number means you have a monolith with extra steps. The data partitioning trap: when placing an order requires coordinating across seven services, you've created distributed transaction hell. Why "we want to scale differently" usually isn't a good reason to split services, but video transcoding versus API serving actually is. The polyglot tax: every additional technology stack means different tools, longer onboarding, harder on-call, and ongoing costs forever. The modular monolith: the sweet spot for most midsize teams with strong internal boundaries but simple deployment. How to use tools like ArchUnit and dependency-cruiser to enforce module boundaries and make your CI fail when someone violates them. The Majestic Monolith plus strategic services pattern: keep the core together, extract two to five services for specific reasons only. Self-contained systems: why thinking in complete vertical slices (Customer Portal, Checkout System) beats thinking in technical services (User Service, Order Service). The four breaking points that signal it's time to evolve: deploy coordination hell, team bottlenecks, scaling waste, and blast radius pain. Why "the code is messy" is a refactoring problem, not an architecture problem, and Shopify ran on a monolith to billions in GMV. The hardest lesson: complexity is easy to add, simplicity is hard to maintain. (00:00) - Intro (00:37) - Title (01:19) - Understanding Microservices and Their Misconceptions (09:43) - Framework for Architectural Decisions (18:54) - Evaluating Factors for Microservices (28:22) - Signals for Architectural Evolution

15. 

    9 Nov 2025

    Cross-Functional Teams vs. Feature Factories: What's Actually Different?

    Episode Summary Are your "cross-functional" teams actually just a feature factory in disguise? In this solo deep-dive, I break down the real differences between truly empowered teams and organizations that just reorganized the boxes on an org chart. You'll learn how to measure true cross-functionality, spot the warning signs you're still running a feature factory, and get concrete strategies to transform your teams. What You'll Learn The Real Definition of Feature Factory – It's not about org structure; it's about how decisions get made and what gets measured Five Capabilities That Define True Cross-Functionality: End-to-end ownership of customer value streams Real decision authority in their domain Direct customer access and learning loops Complete skill set without external dependencies Clear outcomes (not just a backlog) Eight Red Flags You're Still Running a Feature Factory: Your roadmap is a Gantt chart Teams are measured on velocity Product managers act like project managers Engineering estimates drive prioritization "Alignment meetings" happen weekly Features ship but metrics don't move Teams can't say no to stakeholders "We can't because..." is a common phrase Three Frameworks to Measure Cross-Functionality: Team Autonomy Audit Dependency Debt Score Outcome Ownership Matrix Six Transformation Strategies That Actually Work: Start with outcomes, not structure Do a dependency purge Change what you measure Train PMs to be outcome owners Create strategic buffers Fix your incentives (00:00) - Intro (00:54) - Title (01:36) - Understanding Cross-Functional Teams vs Feature Factories (05:54) - Key Characteristics of True Cross-Functional Teams (13:26) - Identifying Red Flags of Feature Factories (20:01) - Measuring Cross-Functionality in Teams (27:09) - Empowering Teams for Success

16. 

    9 Nov 2025

    The Product Thinking Framework

    Most engineering leaders would fail miserably as product managers. They'd get fired for shipping features nobody wants, ignoring user feedback, and measuring the wrong things. But here's the thing - your engineering team IS a product. And the techniques you use to build great products are exactly what you need to build a great engineering organization. In this episode, I break down the Product Thinking Framework: a radically different approach to engineering leadership that will change how you think about your team forever. In This Episode: Why most engineering improvements fail (and the shocking similarity to shipping features nobody asked for) The uncomfortable truth: Engineering leaders make decisions about tools and processes without understanding what engineers actually need Real story: The team drowning in infrastructure that thought they needed more people (spoiler: they didn't) Pillar One - Product Discovery for Engineering: How Engineering Office Hours helps you uncover what your team actually needs Pillar Two - Customer Empathy: Why you should spend a full day working as an IC on your own team (quarterly) Pillar Three - MVP Approach to Infrastructure: How to cut any project down to a 2-4 week learning experiment The microservices migration that would have cost millions (and what we did instead) The mindset shift: From manager to product manager - falling in love with problems, not features Measuring outcomes (shipping speed, learning, enjoyment) not outputs (story points, commits) Common objections: "My engineers don't know what they want," "We need long-term thinking," "I don't have time" Real results: The team that went from 3-day deployments to 30 minutes without hiring anyone Key Takeaways: 1. Set up Engineering Office Hours One hour per week, open attendance for any engineer Focus on discovery, not problem-solving in the session Ask: "What's slowing you down?" and dig deeper with "Tell me more" Share action items within 48 hours 2. Shadow your engineers quarterly Spend a full day working as an IC on your team Use their tools, follow their processes, feel their friction Every minute of frustration reveals a system problem to fix 3. Cut infrastructure projects into MVP experiments Take your biggest project and cut it in half, then half again Find something completable in 2-4 weeks that teaches you something Focus on learning what you need, not delivering what you planned 4. Measure outcomes, not outputs NOT story points, lines of code, or number of commits INSTEAD shipping speed, learning rate, work enjoyment, retention Sometimes the best way to improve outcomes is to do less 5. Iterate constantly on your team Your team is never "finished" - it's a product requiring ongoing improvement Always maintain a backlog of team improvements Ship small changes frequently vs. big transformations rarely (00:00) - Intro (01:03) - Title (01:45) - Engineering Teams as Products (05:32) - Product Discovery for Engineering (11:11) - MVP Approach to Infrastructure (16:55) - Iterative Improvement in Engineering (22:32) - Addressing Common Objections

17. 

    9 Nov 2025

    How I Accidentally Became A Modernization Director

    Nobody wakes up wanting to be a modernization director. In this deeply personal episode, I share my journey from writing simple code at NASA JPL to leading complex system transformations at a fintech startup—and the expensive failures that taught me everything about modernization leadership. You'll hear the story of two catastrophic failures: turning atmospheric science research code into a production web portal, and failures with month end reporting systems as a junior developer. They taught me lessons that no certification or consultant ever could. If you've ever had a "works on my machine" moment turn into a deployment disaster, this episode is for you. Key Topics Covered The MATLAB Trap: Why research code and production code are fundamentally different The Spark Mistake: When choosing the "industry standard" technology kills your product Product vs Platform: The critical decision that determines deployment success The Ego Test: How admitting failure defines modernization leadership Four Core Lessons: Future state thinking, maintainability, embracing failure, knowing when to pivot Key Takeaways Lesson 1: Always Think About the Future State Before writing a single line of code, ask: Where will this actually run? Who will maintain it? What happens when things fail? The gap between "works in dev" and "works in production" gets baked in at the architecture stage, not discovered at deployment. Lesson 2: You Can't Deploy Something Impossibly Hard to Maintain Elegant architecture means nothing if the team who has to run it can't understand, debug, or update it. Build for the maintainers, not for the architects. Meeting requirements includes sustainability. Lesson 3: Empower Developers to Test and Embrace Failure The best modernization teams fail early, fail small, fail visibly, and learn fast. Create realistic test environments. Give permission to break things. Make failure a learning opportunity, not a career-limiting move. Lesson 4: Know When You're Going Down the Wrong Path—and Admit It The worst thing in modernization is forcing a bad approach because you're too proud to pivot. Recognize the signs: projects that keep slipping, workarounds that multiply, excuses about the environment. Have the courage to stop, reassess, and choose a different path. Sometimes the right answer is the simpler tool that works everywhere, not the sophisticated tool that requires expertise to deploy. (00:00) - Intro (00:00) - Chapter 2 (01:09) - Titles (01:52) - The Dangers of 'It Works On My Machine' (07:07) - Lessons from NASA JPL (13:06) - The Reality Of Production Environments (20:19) - Common Problems in Mid-Sized Companies (25:30) - Learning from Failures and Successes

18. 

    9 Nov 2025

    Escaping Technical Purgatory

    Why Mid-Sized Companies Are Stuck (And How to Break Free) You've achieved product-market fit. You're generating real revenue. You have 200-1000 employees and a tech team of 20-150 engineers. You're not a startup anymore—but you're also not Google. And you're stuck in hell. The VP of Engineering reads all the right blogs, follows all the thought leaders, and decides to implement microservices like Netflix. Six months later, deployments take longer, bugs multiply, engineers threaten to quit, and leadership is asking why you just spent half a million dollars to make things worse. This isn't incompetence. This is the reality of being in the missing middle—too big for startup playbooks, too small for enterprise frameworks. In this episode, host Tom Barber breaks down: The 6 types of debt suffocating your company: code, documentation, process, architecture, testing, and knowledge debt Why startup methodologies fail at scale (and destroy your company faster) Why enterprise playbooks will kill you just as quickly (change advisory boards, anyone?) How to build your own playbook with three critical questions every leader must ask Stop trying to copy Spotify. Stop implementing frameworks designed for 10,000 employees. Start building systems that match your actual reality. Perfect for: CTOs, VPs of Engineering, and technical leaders at mid-sized companies who are tired of advice that doesn't fit their world. (00:00) - Intro (01:01) - Titles (01:44) - Techincal Purgatory (05:37) - Why Startup Methodologies Fail At Scale (12:25) - The Importance Of Documentation And Ownership (22:14) - The Pitfalls Of Enterprise Engineering Playbooks (30:45) - Building Your Own Playbook

Reach and audience

Public platform figures. Ratings count people who left a rating, not total listeners.

Spotify

5.0 / 5

1 ratings

Contact Engineering Evolved

Guest appearances

Books guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.