Scaling an IoT platform from 4 to 15 FTEs while delivering CHF 18M in savings sounds like a success story. It was but only after costly mistakes. This talk shares the reality behind connecting 10K+ coffee machines: underestimating Swiss change management timelines, getting blocked by embedded team dependencies, discovering you can't develop people as fast as you scale, and the painful trade-offs between refactoring and growth. Real numbers, real failures, real lessons for anyone building data products in traditional industries.

Target Audience: Product Managers, Data Team Leads, and Platform Architects scaling teams in traditional industries
Prerequisites: Leading or contributing to data/platform teams in established organizations (corporate or scale-up). Facing challenges around team scaling, stakeholder management, or technical-organizational trade-offs.
Level: Basic

Extended Abstract:
The Context

Thermoplan AG, a Swiss B2B coffee machine manufacturer, needed to transform its IoT platform to serve 10,000+ connected professional machines worldwide. As Head of Digital Products, I scaled the team from 4 to 15 FTEs and delivered CHF 18 million in cost savings through platform modernization. 

The Mistakes That Shaped Our Success

Coming from fast-paced consulting and Big 4 backgrounds, I assumed change management would follow predictable patterns. In Swiss manufacturing culture, consensus-building takes significantly longer than in startup or consulting environments. What looked like resistance was actually a different decision-making rhythm. Learning to work with this—not against it—became critical for sustainable transformation.

IoT platforms don't exist in isolation. Our data products depended on embedded firmware teams and hardware engineering constraints. These dependencies created bottlenecks we hadn't planned for. I'll share how we adapted our roadmap, built cross-functional bridges, and learned to make progress despite dependencies we couldn't control.

You can hire 15 people, but you can't instantly develop 15 senior contributors. The gap between headcount growth and actual capability growth was painful and costly. We made hiring mistakes, struggled with knowledge transfer, and learned hard lessons about team composition, onboarding, and when to slow down hiring to focus on development.

Every growing platform faces this: do you refactor for scalability or ship features to prove business value? We chose wrong several times. I'll share the specific moments where technical debt caught up with us.

What You'll Take Away

• Realistic timelines for organizational change in traditional industries
• Strategies for navigating cross-functional dependencies in hardware-adjacent contexts
• A framework for team scaling that accounts for actual capability development, not just headcount
• Decision criteria for the scaling vs. refactoring trade-off

Why This Matters

Most conference talks share the polished success story. This session shares the messy middle—the part where real learning happens. If you're building data products in established organizations, facing hardware dependencies, or scaling teams faster than you're comfortable with, these mistakes will save you time, money, and credibility with your stakeholders.