How the Complexity Ceiling (almost) broke me and my Team

And how I learned to scale

At 47 Engineers, Everything Broke

At 47 engineers, the Silverlight engineering team broke. Not the code. Not the product. The entire system of how we worked.

I was driving home from Microsoft one evening in the pouring rain. I was exhausted and bone-tired. What was wrong?

That's when it hit me: we'd grown from a tight team that could fit in one room to something I no longer recognized. And I was failing to lead it.

Let me take you through how we got there, because if you're scaling an engineering team, you're going to hit the complexity ceiling as well. The only question is whether you'll see it coming.

The Early Days: When Everything Just Works

When I started building Silverlight, we had 4 engineers. By the time we hit 10, life was still good. Morning scrums were quick. Everyone knew the entire codebase. When someone hit a blocker, I could jump in and help solve it. We'd allocate work during sprint planning, and it just... happened. Naturally. Collaboratively.

At this size, I could still write code between my managerial duties. This kept me close to the architecture, built trust with the team, and honestly? It was fun. We all fit in one conference room. Decisions happened fast. We were shipping.

The First Growing Pains (10-30 engineers)

Growing from 10 to 20 engineers meant I spent most of my time hiring. We needed 40-50% growth in six months to hit our timeline. No choice.

I did whatever it took. Built recruiting posters with our Silverlight logo, bold "WE'RE HIRING" text that stood out. Then I spent 9-10 hours putting them in every building on Microsoft campus. Every. Single. Floor.

When our internal recruiter told me some general managers were complaining about my aggressive recruiting tactics, I promised to take them down. Then when complaints kept coming, I played dumb. "Oh, those must be leftover posters from buildings I haven't gotten to yet." Sometimes you bend the rules when you're building something important.

But at 20 engineers, cracks started showing. Morning scrum suddenly took too long. Should we do scrum of scrums? Sprint planning with everyone in the room became inefficient. Communication gaps emerged.

By 30 engineers, I finally accepted what I'd been resisting: I needed a layer of managers reporting to me. The "flat is better" philosophy only works to a point. Beyond that point, you need structure, whether you like it or not.

The Complexity Wall (30-50 engineers)

Then came the real challenges.

We were now shipping multiple products: Silverlight the plugin, Windows XAML, Silverlight for Windows Phone. Different teams working on vNext components in parallel, leapfrogging each other. The integration costs were brutal. My engineering manager spent months merging forked codebases, fighting a battle he didn't even believe in.

The cultural dynamics between our partner teams became a challenge. The Windows Phone team were renegades, 'old-school' Microsoft work-hard/play-hard. The Windows team at the time was established and methodical, with prescriptive ideas about how software should be built. And they refused to work with each other, which in hindsight was an incredible mistake. We sat in the middle, trying to bridge these worlds while building our own product.

Even celebrating wins became a minefield. Once, I sent out different recognition emails tailored to each team's accomplishments. Engineers literally diff'd the emails and complained about the differences. A team working on a rich-text editing component felt undervalued compared to the more visible platform team.

Annual reviews turned into verbal fights. How do you value the contribution of the mobile team killing themselves on features that hadn't shipped yet, versus the mainline team steadily delivering? There's no good answer, only trade-offs that leave someone angry.

The Breaking Point

The worst part? Every technical decision now required my input. The parser rewrite. The layered property system. How to surface object-oriented properties in WinRT. These weren't quick decisions. There were deep, complex, multi-week debates.

I was in back-to-back meetings from 8am to 6pm. No time to think. No time to step back. Just racing from crisis to crisis, decision to decision.

My executive coach helped me realize something crucial: I'm an introvert, and people exhaust me. Yet I'd built a calendar with zero space to recharge. No wonder I was burning out.

Breaking Through

It took 12-18 months to break through that complexity wall. Not weeks. Not a quarter. Over a year of systematic changes:

1. Team alignment that meant something. Not just org charts, but clear ownership, clear interfaces between teams, and most importantly, clear shared goals that everyone understood.

2. Decision frameworks. Instead of every technical decision escalating to me, we created frameworks for how decisions get made, who makes them, and when I need to be involved.

3. Personal sustainability. I started blocking "white space" on my calendar. Longer lunch blocks. Walking meetings. Time to think instead of just react.

4. Accepting the mess. Some problems don't have clean solutions. The mobile team versus mainline team tension? We never fully solved it. We just got better at managing friction.

The Pattern You Can't Escape

Here's what nobody tells you: every engineering organization hits a complexity wall as you scale-up. It's not about your talent, your product, or your market. It's about fundamental human coordination limits.

At 10 people, coordination happens naturally. At 20, you need some process. At 30, you need structure. At 40-50, your entire work-operating system breaks and needs an upgrade.

You can't skip this phase. You can't "culture" your way through it. You can't hire your way past it. You must rebuild how your organization works, and it's going to take longer than you think.

The Other Side

We eventually scaled Silverlight to 87 engineers, shipping 5 major releases. The technology became the foundation for Windows UI experiences used by 1.4 billion people today. Our framework powers the Start Menu, File Explorer, and signature Windows apps like WhatsApp and Apple Music.

But the real victory wasn't the product. It was learning that scaling isn't about adding more people to do more work. It's about completely reinventing your organization every time you double in size.

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

If you're somewhere between 30-50 engineers and feeling like everything's harder than it should be, you're not imagining it. You've hit the complexity wall. The question isn't whether you'll get through it, but how much time and pain it'll cost you.

I help engineering leaders navigate this transition faster because I've already made all the mistakes. Sometimes knowing the pattern is half the battle.