Building teams through empathy & clear principles.

• People arrived late to standups because they knew nothing meaningful would happen
• Engineers worked on whatever seemed urgent, with no shared understanding of priorities
• Customer issues bounced between teams because nobody owned specific domains
• Product requirements lived in emails, Slack threads, and half-remembered conversations
• Releases were unpredictable, with no consistent cadence or quality bar
• Teams measured success by activity metrics rather than customer outcomes

We chose a streamlined approach: three autonomous squads, each owning a complete vertical slice of the product. This structure prioritized clear ownership and fast decision-making over complex matrix organizations. We eliminated inter-team dependencies to enable each squad to deliver value independently.

• Telephony. Everything voice-related — call quality, reliability, features.
• CRM. All integrations — Salesforce, HubSpot, data sync.
• Dashboard. Analytics, reporting, user management.

Product strategy. Each squad had their own product roadmap, sprint cycles, and success metrics. This autonomy enabled faster feature delivery and clearer accountability. Product managers could make decisions quickly without cross-team coordination overhead.

The roadmap includes evolution. By 2026, we’ll introduce cross-functional AI initiatives spanning all verticals. Voice AI will leverage CRM data. Predictive analytics will integrate telephony insights. But first, we established reliable delivery foundations.

When a customer reported a call quality issue, Telephony owned it completely. When Salesforce sync broke, CRM handled it alone. No confusion. No handoffs. No blocked tickets waiting for another team. Just clear ownership and accountability. The sophistication would come later. First, we needed to ship.

Squads without product leadership would fail. We needed three product managers, one for each squad. I hired two externally and made a bet on internal talent for the third.

The CRM squad story. For the CRM squad, I took a calculated risk. I promoted someone from our sales engineering team who had deep CRM expertise. He’d spent years working directly with customers on complex integrations, understood their pain points intimately, and had built relationships with our partner companies. Most importantly, he asked strategic questions: “Why are we building this?” not just “How?”

Every morning, 7:45 AM, we’d meet for coffee. Fifteen minutes. Not status updates, but product philosophy discussions. “A customer called support about this,” I’d say. “What would you do?” Initially, his answers focused on implementation. Gradually, they became strategic. “We could fix the symptom,” he’d say, “or we could redesign the flow to address the root cause.”

Coaching philosophy.

• Daily touchpoints. 15-minute morning check-ins to discuss decisions, not tasks.
• Learning by doing. Started with small product decisions, gradually increased scope.
• Safe failures. Created space to make reversible mistakes and learn from them.
• Customer exposure. Joined support calls to hear real user problems firsthand.

Three months in, he ran his first sprint planning alone. I sat in the back, silent. He asked every question I would have asked. Six months in, the CRM squad had the highest velocity and customer satisfaction scores. The sales engineer who knew CRM setups inside and out had blossomed into a strategic product leader, presenting roadmaps to the board. The CEO pulled me aside afterward: “Where did you find him?” I smiled. “He was always here. We just gave him the right role.”

We established clear processes that made sense for our context. Every story had to meet specific criteria before entering a sprint.

Story requirements.

• Clear business context explaining why this matters
• Testable acceptance criteria
• Dependencies and assumptions documented
• Product owner approval before sprint planning

Definition of done.

• Acceptance criteria met and validated
• Product owner approval received
• Customer-facing documentation updated
• Staged for release with feature flags configured
• Success metrics and tracking in place

Every Friday at 3pm, we gathered for demos. Not status updates. Live demonstrations of working software.

Engineers showed what they built. Product gave feedback. Support shared customer reactions. Sales highlighted market needs. Everyone learned what others were working on and why it mattered.

These sessions built empathy across teams. Engineers understood customer pain. Product saw technical constraints. Support learned about upcoming features. The whole organization aligned around what we were building and why.

The production incident had made the team risk-averse about deployments. But larger, less frequent releases actually increased risk. We needed to decouple deployment from release and make rollbacks instant.

We implemented a sophisticated release strategy that separated deployment from release. Code ships continuously when ready. Customer-facing features release bi-weekly with a controlled 5-day ramp. This approach dramatically reduced risk while increasing velocity.

• Continuous deployment. Code pushed to production when ready.
• Bi-weekly releases. Customer features released every two weeks.
• 5-day ramp. Gradual rollout from 1% to 100% of users.
• Instant rollback. One-click reversion in 30 seconds.

The turning point. Week three with Harness. The new product manager on the CRM squad pushed his first major integration update. It broke for our largest enterprise customer. In the old world, this would have triggered panic calls, emergency meetings, and probably that promised “head rolling.”

Instead: click. Rolled back. 30 seconds. Customer never noticed. We fixed the edge case, deployed to 10 test accounts, verified the fix, then gradually rolled out to everyone. The new PM learned. The customer stayed happy. The CEO never knew.

Six months later, that skeptical senior developer came to me. “I was wrong,” he said. “This is how we should ship code.” Teams now deployed critical fixes during normal business hours with confidence.

The rip cord didn’t just change our deployment process. It changed our relationship with failure. Mistakes became learning opportunities instead of career-ending events. Teams started taking calculated risks because the downside was limited to 30 seconds of rollback time.

Every month, we sent a five-question anonymous survey through Officevibe. Simple questions: “Do you understand your team’s priorities?” (clarity), “Do you feel your work matters?” (purpose), “Would you recommend Kixie as a place to work?” (advocacy), “Do you have the tools to succeed?” (enablement), and “Do you trust your team?” (psychological safety). Each question scored 1–5. The average became our engagement score, providing clear signals about team health.

Every problem started with understanding. Why were people late to standups? Because they felt pointless. Why were tickets aging? Because nobody knew who owned them. Why was morale low? Because talented people felt trapped in dysfunction.

When the Telephony squad knew exactly what they owned, they stopped waiting for permission. When working agreements defined response times, people stopped wondering if they were being ignored. Clarity enabled autonomy.

We implemented Agile principles, but adapted them to our reality. Standups were 15 minutes because that’s what worked. Sprints were two weeks because that matched our release cycle. The best process is the one your team actually follows.

We stopped counting lines of code and started measuring customer outcomes. Sprint velocity meant nothing if we weren’t solving real problems. Team satisfaction scores mattered because engaged teams build better products.

The sales engineer I promoted to product management proved something important: talent exists everywhere in your organization. His customer expertise and CRM knowledge, combined with daily coaching sessions, transformed into strategic product leadership. Six months later, he was presenting roadmaps to the board. Investment in people compounds faster than any technology investment.

Two weeks to restructure into squads. Three weeks to implement our modern release process. Three months for teams to fully adopt the new practices. Six months to achieve the 92% sprint completion rate. The structural changes happened quickly, but cultural transformation took time. Once teams experienced the benefits of smaller, safer releases, adoption accelerated.

Building trust after the production incident. The team had become risk-averse and process-heavy. The turning point came with our first successful feature flag rollback — 30 seconds to revert, no customer impact. This proved that we could ship safely and frequently. As confidence grew, teams began taking ownership and innovating again.

We involved everyone in creating the solution. Engineers wrote the working agreements. Teams chose their own squad structures. People support what they help create. When someone resisted, we asked what would work better. Usually, they had valid concerns that improved our approach.

Sprint predictability told us if teams understood their capacity. Ticket age showed if we were solving the right problems. Team engagement surveys revealed if people felt heard and valued. Customer-reported bugs measured our quality. Every metric connected to either team health or customer success.

We borrowed from Scrum, Kanban, and Shape Up, but created something uniquely ours. Spotify’s squad model inspired our structure, but we adapted it for our size. Amazon’s working backwards approach influenced our PRDs. The framework that works is the one that fits your context.

The team needed clear ownership and fast decision-making. We eliminated inter-team dependencies so each squad could deliver value independently. No waiting, no blocked tickets, no coordination overhead. This structure was intentional. Once we established reliable delivery, we could evolve. By 2026, we’ll introduce cross-functional AI initiatives requiring squad collaboration. Voice AI will leverage CRM data. Predictive analytics will span all verticals. But first, we needed to establish strong foundations for independent delivery.