Building teams through empathy and clear principles. From 1-hour standups to high-velocity squads.
When I joined Kixie, the engineering team was struggling with coordination. Twenty-three people would gather on Zoom every morning, cameras mostly off, for standups that stretched past an hour. Everyone was busy. Nothing was shipping.
These were talented engineers. They'd built a platform handling 100 million minutes of calls. But somewhere between a major outage and the risk-averse processes that followed, they needed better structure. They needed product leadership to help them focus.
System reliability and call features
Integration stability and partnerships
Reporting and account management
My first standup at Kixie lasted 63 minutes. Twenty-three people on Zoom, all in the same office. Each person recited yesterday's work and today's plan. Nobody asked questions. Nobody offered help. When someone mentioned a blocker, the response was silence.
After the meeting, I checked Jira. The oldest ticket in the active sprint was 127 days old. It had been moved through six sprints. The description read "investigate performance issue." No acceptance criteria. No updates. Just a trail of sprint-to-sprint migrations.
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
Three months before I arrived, a production incident highlighted critical gaps in our deployment process. The recovery took considerable time and impacted service availability. Leadership made it clear that reliability was now the top priority.
The team responded by extending QA cycles and batching releases. Deployments moved to weekends with the entire team on call. When I suggested more frequent, smaller releases, there was skepticism. One senior developer explained their perspective: "This is how we ensure stability."
The risk-averse processes had created deployment bottlenecks. Large releases actually increased risk. Extended cycles meant issues stayed in production longer. Weekend deployments led to fatigue. We needed to transform how we thought about releases.
The engineers were talented. They cared about the product. They wanted to ship quality code. The system failed them. Without clear ownership, defined processes, or shared agreements, every day felt like swimming upstream. They needed structure that enabled autonomy, boundaries that created freedom, and most importantly, leadership that understood their challenges.
Three focused squads. Clear ownership. Shared agreements. Real accountability.
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.
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.
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."
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 created agreements that everyone understood and accepted. Written by the team, for the team.
These agreements applied to everyone. Engineers, product managers, leadership. No exceptions. When someone violated an agreement, we addressed it immediately with empathy and clarity.
We established clear processes that made sense for our context. Every story had to meet specific criteria before entering a sprint.
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.
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.
Established product management function at Kixie from the ground up
Designed and implemented verticalized squad organization
Moved teams from ad-hoc to structured sprint methodology
Hired 3 PMs and coached an engineer's transition to product management for CRM squad
Built bridges between engineering, support, and sales teams
Defined sprint processes and quality standards for all teams
Facilitated creation and adoption of team working agreements
Measurable improvements in velocity, quality, and team satisfaction
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.
Transform your engineering organization with empathy, clear principles, and measurable results.