Engineering Evolved

Tom Barber
  • 0.0 (0)
  • TECHNOLOGY

Where business meets innovation and technology drives transformation. Engineering Evolved 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 Engineering Evolved — 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.

Episodes

  1. 5D AGO

    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.

    37 min

  2. NOV 9

    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

    19 min

  3. NOV 9

    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

    22 min

  4. NOV 9

    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

    24 min

  5. NOV 9

    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

    34 min

  6. NOV 9

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

    SummaryIn 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

    32 min

  7. NOV 9

    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

    33 min

  8. NOV 9

    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 streamsReal decision authority in their domainDirect customer access and learning loopsComplete skill set without external dependenciesClear outcomes (not just a backlog)Eight Red Flags You're Still Running a Feature Factory: Your roadmap is a Gantt chartTeams are measured on velocityProduct managers act like project managersEngineering estimates drive prioritization"Alignment meetings" happen weeklyFeatures ship but metrics don't moveTeams can't say no to stakeholders"We can't because..." is a common phraseThree Frameworks to Measure Cross-Functionality: Team Autonomy AuditDependency Debt ScoreOutcome Ownership MatrixSix Transformation Strategies That Actually Work: Start with outcomes, not structureDo a dependency purgeChange what you measureTrain PMs to be outcome ownersCreate strategic buffersFix 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

    30 min

  9. NOV 9

    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 needReal 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 needsPillar 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 experimentThe 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 featuresMeasuring 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 anyoneKey Takeaways: 1. Set up Engineering Office Hours One hour per week, open attendance for any engineerFocus on discovery, not problem-solving in the sessionAsk: "What's slowing you down?" and dig deeper with "Tell me more"Share action items within 48 hours2. Shadow your engineers quarterly Spend a full day working as an IC on your teamUse their tools, follow their processes, feel their frictionEvery minute of frustration reveals a system problem to fix3. Cut infrastructure projects into MVP experiments Take your biggest project and cut it in half, then half againFind something completable in 2-4 weeks that teaches you somethingFocus on learning what you need, not delivering what you planned4. Measure outcomes, not outputs NOT story points, lines of code, or number of commitsINSTEAD shipping speed, learning rate, work enjoyment, retentionSometimes the best way to improve outcomes is to do less5. Iterate constantly on your team Your team is never "finished" - it's a product requiring ongoing improvementAlways maintain a backlog of team improvementsShip 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

    30 min

  10. NOV 9

    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 differentThe Spark Mistake: When choosing the "industry standard" technology kills your productProduct vs Platform: The critical decision that determines deployment successThe Ego Test: How admitting failure defines modernization leadershipFour Core Lessons: Future state thinking, maintainability, embracing failure, knowing when to pivotKey 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

    29 min
  11. Escaping Technical Purgatory

    NOV 9

    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 debtWhy 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 askStop 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

    40 min
  • 11 Episodes

About

Where business meets innovation and technology drives transformation. Engineering Evolved 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 Engineering Evolved — 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.

Information

  • Creator
    Tom Barber
  • Years Active
    2K
  • Episodes
    11
  • Rating
    Clean
  • Copyright
    © 2025 Spicule LTD
  • Show Website
    Engineering Evolved