We're a team of 5 trying to scale to 20. None of us have done this before. How do you break the chicken-and-egg loop?

[vp_eng_keisha]

Six months ago, I joined an EdTech startup as VP of Engineering. Coming from Google and Slack felt like a superpower—until I realized the team of 25 engineers I inherited had a problem I’d never actually solved myself at scale.

None of them had built engineering organizations beyond 10 people. Neither had I, really. At Google, I managed teams within an already-scaled system. At Slack, I inherited established processes. But here? We were building the scaffolding while the building was going up.

The Paradox

Here’s the thing that keeps me up at night: you can’t learn scaling skills without scaling, but scaling badly creates technical debt and cultural damage that’s incredibly hard to recover from.

Every blog post says “hire experienced leaders.” Every conference talk says “promote from within.” Every consultant says “it depends.” They’re all right, and they’re all incomplete.

What We’ve Tried (And What Happened)

Hired expensive “scaling expert” senior engineers: Mixed results. Two were phenomenal—they brought patterns we’d never seen, spotted problems before they became crises. One was a disaster—“at Netflix we did it this way” became the answer to everything, even when our problems were fundamentally different. Culture clash was real.

Sent team to conferences and training: Great for morale, mediocre for capability. Theory doesn’t translate to practice when you’re in the trenches. “Here’s how to structure engineering teams for growth” is useful until you realize your org chart needs to change in 6 months anyway.

Brought in consultants: Helpful but expensive. They diagnosed problems well, but once they left, the knowledge didn’t stick. We got recommendations, not capability.

The Current Dilemma

Our CEO wants to triple engineering headcount in the next 12 months. That means going from 25 to 80+ engineers.

Here’s what I’m wrestling with:

• Current engineering leads have never managed managers. I can coach them, but I’m learning this in real-time myself.
• The processes that work for 25 people (quick standups, everyone-knows-everything, shipping fast) will break at 80.
• We can’t afford to fail publicly during this high-growth phase. User expectations are high, competitors are fast, and our product-market fit window is narrow.
• I don’t know what I don’t know. And that’s terrifying when board members ask, “What’s your scaling plan?”

The Questions I’m Stuck On

Do you hire experienced leaders externally and risk culture clash? How do you assess if someone’s “scaling experience” will actually translate to your context?

Do you promote internally and provide intensive coaching/support? What does that support even look like? Exec coaches? Leadership training? Peer advisory boards?

Is there a middle path? Fractional CTOs? Embedded coaches? Rotational programs where people shadow leaders at other companies?

How do you build scaling muscle without breaking what works today? Our team is high-performing right now. How do I preserve that energy, that culture, that velocity—while fundamentally changing how we operate?

Being Honest

I’ll be real: this feels like building a plane while flying it. And I’m not sure I have the right blueprints.

I know the stats: 47% of platform engineering initiatives operate on budgets under M, and we’re trying to scale organizational capability on a similar shoestring. 93% of developers now use AI coding tools, but productivity gains haven’t budged past 10%—so tooling alone won’t save us.

For those who’ve navigated this successfully (or unsuccessfully—I’ll learn from both), how did you break the loop? What actually worked? What looked good on paper but failed in practice?

I’m all ears. And probably too vulnerable for a VP, but hey, if we can’t be honest here, where can we be?

[cto_michelle]

Keisha, I’ve been exactly where you are. At Microsoft in the mid-2000s when we were scaling Azure teams, and again at Twilio when we went from 200 to 800 engineers in 24 months. The chicken-and-egg problem is real, and it’s one of those challenges that looks simple from the outside and feels impossible from the inside.

Here’s what I learned, often the hard way: the answer isn’t hire OR promote—it’s a portfolio approach.

The 70-20-10 Framework

When I became CTO at my current company, we had a similar trajectory: 50 engineers to 120 in 18 months. Here’s what actually worked:

70% promote from within with structured support. This isn’t just “good luck, you’re a manager now.” It’s:

• Formal leadership development program (we partnered with a local university for an 8-week engineering leadership course)
• Peer coaching groups—new managers meet monthly to share challenges, no executives in the room
• Clear frameworks and playbooks: “Here’s how we do performance reviews. Here’s how we handle conflicts. Here’s our hiring rubric.”
• Every promoted manager gets an external executive coach for their first year (costs ~K/person, worth every penny)

20% strategic external hires at director+ level. Not to replace your people—to complement them. We hired:

• One Director of Infrastructure who’d scaled systems at Stripe
• One Director of Product Engineering who’d built PMF at multiple startups
• These weren’t “my way or the highway” leaders. They were culture-adds who brought pattern recognition without ego.

10% fractional/advisory expertise. This was the unlock I didn’t expect:

• Former CTO from a similar-stage company, 8 hours/month for 12 months, helped me think through org design
• Former VP Eng from Shopify, quarterly strategic reviews, helped us avoid scaling pitfalls
• Domain experts for focused engagements (DevOps transformation, engineering metrics, incident response culture)

Why This Works

Preserves culture and institutional knowledge. Your current team knows the product, the customers, the context. Don’t replace that.

Brings pattern recognition. External leaders who’ve seen the movie before can spot problems 3-6 months ahead. They’re worth their weight in gold if they have humility.

Creates learning without betting everything on untested managers. Your promoted managers aren’t learning alone—they have peers, coaches, and experienced leaders around them.

The Biggest Mistake

The biggest mistake I made—twice—was waiting too long to invest in leadership development.

By the time you feel the pain of poor management, you’re already 6 months behind. The engineering manager who’s struggling today probably needed coaching 6 months ago. The team dysfunction you’re seeing now started with a leadership gap you didn’t address last quarter.

Start building your leadership bench now. Don’t wait until the board asks for the scaling plan. Don’t wait until you’ve lost good engineers because their manager was overwhelmed.

One Actionable Thing You Can Do This Week

Start building your “scaling playbook” right now. It’s a living document that captures:

• Decisions you’ve made and why (“Why did we choose this on-call structure?”)
• Processes that work at your current scale (“How we run sprint planning with 25 engineers”)
• Problems you’ve solved (“How we handled the database migration without downtime”)
• Cultural norms you want to preserve (“What makes our team high-performing”)

When you promote managers or hire external leaders, this is their orientation. This is your institutional memory. Without it, every new leader re-invents the wheel or accidentally breaks something that worked.

Final Thought

You said you’re “too vulnerable for a VP.” I’d argue the opposite: vulnerability is leadership. The VPs who pretend they have all the answers are the ones who quietly fail while maintaining the facade. The ones who say “I don’t know, let’s figure it out together” are the ones who build resilient teams.

You’re asking the right questions. You’re being thoughtful about culture. You’re learning in public. That’s not weakness—that’s exactly the leadership your team needs during this transition.

You’ve got this.

[eng_director_luis]

Michelle nailed the strategic framework. I want to add a tactical layer from a slightly different angle.

I’m at a Fortune 500 financial services company—lots of process, hard to move fast. So our problem is the inverse: how do you scale capability without drowning in bureaucracy? But the core challenge is the same: how do you build organizational muscle when you’ve never lifted this weight before?

What Actually Worked (Tactical Implementations)

Coming from Intel and Adobe into financial services, I’ve seen scaling done well and done poorly. Here’s what worked when we went from 40 to 90 engineers in 18 months:

1. Peer Learning Circles

Instead of bringing in external trainers (expensive, generic), we created engineering leadership peer circles:

• 6-8 senior engineers who wanted to move into management
• Bi-weekly 90-minute sessions, rotating facilitator
• Real problems only: “I have an underperformer on my team, what do I do?” “Two of my engineers are in conflict, how do I mediate?”
• Created a safe space to admit “I don’t know” without career consequences

The magic: They learned from each other’s experiments in real-time. One manager would try a new 1-on-1 structure, report back, and others would adapt it. Organic knowledge transfer.

2. Rotational Programs

We implemented 6-month rotations where engineers spend time on different teams:

• A backend engineer rotates to infrastructure for 6 months
• A mobile engineer rotates to platform team
• Knowledge spreads organically—no single point of failure
• Engineers see different leadership styles, bring best practices back

Side benefit: Engineers who go through rotations make better managers because they understand cross-functional dependencies.

3. “Scaling Apprenticeships”

This was unconventional, but it worked: we paired our new engineering managers with senior leaders from other companies for quarterly advisory sessions:

• Reached out to my network at SHPE (Society of Hispanic Professional Engineers)
• Found 5 experienced EMs/Directors willing to mentor our folks
• 1-hour quarterly calls: “Here’s what I’m struggling with, what have you seen work?”
• Even paired one of our managers with a Director at a competitor (with both companies’ blessing)

Why this worked: Our managers got outside perspective without us having to hire expensive consultants. The mentors were doing it to give back to the community.

The Cultural Piece (First-Gen Perspective)

Here’s something that doesn’t get talked about enough: as a first-generation college graduate who became a Director of Engineering, one of the hardest barriers was learning to admit “I don’t know how to do this.”

In communities where you’re the first to reach certain levels, there’s pressure to have all the answers. “I made it this far, I should know this.” But that’s toxic.

The unlock: Creating a culture where saying “I’ve never done this before, let’s figure it out together” is a strength, not a weakness.

When I told my team, “I’ve never scaled an org from 40 to 90, but here’s what I’ve learned from mentors, here’s our plan, and we’ll adjust as we learn”—that vulnerability became permission for everyone else to be learners too.

Practical Timeline (If I Were You)

If I were in your shoes, Keisha, here’s what I’d do in the next 12 months:

Months 1-3: Build Internal Leadership Infrastructure

• Launch peer learning circles (pick 8-10 high-potential ICs/managers)
• Create your scaling playbook (as Michelle mentioned)
• Identify 2-3 advisory mentors from your network

Months 4-6: Strategic External Hires

• Hire 1-2 Directors with specific scaling expertise (infrastructure, product engineering)
• Make sure they’re culture-adds, not culture-replaces
• Pair them with internal rising stars for knowledge transfer

Months 7-12: Promote + Support

• Promote 3-4 internal managers with the peer circles + coaching in place
• Start rotational programs to spread knowledge
• Measure: time-to-onboard, deployment frequency, employee satisfaction

Final Thought

Scaling isn’t a one-time problem you solve—it’s a continuous capability you build.

The companies that scale well don’t just hire their way out of it. They invest in learning infrastructure: peer networks, mentorship, documentation, rotations. They make organizational learning a competitive advantage.

You’re not just scaling headcount, Keisha. You’re building a learning organization. That’s the real unlock.

[maya_builds]

Okay, I’m going to be the contrarian voice here (shocking, I know).

What if you don’t scale to 20?

Before everyone throws tomatoes: I’m not saying “never hire.” I’m saying question the assumption that scaling your business requires linearly scaling your team.

My Startup Scaling Disaster Story

I was co-founder/CPO at a B2B SaaS startup. We raised a Series A, and the board said “great, now scale the team.” So we went from 5 engineers to 18 in 8 months.

It broke us.

What actually happened:

• First 4 months: Hiring consumed all our time. Interviews, offers, negotiating, onboarding.
• Next 2 months: New engineers ramping up, asking questions, slowing down existing team.
• Final 2 months: Realized half weren’t the right fit. Cultural mismatch, skill mismatch, expectation mismatch.
• 6 months after that: We let 8 people go. Brutal. Expensive. Traumatic for everyone.

The team that shipped our best work? The original 7 who remained.

The Uncomfortable Question

Everyone assumes: growth = more people.

But here’s what I learned the hard way:

• 5 engineers with great tools can outperform 15 without. We invested in better CI/CD, automated testing, design systems. Velocity tripled.
• Complexity scales with team size. Every new person adds coordination overhead. At 18 engineers, we spent more time in meetings than building.
• Hiring is expensive and slow. Took us 4 months to hire 13 people. Took us 6 months to realize we’d made mistakes.

The Alternative Path (What I Wish We’d Done)

Before you scale headcount, scale capability:

1. Invest in automation and tooling first.

   • What manual work is slowing you down? Automate it.
   • What processes are broken? Fix them before adding people.
   • Research shows AI can achieve 90% speedups for simple tasks like restructuring code and writing tests - use that leverage.

2. Use contractors/agencies for burst capacity, not permanent headcount.

   • Need to ship a mobile app? Contract a mobile team for 6 months.
   • Need DevOps transformation? Hire a DevOps consultancy, not permanent staff.
   • Test the capability before committing to permanent overhead.

3. Ask: What outcome do we actually need?

   • Shipping faster? → Maybe you need better process, not more people.
   • Handling more load? → Maybe you need better infrastructure, not more engineers.
   • Entering new markets? → Maybe you need specialists (contract), not generalists (full-time).

When You SHOULD Scale

Don’t get me wrong—there are absolutely times when you need to grow the team:

• The work fundamentally requires more brains, not just more time. Building a new product line, supporting multiple platforms, serving different customer segments.
• You’ve maxed out productivity gains from tools/process. If your team is already operating at peak efficiency and you still can’t hit goals, then yes, add capacity.
• You’re losing market opportunity because of capacity constraints. Competitors are moving faster, customers are churning because you can’t deliver fast enough.

But even then: scale thoughtfully. Hire one person at a time. Integrate them fully before adding the next. Preserve what works.

The Design Lens

As someone who thinks in systems: your organization is a system.

Adding components (people) to a system without understanding how they interact creates chaos. You need to design the system first:

• What are the interfaces between teams?
• How does information flow?
• Where are the decision points?
• What are the feedback loops?

If you don’t design the system, the system will design itself—and it won’t be pretty.

Final Provocation

Some of the most successful startups I know stayed deliberately small and used leverage differently:

• Instagram: 13 engineers when acquired by Facebook for B
• WhatsApp: 55 employees when acquired for B
• Basecamp/37signals: ~60 people, M+ revenue

They optimized for efficiency, not headcount. They used tools, automation, focus, and saying “no” to stay lean.

I’m not saying “never hire.” I’m saying: what if the answer to “how do we scale?” isn’t always “hire more people”?

What if it’s “work smarter, not bigger”?

[product_david]

Michelle gave you the strategic portfolio approach. Luis gave you the tactical implementation. Maya challenged the premise. Let me add the product/business lens—because this is fundamentally a build-vs-buy decision, but for organizational capability.

The Decision Framework

Coming from Google APM to Airbnb PM to now VP Product at a Series B fintech, I’ve seen this scaling challenge from every angle. Here’s the framework I use:

When to BUILD Internal Capability (Promote from Within)

• Differentiation matters. Your engineering culture is a competitive advantage. Your team knows context that can’t be hired.
• Culture is critical. You’re in a high-trust, high-autonomy environment. External hires might optimize for process over people.
• You have time. Your product roadmap can flex, your competitors aren’t breathing down your neck, your board is patient.

When to BUY External Expertise (Hire Experienced Leaders)

• Speed matters. You’re in a land-grab market, competitors are moving fast, window of opportunity is closing.
• Skill gap is large. None of your team has done this before, and the learning curve is steep (6-12 months to get good at management).
• You can afford the premium. Senior hires are expensive—not just salary, but recruiting costs, potential mis-hires, cultural integration.

When to PARTNER/RENT (Fractional, Advisors, Consultants)

• Need is temporary. You need scaling expertise for 12-18 months, not forever.
• Testing new capability. You’re not sure if you need a full-time VP of Platform Engineering—try a fractional first.
• De-risking the investment. Advisors give you pattern recognition without the commitment of a full hire.

Our Series B Experience

We scaled our product team from 5 to 15 in 18 months. Made both mistakes:

Hired too senior: Brought in a Director of Product from a unicorn startup. Great résumé, wrong fit. She optimized for process and frameworks. Our team needed scrappy execution. She left after 9 months—expensive lesson.

Promoted too junior: Promoted a PM to Senior PM / Team Lead without support. Overwhelmed within 3 months. We almost lost her. Salvaged it with coaching, but that was a close call.

What worked: “Scaling councils”—cross-functional groups (Product, Eng, Design, Data) that made scaling decisions together. No one function owned “how we scale.” We designed the org together. Decisions stuck because everyone bought in.

The Measurement Problem

Here’s what most teams miss: you need to measure BEFORE you scale, so you know if it’s working.

Define your baseline metrics now:

• Time to onboard a new engineer (days until first meaningful commit)
• Deployment frequency (deploys per week)
• Incident response time (mean time to resolution)
• Employee satisfaction (quarterly pulse surveys, eNPS)
• Engineering velocity (story points, features shipped—pick your poison)

Track these monthly. When you start scaling (hiring, promoting, reorganizing), you’ll know if you’re improving or regressing.

At our Series B, we regressed for 4 months during scaling (slower deploys, longer onboarding, lower satisfaction). But we knew it was happening because we were measuring. We adjusted: paused hiring, invested in onboarding docs, fixed process bottlenecks. By month 6, we were back to baseline. By month 9, we were outperforming.

Without measurement, we would have kept hiring into dysfunction.

The Strategic Question

Keisha, here’s my question for you: Why does your CEO want to triple headcount?

Is it:

• Product roadmap capacity? (“We have 10 features to ship, only have capacity for 3”)
• Infrastructure/scalability needs? (“Our system can’t handle 10x traffic without re-architecting”)
• New market entry? (“We need to build enterprise features, mobile apps, international support”)
• Investor optics? (“Board expects us to look like a scaling company”)

The “why” determines the “how.”

• If it’s roadmap capacity, maybe the answer is ruthless prioritization (ship 3 great features, not 10 mediocre ones).
• If it’s infrastructure, maybe the answer is specialized hires (2-3 infra engineers) + cloud migration, not 50+ generalists.
• If it’s new markets, maybe the answer is contract teams (test the market before committing headcount).
• If it’s investor optics… that’s a different conversation. (And maybe Maya’s point about staying lean is the real answer.)

What I’d Do in Your Shoes

Month 1-2: Define the “Why”

• Align with CEO and board on the actual business outcome we need
• Translate business outcome into org capability requirements
• Decide: build, buy, or partner for each capability

Month 3-4: Measure Baseline + Build Playbook

• Capture current state: metrics, processes, culture, what works
• Create scaling playbook (as Michelle said)
• Identify 2-3 high-potential internal leaders for development

Month 5-6: Strategic Experiments

• Promote 1-2 internal managers with coaching/support (build)
• Hire 1 experienced director in critical area (buy)
• Engage 1 fractional advisor for 6 months (partner)
• Measure: are outcomes improving?

Month 7-12: Scale What Works, Stop What Doesn’t

• If internal promotions + coaching are working → do more
• If external hires are culture-adds → hire more thoughtfully
• If fractional advisors are delivering ROI → extend or convert to full-time
• If none of it is working → revisit the “why” with CEO

Final Thought

Don’t scale for scaling’s sake. Align your scaling strategy with business outcomes, measure relentlessly, and be willing to adjust course.

The best product teams I’ve worked with didn’t optimize for headcount. They optimized for impact per person. And that requires clarity on outcomes, not just inputs.

You’ve got the right instincts, Keisha. Trust them. And bring your CEO along on the journey—make sure you’re solving the same problem.