Consolidating Three Siloed Teams

The Question

You've consolidated three siloed teams into one platform org. Walk me through how you identified who should stay vs. who needed to move on.

The Challenge I Inherited

In April 2022, I was promoted to Manager of Software Engineering. I was already leading the Platform Services team, and the promotion added responsibility for DevOps and SysOps—bringing three siloed teams under one manager.

About 12 people total across the three teams, but they operated completely independently with separate Jira boards, scrum masters, and priorities. The problem wasn't the people—it was the structure. DevOps and SysOps had been operating without real technical leadership for a couple of years, just scrum masters managing process. They were surviving, not thriving.

The Dysfunction

The silos created real problems. The most significant was rigid process walls. Scrum masters had drilled in "no ticket, no work," which meant when the Platform Services team needed help with a Terraform script, they couldn't just ask DevOps in Slack. They had to create a Jira ticket, wait for triage, wait for assignment—this could take weeks for what should have been a five-minute conversation.

Ownership of end-to-end processes was unclear. Take certificate renewals: SysOps purchased the cert, DevOps had Terraform scripts to deploy it, but who communicated with app teams about which ones could apply their own certs? Nobody really knew. Sites would go down because of expired certificates due to unclear handoffs.

The teams were constantly fighting fires, unable to complete work they'd planned during sprint planning. Platform Engineering handled operational support for other teams, which created unpredictable workloads that made sprint planning ineffective.

I'll be honest: my core competency was software engineering and architecture. I was familiar with DevOps and SysOps from the consumer side, but I wasn't deeply technical in those domains. I needed to assess people and processes in areas where I wasn't the expert.

How I Assessed the Situation

I spent my first several months listening. I attended their standups, reviewed their work, asked a lot of questions. I wasn't looking for who to fire—I was looking for what was broken in how they worked together.

What I found was that the people were capable. They weren't the problem. The structure was preventing them from being effective.

The Consolidation (January 2023)

About nine months in, I proposed consolidating the three teams into one Platform Engineering team. My director and CTO agreed immediately—they'd seen the dysfunction too.

Nobody left during the consolidation. This wasn't about removing people; it was about removing barriers.

I moved everyone to a single Kanban board with unified priorities. I told the scrum masters—who managed multiple teams across the organization—that I appreciated them holding things together, but we were moving away from separate sprints and they could focus on their other teams. They were actually relieved.

The team appreciated the change because it made their work easier. They could collaborate directly instead of navigating process walls. I also started going to bat for them, pushing back on unrealistic requests from other teams. My leadership backed me up, which built trust quickly.

Raising Standards (Mid-2024)

Being Actively Mentored, Myself

During this time I should note that I relied on my mentor Terence Kent a lot for advice. Early 2024 He became my director, which accelerated my and our team's growth. You're never too experienced or knowledgeable to be mentored!

For about a year and a half, I focused on making the consolidated team function well and building trust. Once we had that foundation, my director and I decided it was time to raise the bar.

Towards the end of my gig at MCG, I began codifying our expectations into an engineering handbook; a set of documented standards around security, quality, and delivery. The philosophy was simple: we build secure solutions that keep users safe, we deliver solutions that actually work as expected, and we don't sacrifice quality to hit arbitrary dates.

This meant specific expectations around:

• Observability: Logging, distributed tracing, metrics, and health checks built in from day one, not bolted on later
• Documentation: Solutions need to be maintainable by others, not just the person who built them
• Code quality: Reviewable, testable code with clear patterns
• Security by design: Not an afterthought

We didn't just hand people a document and expect compliance. We ran live sessions and workshops explaining how these standards affected their work and why they mattered. We provided templates, examples, and mentoring.

My Engineering Handbook

When I left MCG I decided I needed to create my own engineering handbook that I could take with me where ever I went. You can see it here: my-engineering-handbook. It's language/platform/cloud agnostic and should be applicable anywhere. Feel free to take it and tweak it for your team!

The Results

Most of the team embraced these standards. Nine out of twelve met them, and several told me the standards made working together easier and built confidence. After-hours on-call incidents dropped by mid-2025.

The outcomes backed this up: the MIDS improvements came from this team. We also eliminated planned downtime and migrated 2,000+ sites to Azure.

The Difficult Part

Despite extensive coaching and support, three people couldn't adapt to the new standards. This wasn't about effort—they tried. It was about capability gaps we couldn't close.

We worked with each person for over a year, providing mentoring, clear feedback, documentation of expectations, and opportunities to improve. When it became clear they couldn't meet the bar, we worked with HR to provide soft landings and support their transitions.

This was the hardest part of the role. I don't take terminations lightly. But maintaining standards means everyone needs to meet them, and it's not fair to the high performers to lower the bar.