We Hit 50 Engineers and Everything Broke—Here's What I Wish I'd Known About the Scale-Up Transition

[cto_michelle]

I need to share something that’s been on my mind lately, and I suspect many of you have lived through this inflection point too.

We crossed 50 engineers last quarter. I should have been celebrating—we’d tripled the team in 18 months, closed our Series B, and the product roadmap was more ambitious than ever. Instead, I found myself in back-to-back firefighting meetings wondering why everything suddenly felt… broken.

The Complexity Wall Hit Like a Freight Train

Here’s what nobody told me: the communication paths don’t scale linearly. At 20 engineers, you have about 190 potential connections. At 50? Over 1,200. And by the time we hit 60 engineers, we were looking at nearly 1,800 communication paths.

What that looked like in practice:

• Features that used to take 2 weeks were now taking 6-8 weeks
• Our senior engineers were spending 80% of their time in alignment meetings
• A “simple” change to the checkout flow required coordination across 4 teams
• New engineers were taking 3-4 weeks just to understand who owned what

The processes that got us to 20 engineers—daily standups where everyone knew everyone, ad-hoc Slack decisions, informal code ownership—became active obstacles. Our informal culture that we were so proud of? It was creating chaos.

What Actually Broke (And It Wasn’t What I Expected)

Delivery Cadence: We went from shipping every day to shipping every two weeks. More engineers, slower output. The productivity paradox was real.

Engineering Culture: Our “everyone knows everything” culture became “nobody knows anything.” New hires were lost. Veterans were frustrated.

My Leadership Model: This one hurt the most. The hands-on, know-every-commit-message CTO approach that got us here? It was now the bottleneck. I had to fundamentally change how I led.

The Biggest Surprise: I Needed to Become a Different Leader

At Microsoft and Twilio, I’d seen this pattern before. But experiencing it as the CTO was different. The skillset that got you to 50 engineers—being technical, knowing the codebase, making quick decisions—that’s not what’s needed to scale beyond 50.

At 50+, it’s about:

• Building a leadership team, not managing engineers directly
• Shaping culture deliberately, not hoping it persists
• Designing organizational structure to enable autonomy
• Thinking in systems and second-order effects

I had to let go of reviewing architecture docs personally. I had to trust my Directors to make decisions I would have made differently. That was harder than any technical challenge I’d faced.

What We Changed (And What’s Still a Work in Progress)

Architecture Follows Organization: We split our monolith into domain-bounded services. Not because microservices are trendy, but because we needed teams to be able to ship independently. Conway’s Law is real—your architecture will determine your organizational structure whether you plan for it or not.

Federation Over Centralization: Instead of trying to coordinate 50 engineers, we created 4 autonomous business units of ~12-15 engineers each. Each unit operates like its own startup, with clear ownership boundaries and minimal cross-dependencies.

Written Decision Records: We introduced RFCs and architecture decision records. It felt bureaucratic at first, but it was the only way to scale decision-making beyond the people in the room.

Leadership Development: I promoted 3 engineering directors and 5 senior engineering managers. Building that leadership bench was more important than any technical decision.

Still Struggling With

• Onboarding velocity: New engineers still take too long to become productive
• Cross-team collaboration: How do you balance autonomy with collaboration?
• Cultural preservation: How do you maintain the “feel” of the early days when 70% of the team wasn’t there?
• Burnout rates: We’re seeing signs of burnout in our mid-level engineers who are caught between IC work and unofficial leadership

My Question to You

For those who’ve scaled past 50 engineers: What do you wish you’d done differently?

What processes did you introduce too late? Which ones did you introduce too early? How did you preserve what made your culture special while adapting to the realities of scale?

And for those approaching this inflection point: what are you most worried about?

I’m particularly interested in hearing from folks who’ve done this multiple times—are there patterns that work regardless of company or industry? Or is every scale-up journey unique?

---

Michelle Washington | CTO | Scaling engineering orgs and learning in public

[eng_director_luis]

Michelle, this resonates deeply. I’m living through a version of this right now at our financial services company—we’re at 42 engineers and I can already feel the strain points you’re describing.

The Conway’s Law observation hits particularly hard. We made the mistake of trying to scale our organization first without addressing the architecture, and it’s created exactly the coordination nightmare you mentioned. Our monolithic core banking system means every feature touches 3-4 teams, and we’ve become experts at scheduling alignment meetings instead of shipping code.

What We’re Doing Differently

We just started a measured migration to domain-bounded services—payments, accounts, lending, compliance—each with clear ownership. The key learning for us was starting with the business domain boundaries, not the technical ones. When we let the business logic dictate the split, team ownership became obvious.

The federated model you describe (4 autonomous units of 12-15 engineers) is exactly what we’re targeting. We’re calling them “capability teams” internally, and each one has:

• Full-stack ownership (frontend, backend, infrastructure)
• Dedicated product manager
• Clear customer or business outcome
• Quarterly OKRs they set themselves

The Cross-Cultural Dimension You Didn’t Mention

One thing I’d add: scaling across cultures and time zones adds another layer of complexity. We have engineers in Austin, Mexico City, and Manila. What worked was creating regional pods with full autonomy rather than distributing teams across time zones. The 12-15 engineer unit size you mentioned? We found 10-12 works better for remote-first teams.

Question on Leadership Transitions

You mentioned promoting 3 directors and 5 senior managers. How did you identify who was ready for that transition? We’re struggling with this—our best senior engineers aren’t necessarily the best managers, but they’re the ones everyone looks to for leadership. Did you promote from within or bring in external leadership talent?

Also curious: how did you handle the inevitable mistakes during the transition? I suspect some of those promoted leaders made decisions you had to unwind. How did you balance letting them grow through mistakes vs. protecting the business?

Thanks for sharing this so candidly. It helps to know the productivity paradox (more engineers = slower shipping) isn’t just us.

[vp_eng_keisha]

Oh Michelle, I feel this in my bones. I’m currently in the thick of it—we’ve gone from 25 to 80+ engineers in the last 16 months at our EdTech startup, and every single thing you described is happening simultaneously.

The stat that keeps me up at night: 70% of our engineers reported burnout symptoms in our last engagement survey. And our attrition rate jumped 35% year-over-year. That’s not sustainable, and it’s directly tied to the scaling chaos you’re describing.

The Hiring Speed vs. Culture Quality Dilemma

Your point about cultural preservation really strikes a chord. We’re hiring 5-7 engineers per month right now, which means by next quarter, 75% of the team will have joined in the last year. How do you preserve culture when the majority of people never experienced it?

Here’s what we’re trying:

Culture Carriers Program: We identified 12 “culture carriers”—not necessarily senior engineers, but people who embody our values—and gave them explicit responsibility for preserving culture during onboarding and team formation. They’re compensated for this work.

Onboarding Cohorts: Instead of individual onboarding, we batch new hires into monthly cohorts of 8-12 people. They go through a 2-week structured program together, build relationships, and get the “why we work this way” context. Our time-to-productivity dropped from 8 weeks to 4 weeks.

Values in Action Stories: We built a Slack channel where people share stories of seeing our values in action. It’s not corporate BS—it’s “Luis stayed late to help me debug even though it wasn’t his project” type stories. Makes values tangible.

The Data That Surprised Me

We started measuring cognitive load as a DevEx metric (alongside cycle time and deployment frequency). We ask engineers: “Do you have too many things to keep track of?” Turns out, this predicts burnout better than hours worked.

At 25 engineers, our cognitive load score was 6.5/10 (manageable). At 80 engineers? 8.7/10 (overwhelming). The complexity explosion is real, and it manifests as mental burden.

The Inclusive Hiring Challenge During Rapid Growth

Michelle, as another Black woman in tech leadership, I want to raise something hard: rapid growth makes inclusive hiring harder, not easier.

When you’re hiring 5+ people per month, the pressure to “fill seats” is intense. I’ve watched teams compromise on culture fit and diversity goals because “we just need bodies.” And once you hire 20 people who don’t reflect your values or your diversity goals, unwinding that is nearly impossible.

We implemented “hiring circuit breakers”—if our diversity metrics for any role fall below 30% underrepresented candidates in final rounds, we pause and reset the search. It slows us down, but hiring fast and hiring well aren’t the same thing.

My Question for You

You mentioned building a leadership team of 3 directors and 5 managers. How many of those leaders came from underrepresented backgrounds? I’m finding it really hard to build a diverse leadership bench at the pace we’re scaling. Did you promote from within or hire externally?

And candidly: how do you avoid the trap of promoting the people who “look like leaders” (which often means they look like existing leadership) vs. the people who actually have leadership potential?

Thanks for starting this conversation. It’s messy and hard, and we need more CTOs talking honestly about it.

[maya_builds]

Coming at this from the design side, but wow—everything you’re describing applies to design teams too, just at different scale points.

Our design team hit its breaking point at 12 people (not 50!), which tells you something about how design collaboration scales differently than engineering. But the pattern is identical: what got us here won’t get us there.

The Design Systems Parallel

Your comment about splitting the monolith into domain-bounded services? We had to do the same thing with our design system.

At 5 designers, we had one Figma file. Everyone knew where everything was, we’d just Slack each other about changes, and it worked great. At 12 designers across 3 product teams? That single source of truth became a source of chaos.

What broke:

• Designers making similar components in different corners of the file
• No clear ownership of which components were “official”
• Every design review turned into “why didn’t you use the existing button component?” debates
• New designers taking 2 weeks just to navigate our Figma org

What we changed:
We federated the design system. Each product team owns their domain-specific components. There’s a “core” team that maintains foundational stuff (typography, colors, basic buttons). But the product teams are autonomous within their domain.

Sound familiar? It’s Conway’s Law for designers.

The Craft Quality vs. Speed Tension

Here’s what keeps me up at night: as teams scale, the pressure to move fast often crushes the craft that made the product special in the first place.

At 5 designers, we could have thoughtful design critiques where we’d spend an hour on a single interaction. At 12 designers shipping for 50 engineers? Those critiques became “looks good, ship it” rubber stamps.

My failed startup taught me that losing craft kills products slowly. Users don’t leave immediately—they just stop caring. How do you preserve the quality bar when the volume demands keep increasing?

Question About Cross-Functional Scaling

Michelle, I’m curious about the product-design-engineering collaboration patterns as you scaled. At 20 engineers, our weekly “product trio” meetings (PM, design lead, engineering lead) worked great. At 50+ engineers with 4 autonomous units, how do you keep product and design aligned with engineering priorities?

Do each of your 4 autonomous units have dedicated product and design partners? Or do you have a centralized product/design team working across all units? We’re trying to figure this out and it feels like every option has downsides.

Also: how do you handle shared components and design patterns across autonomous units without creating a coordination nightmare?

Thanks for sharing this. It helps to know the scale-up pain isn’t unique to any one function. We’re all figuring this out together.

[product_david]

Michelle, this is exactly the conversation product leaders need to hear more of. The productivity paradox (more engineers = slower shipping) is something I see from the product side constantly, and it drives our executives crazy.

“We doubled the engineering team—why aren’t we shipping twice as fast?” has been the refrain at every board meeting for the last 6 months. Your post gives me the language to explain why that’s not how scaling works.

The Product Velocity Illusion

Here’s what I’ve observed across Google, Airbnb, and now at our Series B startup:

At 20 engineers: Product velocity is high because coordination cost is low. We can pivot quickly, try experiments, kill features that don’t work. The feedback loop from idea to shipped to learned is 2-3 weeks.

At 50 engineers: Product velocity tanks because coordination cost explodes. Every feature now requires:

• Alignment across 3-4 teams (like you said)
• Architecture review (because it might impact other teams)
• Security review (because we have dedicated security now)
• Design system review (to maintain consistency)
• Documentation updates (because 50 people can’t keep it all in their heads)

Same feature that took 2 weeks at 20 engineers now takes 8 weeks. Not because engineers are slower—because the organizational overhead is 4x higher.

The Product-Engineering Alignment Tax

One thing you didn’t mention that I’d add: product-engineering alignment gets exponentially harder as you scale.

At 20 engineers with 2 product managers, we’d have a weekly roadmap sync. 1 hour, everyone aligned, done.

At 50 engineers with 7 product managers across 4 autonomous units, alignment is a full-time job. We now have:

• Weekly product leadership sync
• Bi-weekly cross-team dependency mapping
• Monthly roadmap reviews
• Quarterly OKR planning

I spend 30% of my time just coordinating between product managers who need to align with engineering teams who have dependencies on each other.

The Strategy Question No One Asks

Here’s the uncomfortable question: should you actually scale to 50+ engineers, or should you constrain scope to what 20-30 engineers can build well?

I know that sounds heretical in growth-stage startups, but hear me out. You mentioned you went from shipping daily to shipping every 2 weeks with more engineers. What if the right move was to keep the team smaller and the scope tighter?

At Airbnb (when I was there), Brian Chesky famously said “do fewer things better” and actually reduced the product surface area while scaling engineering. It was controversial but it worked.

My Questions for You

1. How do you say no to features now? With 4 autonomous units, I imagine each one wants to build their roadmap. How do you prevent feature bloat and maintain a cohesive product vision?

2. What metrics changed? You mentioned velocity dropping. Did you change how you measure product success? Are you tracking different KPIs at 50 engineers vs. 20?

3. Product-engineering allocation: How do you decide which autonomous unit gets which features? And how do you handle features that span multiple units?

This is such an important conversation. Every product leader I know is dealing with some version of “we hired more engineers and shipping got slower.” Thanks for naming it explicitly.