Scaling an Engineering Org From 60 to 100+ Engineers: Lessons Learned

At Talent Systems I was VP of Software Engineering. For most of that time I led 60+ web, mobile and QA engineers across eight product lines, with teams in North America, Europe, South America and APAC. Then the head of engineering left, and for about six months I ran the full org: 100+ people including IT and DevOps. This post is about what changed between those two jobs and the handful of mechanisms that made the larger one work. Some of it I got right the first time. Some of it I learned by getting it wrong.

The jump is not linear

Going from 60 to 100 sounds like adding a bit more of the same. It is not, for two reasons.

First, the new people were not more product engineers. They were IT and DevOps, functions with different rhythms, different customers inside the company, and different definitions of a good week. Product teams measure themselves on what shipped. DevOps measures itself on what did not break. IT measures itself on tickets closed and laptops that work on day one. Running all three with one playbook does not work.

Second, at 60 I could still know every engineer's name and most of their work. At 100 across four continents I could not, and pretending otherwise would have meant spending my entire week in one-on-ones and none of it on the system. The job became managing managers and designing mechanisms.

Structure: pods, guilds, and a crisp answer to "who owns this"

The structure that held up was cross-functional pods owning a product line or a slice of one, with functional guilds cutting across them. A pod had web, mobile and QA together with a product owner, and it owned outcomes for its area. Guilds, for example mobile or QA, owned standards, shared tooling and career growth within the discipline.

The thing that mattered more than the shape was clarity about ownership. For every system and every recurring decision, one named owner. When something fell through the cracks, the question was never "whose fault is this" but "why did this have no owner." A clear RACI sounds bureaucratic until you have watched a production issue bounce between three teams for a day because each believed another was handling it.

Release discipline is what lets 100 people ship at once

With 60 engineers across eight product lines, releases were already a coordination problem. At 100, with platform and infrastructure teams in the mix, they would have become the bottleneck for everything. What we built was shared practice rather than a central release team.

Every product line used the same release flow, with feature flags so that deploying and launching were separate decisions, and observability good enough that a bad change was visible within minutes and could be turned off without a rollback. On the infrastructure side the DevOps team standardized on Kubernetes with ArgoCD, Istio and Terraform across GCP and AWS, which meant one way to deploy and one way to describe environments instead of eight.

The result over that period was that sprint velocity doubled and production incidents dropped by 80 to 90%. I give those numbers because they are on my resume and because they came from mechanism, not from asking people to work harder.

Metrics that executives could act on

At 60 I could give the executive team a sense of how engineering was doing from memory and a few dashboards. At 100, with the CEO and the board asking harder questions, that was not good enough. We partnered with the data team on Snowflake, Fivetran and Power BI to produce a small set of KPIs that product and executives could actually use: delivery cost per feature, cycle time, reliability against SLOs, and spend.

The discipline was keeping the set small and tied to decisions. A dashboard with forty charts gets ignored. Four numbers that change what the executive team does on Monday get looked at. Delivery cost per feature became the one that moved the most conversations, and over the period it dropped by 30% through architecture refactoring and process changes that the number made visible.

Moving from vendors to in-house teams

A large share of delivery had been done by outsourced vendors. The transition to in-house teams was one of the biggest changes of the period and the one most likely to go wrong, because it touched hiring, knowledge transfer, morale and cost at the same time.

What worked was treating it as a program with a sequence. Hire the leads first, so there were people to receive the knowledge. Move one product line at a time, with the vendor overlapping long enough to hand off properly. Introduce structured intake and prioritization tied to quarterly business outcomes, so that the new in-house teams were working on what mattered instead of inheriting the vendor's backlog. Measure the cost per feature before and after so the business case stayed honest.

Post-acquisition integration

During the same period the company integrated acquired platforms. Technical integration is the easier half. The harder half is aligning roadmaps and people who built different things in different ways and are each sure their way is right.

What helped was writing down the target architecture and the decision rights early, involving the acquired team's leads in the decisions rather than announcing them, and being honest about what was going to be retired and when. Uncertainty does more damage than bad news.

What changed when IT and DevOps reported to me

This was the part I had not done before at that scale, and it taught me the most.

IT's customers are everyone in the company, and most of them are not engineers. Response time and reliability of the basics, accounts, devices, access, matter more than any project. The best thing I did was stop treating IT like a cost center to be minimized and start treating it like a product team whose users were the whole company, with a backlog, SLAs and a visible roadmap.

DevOps at that scale is a platform team. Its job is to make the product teams faster and safer without being in their way. The failure mode is becoming a gatekeeper that every deploy has to go through. The fix was self-service: paved roads with Terraform modules and standard pipelines, so that a product team could ship without filing a ticket and the DevOps team could spend its time on reliability and cost rather than approvals.

What breaks first at each step

If I had to summarize the pattern for someone about to make this jump:

Around 60, communication breaks first. You need written plans, a weekly operating rhythm, and leads who can run their areas without you in the room.
Around 80, release coordination breaks. You need shared release practice, feature flags and observability, or every launch becomes a negotiation.
Around 100, your own attention breaks. You need managers you trust, a small set of metrics you believe, and mechanisms that run when you are not looking.

The through line is mechanisms over heroics. Heroics got the org to 60. They would not have gotten it to 100 and they certainly would not have kept it there.

What I would tell my earlier self

Hire leads before you think you need them. Write down ownership before the gap appears, not after. Make deploy and launch separate decisions as early as possible. Keep the executive metrics to a handful and make sure each one changes a decision. And treat the functions that do not ship features, IT and DevOps and QA, as the product teams whose customers are your other teams, because that is what they are.

I do this kind of work now as a fractional CTO and through engineering leadership consulting engagements, usually for teams between about ten and a hundred engineers who are approaching one of these steps. The fractional CTO page describes how that works, the AI engineering leadership page covers the agentic side, my resume has the full history, and the contact page is the place to start if you are at one of these thresholds now.

Frequently asked questions

What is the biggest change when an engineering org passes 100 people?

The leader can no longer know every engineer and every piece of work. The job becomes managing managers, designing mechanisms that run without you, and holding a small set of metrics you trust. Attention, not effort, becomes the constraint.

How should IT and DevOps fit into an engineering org?

As platform and service teams with their own customers, backlogs and SLAs. DevOps should build self-service paths so product teams ship without tickets. IT should be run like a product team whose users are the whole company. Neither works well as a gatekeeper or a cost center.

How do you move from outsourced vendors to in-house engineering teams?

Hire leads first so there is someone to receive the knowledge, move one product line at a time with a vendor overlap, introduce structured intake tied to business outcomes, and measure delivery cost per feature before and after so the business case stays honest.

What metrics should an engineering leader report to executives?

A small set tied to decisions: delivery cost per feature, cycle time, reliability against SLOs, and spend. Four numbers that change what the executive team does are worth more than a dashboard with forty charts.