Home
Categories
EXPLORE
True Crime
Comedy
Society & Culture
Business
TV & Film
Sports
Health & Fitness
About Us
Contact Us
Copyright
© 2024 PodJoint
00:00 / 00:00
Sign in

or

Don't have an account?
Sign up
Forgot password
https://is1-ssl.mzstatic.com/image/thumb/Podcasts211/v4/1d/b8/b4/1db8b476-9186-3b98-d3d8-f696983c04e6/mza_7381388784093259720.jpg/600x600bb.jpg
Engineering Evolved
Tom Barber
11 episodes
2 days ago
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.
Show more...
Technology
RSS
All content for Engineering Evolved is the property of Tom Barber and is served directly from their servers with no modification, redirects, or rehosting. The podcast is not affiliated with or endorsed by Podjoint in any way.
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.
Show more...
Technology
Episodes (11/11)
Engineering Evolved
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.

Show more...
2 days ago
37 minutes

Engineering Evolved
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
Show more...
1 week ago
18 minutes

Engineering Evolved
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
Show more...
1 week ago
22 minutes

Engineering Evolved
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
Show more...
1 week ago
23 minutes

Engineering Evolved
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
Show more...
1 week ago
33 minutes

Engineering Evolved
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

Show more...
1 week ago
31 minutes

Engineering Evolved
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
Show more...
1 week ago
32 minutes

Engineering Evolved
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
Show more...
1 week ago
29 minutes

Engineering Evolved
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
Show more...
1 week ago
29 minutes

Engineering Evolved
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
Show more...
1 week ago
28 minutes

Engineering Evolved
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
Show more...
1 week ago
39 minutes

Engineering Evolved
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.