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

1. Absence of Trust - Vulnerability-based trust, not competence trust
2. Fear of Conflict - Artificial harmony vs. productive disagreement
3. Lack of Commitment - What happens when people don't feel heard
4. Avoidance of Accountability - When standards become suggestions
5. 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

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

1. Complexity: Even cloud vendors are building products to hide Kubernetes
2. YAML Everything: Config management becomes a people and process problem
3. Cost at Scale: Engineering hours, infrastructure, and mental health costs
4. Developer Experience: High barrier to entry and friction in feedback loops
5. 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?

1. What specific problem are you solving?
2. Do you have dedicated team capacity?
3. What's your actual scale (services, teams, traffic)?
4. How frequently do you deploy?
5. 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
• Contact: 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

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.