Engineering organizations rarely fail because their developers suddenly forget how to write software. They fail because the company grows faster than its operating model. As engineering headcount expands, the organization accumulates communication overhead, fragmented ownership, inconsistent technical standards, duplicated systems, operational risk, and cultural confusion. Leaders often respond by adding meetings, approval layers, managers, policies, and specialized teams. These interventions may create the appearance of control while making the organization even slower.
Kevin Scott’s experience leading engineering at AdMob and LinkedIn highlights four enduring principles:
Engineering exists to help the company win, not merely to produce elegant code. Leaders must design how the organization works, not only what technology it builds. Technical systems can be rewritten more easily than organizational culture. Engineering principles should be documented early in a practical cultural manifesto. Modern research reinforces these lessons. DORA’s long-running research program connects organizational capabilities, software-delivery practices, and continuous improvement with stronger technology and business performance. Microsoft’s SPACE framework warns that developer productivity cannot be reduced to commits, tickets, or lines of code. Google’s Site Reliability Engineering guidance shows that reliability requires explicit ownership, service objectives, operational discipline, and organizational maturity. Team Topologies provides a useful model for organizing around customer value, platforms, specialized subsystems, and temporary enablement.
A scalable engineering organization should therefore be designed around:
Clear business outcomes Small teams with meaningful end-to-end ownership Stable product or value streams Explicit decision rights Internal platforms that reduce cognitive load Reliability standards and service-level objectives Healthy collaboration between product, design, engineering, data, security, and operations A small number of multidimensional performance measures Leadership principles that survive headcount growth Regular organizational reviews and deliberate restructuring
The most important lesson is simple:
Do not wait until the organization becomes painfully slow before designing how it should work. By the time coordination failures become obvious, they may already be embedded in reporting lines, incentives, architecture, hiring practices, and management behavior.
Introduction: Why Successful Engineering Teams Eventually Become Slow In the earliest stage of a startup, engineering coordination appears almost effortless. A founder describes a customer problem. A developer starts building. Another engineer reviews the code. Someone deploys the product. The team talks continuously, priorities are visible, and everyone understands why the work matters. There may be no formal architecture council, platform organization, program-management function, escalation process, service catalog, or engineering manifesto. The absence of structure can feel like a competitive advantage. At five people, it often is. At 50 people, the same informal model begins to break. At 500 people, it can become dangerous.
The difficulty is that organizational failure rarely happens all at once. It develops gradually:
Deployments require more coordination. Engineers wait for approvals from teams they barely know. Multiple groups build similar infrastructure. Product managers compete for shared engineering resources. Nobody is certain who owns an aging service. Teams optimize local metrics while damaging the wider customer experience. Technical leaders spend more time resolving escalations than setting direction. Senior engineers become human routers for every important decision. Reliability work is repeatedly delayed in favor of visible features. Managers create more status meetings because they cannot see how work flows. Developers feel busy but customers receive less value. The company continues hiring because leadership assumes the problem is insufficient capacity.
But adding more people to a poorly designed system often creates more dependencies rather than more output. The central challenge of engineering leadership is therefore not just recruiting talented people or choosing good technologies. It is designing an organization in which talented people can repeatedly produce valuable outcomes without being suffocated by the organization surrounding them.
1. The Historical Lesson from AdMob and LinkedIn
Kevin Scott served in senior engineering leadership roles at AdMob and LinkedIn during periods of rapid growth and major transition. His reflections, originally shared through First Round Review, focus less on reporting structures and more on the operating philosophy behind successful engineering organizations. At LinkedIn, the company had passed 100 million users and was approaching its 2011 initial public offering. Yet its engineering organization was struggling to maintain product velocity. As the company and codebase expanded, deployments became slower, systems became harder to change, and unfinished work accumulated. At AdMob, rapid commercial growth created another form of pressure. Sales opportunities frequently generated requests for advertiser-specific features. Engineering teams were drawn into one-off development that produced revenue in the near term but offered little reusable value. Over time, the team became strained, reactive, and vulnerable to burnout. These examples reveal two common scaling traps. The LinkedIn trap: growth without delivery capacity A company may have excellent engineers and strong demand, yet still lose the ability to move quickly because its architecture, development workflow, and organizational design have not evolved.
The result is organizational gridlock:
Too many dependencies Slow integration Fragile deployments Unclear ownership Long stabilization cycles Difficulty changing foundational systems The AdMob trap: revenue without leverage A startup may say yes to every customer, sales request, partnership opportunity, or executive escalation. This behavior can produce impressive short-term revenue, but engineering becomes a custom-development agency instead of a scalable product organization.
The result is a growing portfolio of:
Customer-specific code Manual processes Exceptions Special configurations Unsupported integrations Operational obligations Low-reuse features The company appears to be growing, but each additional customer makes the organization more complicated. The lesson from both cases is that engineering structure cannot be separated from business strategy. A team designed for a repeatable software platform should behave differently from a team designed for custom enterprise implementation. A company competing through speed should make different technical investments from one competing through reliability, proprietary data, regulatory compliance, or network effects. There is no universally correct engineering structure. There is only a structure that fits, or fails to fit, the company’s current strategy.
2. Engineering’s Job Is to Help the Company Win
Many engineering leaders were promoted because they were exceptional developers, architects, or technical problem-solvers.
Their professional identity may have been built around:
Writing elegant code Designing scalable systems Solving difficult technical problems Improving performance Selecting technologies Maintaining quality Reducing technical debt These capabilities remain valuable in leadership. However, they are no longer the complete job.
The leader of an engineering organization must ask a wider question:
What must the company accomplish, and how should engineering help make that outcome possible? This changes the way technical work is evaluated. A technically impressive system may be strategically irrelevant. A beautifully designed internal platform may consume years of engineering effort without improving customer value. A highly scalable architecture may be premature if the company has not found product-market fit. A rapidly shipped feature may be harmful if it creates unacceptable security or compliance exposure. A custom integration may be worthwhile for a strategically important customer, but destructive if it becomes the default sales model. Technical quality matters, but it must be understood in context. Engineering strategy should follow business strategy
Consider five companies with different competitive advantages:
Company A competes through speed
Its engineering organization should emphasize:
Short deployment cycles Product experimentation Rapid feedback Reversible decisions Strong developer tooling Low coordination overhead Company B competes through reliability
Its organization should emphasize:
Service ownership Redundancy Observability Incident management Capacity planning Conservative change controls for critical systems Company C competes through proprietary data
Its organization should emphasize:
Data quality Governance Privacy Data infrastructure Machine-learning capability Secure internal access Company D competes in a regulated industry
Its organization should emphasize:
Auditability Security Compliance by design Segregation of duties Documentation Risk management Company E competes through customization
Its organization may need:
Configuration frameworks Solutions engineering Extensible APIs Implementation teams Clear boundaries between product and customer-specific work The engineering leader’s role is to translate the business model into technical and organizational capabilities.
That translation should influence:
Hiring Team design Architecture Platform investment Product planning Reliability expectations Security controls Performance measurement Leadership development A company cannot claim that customer trust is its advantage while rewarding teams exclusively for shipping speed. It cannot claim to be a platform business while allowing every major customer to create a different version of the product. It cannot claim that innovation is essential while requiring six committees to approve every experiment.
Organizational truth is revealed by operating behavior, not executive language.
3. Ask “How Will We Work?” Before Obsessing Over “What Will We Use?”
Engineering discussions naturally focus on tools and technical choices:
Which programming language should we standardize on? Should we use microservices or a modular monolith? Which cloud provider should we choose? What database should support this workload? Should we build or buy? Which AI coding platform should we deploy? Which orchestration system should manage infrastructure? These are legitimate decisions.
But they are often easier to discuss than the organizational questions underneath them:
How will teams coordinate? How will we make decisions? How will we resolve disagreement? How will ownership transfer when people leave? How will we balance feature delivery and system health? How will we decide when standardization is required? How will teams learn from incidents? How will we prevent one team from becoming a bottleneck? How will product and engineering share accountability? How will we determine whether a platform is helping its users? How will we protect developers from constant interruptions? How will we preserve quality as AI increases code-production capacity?
A company can replace a database. It is harder to replace an unhealthy decision-making culture. It can migrate from one cloud provider to another, although the process may be expensive. It is much harder to repair an organization in which nobody feels safe raising risks. It can refactor a service. It is harder to refactor a management system that rewards heroics, hides failure, and promotes people based on political visibility. The “how” questions create the operating system of the engineering organization.
4. Culture Is an Operational System, Not a Collection of Slogans
Companies often define culture using broad words:
Excellence Innovation Integrity Ownership Collaboration Customer focus These words are positive, but they do not tell an engineer what to do when two principles conflict. Should a team delay a launch to fix a reliability concern? Can an engineer stop a deployment? When should a team build a reusable platform rather than a local solution? Can product managers commit engineering work to a customer before technical review? Who owns a service after it enters production?
What happens after an incident? When is technical debt important enough to displace roadmap work? These are cultural questions because they reveal what the organization actually values. Culture appears in repeated decisions
An engineering culture is expressed through patterns such as:
What leaders praise What they ignore Who gets promoted Who gets blamed Which deadlines are treated as negotiable Which risks are tolerated Whether teams document decisions Whether incidents produce learning or punishment Whether reliability work receives funding Whether managers protect focus time Whether senior leaders bypass normal prioritization Whether customer problems are treated as interruptions or responsibilities
Culture is not separate from execution. Culture determines execution. A company that rewards last-minute heroics may unintentionally discourage prevention. A company that praises individual output may weaken collaboration. A company that punishes every failure may cause teams to hide risk. A company that values speed without defining acceptable failure may accumulate instability. A company that claims to value ownership but centralizes every decision will produce dependency. Because these behaviors become self-reinforcing, cultural design should begin before the organization reaches crisis.
5. Create an Engineering Manifesto Before You Think You Need One
One of Kevin Scott’s most important recommendations is to create a cultural manifesto for engineering. This should not be confused with a generic values poster. An engineering manifesto is a practical statement of how the organization intends to build, operate, and improve technology.
It serves several purposes:
Aligns teams Clarifies expectations Accelerates decisions Reduces recurring arguments Supports onboarding Guides leadership behavior Preserves important principles during growth Makes cultural contradictions easier to identify The manifesto should describe the organization’s current commitments, not imaginary perfection.
A useful engineering manifesto might answer:
Business alignment What role does engineering play in the company’s strategy? What customer or market advantage are we helping create? What kinds of technical investment are strategically important? What types of work should engineering decline? Product development How are priorities established? How do product, design, engineering, data, and go-to-market teams collaborate? How are customer requests evaluated? What qualifies as an experiment? How quickly should teams seek feedback? Technical ownership
Who owns services in production? Does the team that builds a service operate it? What documentation is required? How are architecture decisions recorded? How are dependencies managed? Quality and reliability What level of testing is expected? What service-level objectives should critical systems meet? How are incidents managed? How are post-incident reviews conducted? When can teams stop feature work to restore system health? Security and privacy
What security responsibilities belong to every team? Which controls are centralized? How are vulnerabilities prioritized? How is sensitive data handled? When is independent review required? Team behavior How are disagreements resolved? What does respectful technical debate look like? How are decisions communicated? How do teams share knowledge? How should leaders respond when someone raises a risk? Improvement
How is technical debt identified and prioritized? How are developer pain points measured? How frequently are organizational assumptions reviewed? What evidence can trigger a change in the manifesto? Coordination matters more than universal agreement A manifesto should be debated, but it does not need unanimous support. Some principles require leadership decisions.
For example:
All production services must have named owners. Customer-specific code requires executive product approval. Critical incidents require blameless review. Platform teams must measure adoption and user satisfaction. No team may rely indefinitely on one person’s undocumented knowledge. Security controls apply to executives as well as employees. People may disagree with a rule while still understanding why it exists and how to operate within it. Clarity is often more scalable than consensus.
6. Organize Teams Around the Flow of Customer Value
Traditional organizations often group engineers by technical specialty:
Front-end department Back-end department Database team Mobile team Quality-assurance team Infrastructure team Security team Specialization can be useful, but organizing primarily by function often creates handoffs.
A customer-facing feature may require:
Product definition Design Front-end development Back-end development Database changes Security review Quality assurance Infrastructure provisioning Release approval Operational handover No single team can deliver the outcome independently. Each department is busy, yet the feature moves slowly.
Stream-aligned ownership Team Topologies proposes organizing much of the engineering organization around streams of value. A stream-aligned team is responsible for delivering outcomes for a product, service, customer journey, or business capability. Supporting structures include platform teams, enabling teams, and teams responsible for complicated subsystems.
A stream-aligned team might own:
Customer onboarding Merchant payments Search and discovery Advertising delivery Identity and access Seller operations Subscription billing Fraud prevention The team should have enough capability and authority to improve its area without waiting for a long chain of functional departments. This does not mean every team needs every specialist permanently assigned. It means the organization should minimize unnecessary dependencies between an idea and its delivery to customers. End-to-end ownership
A well-designed product team should ideally understand and influence:
Customer problems Product goals Application behavior Data Testing Deployment Reliability Security Performance Operational cost Customer feedback Ownership becomes dangerous when it means unlimited responsibility without support.
Therefore, end-to-end ownership must be accompanied by:
Good internal platforms Clear standards Shared tooling Training Sustainable on-call practices Escalation paths Specialist support Reasonable cognitive load The goal is not to make every developer an expert in everything. The goal is to enable teams to deliver value without navigating the entire company.
7. Build Platform Teams That Remove Work Rather Than Create Governance
As product teams multiply, they need common capabilities:
Continuous integration Deployment pipelines Cloud environments Authentication Logging Monitoring Feature flags Data access Secrets management Developer environments Service templates AI-development tools
Security controls A platform team can provide these capabilities as internal products. But platform teams frequently become central bottlenecks.
They may:
Require tickets for routine tasks Impose standards without understanding users Build tools nobody adopts Optimize infrastructure rather than developer experience Become gatekeepers Measure completed projects instead of reduced friction A successful platform should make the preferred path the easiest path. Treat the platform as a product
An internal platform needs:
Defined users User research A product roadmap Documentation Support Reliability commitments Adoption metrics Satisfaction measures Clear boundaries A deprecation strategy The platform’s purpose is not merely to centralize infrastructure. Its purpose is to reduce the cognitive and operational burden placed on customer-facing teams.
Team Topologies describes a platform as a set of internal services that accelerates stream-aligned teams and shields them from unnecessary complexity. It also distinguishes three interaction modes: ongoing service consumption, temporary collaboration, and facilitation. That distinction matters. Not every relationship between teams should become a permanent dependency. Questions for evaluating an internal platform Can a new team deploy a service without manual intervention? How long does it take a new engineer to become productive? Can teams understand platform errors without contacting the platform group? Are security and reliability defaults built into the workflow? How much custom support does each platform adoption require? Are developers using the platform voluntarily? What work has the platform eliminated? Has the platform reduced lead time or failure risk?
Does the platform have service-level commitments? Can teams exit or extend the platform when necessary? A platform that creates more coordination than it removes is not functioning as a platform. It is another department.
8. Use Enabling Teams to Spread Capability
Some organizational problems cannot be solved by issuing standards.
A team may lack knowledge in:
Cloud architecture Machine learning Cybersecurity Accessibility Performance engineering Observability Regulatory compliance Data governance AI evaluation Incident management Creating a permanent centralized approval group may produce bottlenecks. An enabling team provides a different model.
It temporarily works with another team to transfer capability, improve practices, or help solve a difficult problem. The enabling team’s success is measured by whether the receiving team becomes more capable and independent.
For example, a security enabling team might:
Help a product group implement threat modeling Provide secure templates Review a first implementation Train engineers Automate common controls Withdraw once the team can manage routine security decisions
This model avoids two extremes:
Every team must independently rediscover specialized knowledge. Every specialized decision must pass through a centralized gatekeeper. Enabling teams scale expertise by teaching and improving systems, not by collecting permanent approvals.
9. Protect Teams from Excessive Cognitive Load
An engineering team can own too little and become dependent on everyone. It can also own too much and become overwhelmed.
Cognitive load includes everything team members must understand to perform their work:
Product logic Customer behavior Codebases Infrastructure Data models Security requirements Compliance obligations Deployment systems Monitoring tools Incident procedures Internal policies Dependencies
Organizational relationships
When cognitive load becomes excessive, teams experience:
Slow onboarding More mistakes Fragile ownership Dependence on a few experts Delayed decisions Burnout Avoidance of necessary changes Increased operational risk This is why team boundaries should be designed around manageable domains. Signals that a team’s scope is too broad Multiple unrelated roadmaps compete for attention. The team operates more services than it can meaningfully maintain.
Nobody understands the full system. On-call alerts cover unrelated business areas. Important maintenance is continually postponed. Senior engineers spend most of their time explaining context. New hires require many months to contribute. The team’s backlog contains fundamentally different categories of work. Stakeholders cannot describe the team’s mission in one sentence. The answer is not always to split the team.
Sometimes the organization should:
Simplify architecture Retire services Improve documentation Automate operational work Move common complexity into a platform Reduce product scope Clarify ownership Eliminate low-value processes Organizational structure should not be used to preserve unnecessary technical complexity.
10. Keep Teams Small, but Do Not Worship a Specific Number
Small teams tend to communicate more effectively than large teams. As membership grows, the number of potential communication relationships increases rapidly. More people bring more knowledge and capacity, but also more coordination. There is no universal perfect team size. A practical product team often includes approximately five to ten core contributors, but the right size depends on: Nature of the work Degree of specialization Technical complexity Product maturity Operational burden Geographic distribution Leadership capability Dependency structure
The more important question is whether the team can:
Share context Make decisions Maintain ownership Coordinate without excessive meetings Deliver customer value Operate its systems sustainably A 12-person team with clear subdomains may outperform a seven-person team trapped among external dependencies. A six-person team responsible for 40 services may be far less effective than a larger team with a focused product boundary. Team size should therefore be considered alongside mission, authority, capability, and cognitive load.
11. Create Clear Decision Rights
Many scaling companies do not suffer from a lack of intelligence. They suffer from uncertainty about who can decide.
A technical question moves through meetings because:
The owner is unclear. Leaders want broad alignment. Nobody wants accountability. Multiple teams may be affected. The organization confuses consultation with approval. Senior leaders routinely overturn delegated decisions. This creates decision latency. Separate decision roles
For important decisions, identify:
Decision owner: the person accountable for making the decision Contributors: people supplying analysis or options Consulted parties: stakeholders whose input is required Informed parties: people who need visibility after the decision Approver: used only when legal, financial, security, or executive authority genuinely requires formal approval Not every contributor should be an approver. Not every stakeholder should possess veto power. Make decisions reversible where possible Reversible decisions should be made quickly and close to the work. Irreversible or high-impact decisions deserve more analysis.
Examples of relatively reversible decisions may include:
A local library An internal workflow An experiment A user-interface variation A limited deployment pattern
Higher-consequence decisions may include:
A core data model A company-wide identity architecture A major regulatory commitment A long-term cloud contract A foundational public API A security model A merger of critical systems Good engineering governance applies greater rigor in proportion to risk. It does not treat every decision as equally dangerous.
12. Design Product and Engineering as One Delivery System
Engineering structure cannot be fixed while product management remains disconnected from technical reality.
Common dysfunctions include:
Product commits dates without engineering input. Engineering builds infrastructure without product context. Design enters too late. Data teams receive requests after launch. Security review begins immediately before release. Sales promises custom capabilities that are absent from the roadmap. Product measures feature delivery while engineering measures system health. Teams ship outputs without owning business outcomes. A strong product-development system should align around shared goals. A balanced team model
A durable product area often needs partnership among:
Product management Engineering Design Data or analytics Security and privacy Operations or reliability Relevant commercial stakeholders These functions do not need identical authority over every decision. They do need shared context and explicit responsibilities. Shared outcome examples
Instead of measuring:
Features released Tickets closed Story points completed Code merged
Measure outcomes such as:
Onboarding completion Payment success Search satisfaction Retention Conversion Fraud loss Support burden Reliability Customer task completion Cost per transaction Output metrics remain useful for diagnosing workflow. They should not replace the reason the work exists.
13. Balance Product Delivery with Reliability
Rapidly growing companies often postpone reliability work because new features are more visible.
This creates a dangerous cycle:
More features increase system complexity. Complexity increases incidents and operational work. Operational work consumes engineering capacity. Delivery slows. Leadership applies more roadmap pressure. Maintenance is postponed again. The system becomes even more fragile. Google’s Site Reliability Engineering approach provides practical methods for balancing innovation and operational stability. These include service-level indicators, service-level objectives, error budgets, incident response, postmortems, toil reduction, and staged organizational maturity. Service-level objectives An SLO defines a target level of reliability for a service.
Examples include:
Percentage of successful requests Latency targets Availability Data freshness Job-completion rates Recovery time Accuracy or correctness measures The objective should reflect user experience, not merely infrastructure availability. Error budgets If a service has a 99.9 percent availability objective, the difference between perfect reliability and the objective forms an error budget. The team can use that budget to balance change and stability. When reliability is comfortably within the target, the team may accept more deployment risk.
When the error budget is exhausted, the organization may reduce risky changes and prioritize reliability. This creates a decision mechanism that is more useful than arguing abstractly about whether the company is moving too fast. Reduce toil Toil is recurring operational work that is manual, repetitive, and does not create durable value.
Examples include:
Manual deployments Repeated account provisioning Restarting unhealthy services Copying data between systems Responding to noisy alerts Repeating the same incident procedure Maintaining customer-specific exceptions If operational work grows proportionally with customers or infrastructure, the organization has not truly scaled. The engineering roadmap should include systematic toil reduction.
14. Do Not Measure Developer Productivity with One Metric
Leaders naturally want evidence that an engineering organization is productive.
The danger appears when productivity is reduced to a simplistic number:
Lines of code Commits Pull requests Tickets Story points Hours worked Deployments AI-generated code volume These metrics can be useful in limited contexts, but they do not measure the complete value of engineering work. A developer who prevents a major security incident may write little code. An engineer who deletes an unnecessary system may create more value than someone who adds thousands of lines. A staff engineer may improve decisions across five teams without appearing productive in repository statistics.
A team can increase deployment frequency while releasing low-value changes. The SPACE framework Microsoft Research, GitHub, and academic collaborators developed the SPACE framework to represent multiple dimensions of developer productivity: Satisfaction and well-being Performance Activity Communication and collaboration Efficiency and flow The framework explicitly warns that productivity is multidimensional and should not be measured using a single metric.
A useful engineering scorecard might therefore combine:
Business outcomes Revenue contribution Adoption Conversion Retention Customer satisfaction Delivery performance Lead time for changes Deployment frequency Change failure rate Recovery performance Reliability and quality
SLO attainment Escaped defects Incident severity Security findings Performance regressions Developer experience Time to first meaningful contribution Build and test time Environment setup difficulty Interruptions Tool satisfaction Perceived ability to complete work
Organizational health Retention Burnout risk Internal mobility Knowledge concentration Psychological safety Manager effectiveness DORA’s research similarly focuses on capabilities and outcomes rather than treating developer activity as the ultimate objective. Its research program has studied software-delivery and operational performance across tens of thousands of professionals and organizations. The purpose of measurement should be improvement, not surveillance. When metrics are used to rank individuals mechanically, people optimize the metric. When metrics are used to identify system friction, the organization can improve the environment in which people work.
15. Treat AI-Assisted Engineering as an Organizational Change
AI coding assistants and software-development agents can increase the speed at which code, documentation, tests, and prototypes are produced. But faster code production does not automatically create a faster company. If review, testing, security, integration, architecture, and deployment remain constrained, AI may move the bottleneck rather than remove it.
It may also increase:
Code volume Review burden Dependency use Security exposure Inconsistent design Duplicate implementations Maintenance obligations The 2025 DORA report focused on AI-assisted software development and emphasized that organizations unlock value by investing in teams, people, processes, and organizational capabilities, not merely by distributing tools.
An AI-ready engineering manifesto should address:
Which data may be shared with AI tools Which repositories may use external models How generated code is reviewed How licenses and dependencies are evaluated What testing is required Which decisions require human approval How AI-generated vulnerabilities are identified How productivity impact is measured How junior engineers continue developing foundational skills How teams document agent-generated changes Who is accountable for generated code AI does not eliminate the need for engineering culture.
It makes cultural and operational clarity more important because the organization can create software faster than before.
16. Avoid the Deal-Specific Development Trap
AdMob’s experience illustrates a recurring startup problem: engineering becomes overloaded by customer-specific work. The request often appears reasonable. A large prospect wants one feature. A salesperson believes the contract depends on it. The engineering effort appears manageable. The deal is approved. Then another customer wants a variation.
Over time, the company accumulates special cases that affect:
Product behavior Testing Infrastructure Documentation Support Deployment Security Billing Future development The cost is not the original implementation. The cost is the permanent obligation. Evaluate custom requests systematically
Before accepting customer-specific engineering work, ask:
Does this solve a problem shared by the target market? Can it become a configurable platform capability? Does it strengthen the company’s strategic differentiation? What is the full lifecycle cost? Who will operate and support it? Will it slow the core roadmap? Does the contract justify the opportunity cost? Can professional services handle it without changing the core product? Is there a clear expiration or migration path? What precedent will this create for sales? Create service boundaries
Companies may distinguish among:
Core product capabilities Configurable features Public APIs Partner integrations Professional services Customer-funded development Experimental capabilities Unsupported customizations The objective is not to reject every large customer request. It is to prevent commercial urgency from silently redefining the product architecture.
17. Restructure Before the Organization Freezes
Engineering structures should not be changed casually. Frequent reorganizations destroy context, trust, and momentum. But refusing to restructure can be equally harmful. A team model that worked at 20 engineers may be inappropriate at 100. A centralized infrastructure group may need to become a platform organization. A single product team may need to divide around distinct customer journeys. A specialized team may need to embed expertise into product groups. A fragmented architecture may require temporary centralization. Signals that restructuring may be necessary Most initiatives require coordination across many teams. A few teams are permanent bottlenecks. Ownership does not match architecture.
Managers have excessively broad responsibilities. Product areas contain incompatible goals. Teams repeatedly negotiate basic responsibilities. Reliability incidents fall between organizational boundaries. The roadmap is organized around departments rather than customer value. Platform adoption is weak. Leaders cannot explain why the current structure exists. The business strategy has changed, but the organization has not. Reorganize around a hypothesis
Every restructuring should state:
What problem is being solved What evidence supports the change What will become easier What new risks may appear Which metrics should improve When the structure will be reviewed
For example:
We are creating a payments platform team because five product teams currently implement payment logic independently. We expect this change to reduce duplicated work, improve transaction reliability, and shorten integration time for new payment methods. We will review adoption, lead time, incident rates, and product-team satisfaction after two quarters. This is more useful than announcing that the company is reorganizing to “increase alignment and unlock synergies.”
18. A Stage-by-Stage Engineering Structure
No single model fits every company, but the following stages provide a useful starting point. Stage 1: Founder-led engineering Typical size Two to ten engineers Priorities Find product-market fit Ship quickly Stay close to users Minimize unnecessary infrastructure Establish basic quality and security habits Clarify ownership Structure
A small cross-functional product team, with founders heavily involved. Risks Founder bottlenecks Undocumented systems Weak testing Constant priority changes Premature platform work Hero culture Leadership focus Write the first version of the engineering manifesto, even if it is only a few pages.
Stage 2: Early scaling Typical size Ten to 40 engineers Priorities Establish team missions Introduce engineering managers selectively Define service ownership Improve deployment and observability Create consistent hiring and onboarding Reduce key-person dependence Structure Several stream-aligned teams supported by lightweight shared infrastructure capability.
Risks Functional silos Too many managers Architecture fragmentation Sales-driven roadmap distortion Inconsistent standards Unclear technical leadership Leadership focus Clarify decision rights and establish shared development practices.
Stage 3: Growth organization Typical size 40 to 150 engineers Priorities Reduce dependencies Build internal platform capabilities Establish reliability practices Develop managers and senior individual contributors Improve planning across teams Introduce meaningful engineering metrics Structure Stream-aligned product teams, a platform team, targeted enabling capabilities, and specialized subsystem ownership where needed.
Risks Platform gatekeeping Meeting expansion Layered approvals Manager inconsistency Duplicated infrastructure Organizational distance from customers Leadership focus Preserve local autonomy while standardizing the areas where inconsistency creates company-wide cost.
Stage 4: Multi-product scale Typical size 150 to 500 engineers Priorities Organize around product portfolios or business domains Strengthen architecture governance without centralizing every decision Improve internal mobility Formalize service maturity Manage cross-product platforms Strengthen security and compliance Structure Multiple engineering groups with clear domain ownership, supported by platform, reliability, data, security, and enabling organizations.
Risks Duplicate platforms Political resource allocation Weak end-to-end accountability Excessive hierarchy Strategy dilution Slow cross-group decisions Leadership focus Maintain a coherent engineering strategy and ensure that each organizational layer adds value.
Stage 5: Large technology organization Typical size More than 500 engineers Priorities Portfolio governance Platform ecosystems Organizational simplification Leadership succession Reliability at scale Cost management Research and long-term innovation Global coordination
Structure Federated domains with shared company-wide principles, platforms, and governance mechanisms. Risks Bureaucracy Internal competition Local optimization Process accumulation Innovation theater Disconnection from users Hidden duplication Leadership focus Continuously remove obsolete process and organizational complexity.
19. A Practical Engineering Organization Scorecard
Leadership teams can review the engineering organization quarterly across eight dimensions.
1. Strategic alignment
Can every team explain how its work helps the company win? Do roadmaps reflect business priorities? Is engineering involved in strategy formation?
2. Team ownership
Does every important product and service have a clear owner? Can teams deliver without excessive external coordination? Are ownership boundaries understood?
3. Flow
How long does work take from idea to production? Where does it wait? How many teams participate in a typical initiative?
4. Reliability
Are SLOs defined for critical services? Are incidents decreasing? Is operational work sustainable?
5. Developer experience
Can engineers create environments and deploy easily? Is onboarding improving? Which tools or processes create the most frustration?
6. Organizational health
Are managers effective? Are senior engineers able to lead without becoming bottlenecks? Are burnout and attrition concentrated in certain teams?
7. Architecture and platform leverage
Are common capabilities reused? Is the platform reducing cognitive load? Is technical complexity increasing faster than customer value?
8. Learning and adaptation
Are incident lessons implemented? Are unsuccessful processes removed? Does the engineering manifesto evolve? Can teams challenge outdated assumptions? The scorecard should not become an exercise in producing perfect numbers. Its purpose is to support difficult conversations with evidence.
20. A 90-Day Implementation Plan
Days 1 - 30: Diagnose the system Interview stakeholders
Speak with:
Engineers Managers Product leaders Designers Data teams Security Customer support Sales Executives
Ask:
What slows delivery? Where is ownership unclear? Which teams are bottlenecks? What work repeatedly interrupts planned priorities? Where does customer feedback disappear? Which cultural behaviors are rewarded? What would make engineering substantially more effective? Map the work
Document:
Teams Missions Services Dependencies Decision owners On-call ownership Product areas Platform capabilities Major bottlenecks Establish baseline measures
Select a limited set of indicators covering:
Business outcomes Delivery flow Reliability Developer experience Organizational health
Days 31 - 60: Define principles and target structure Draft the engineering manifesto
Include:
Role of engineering Product-development model Ownership principles Reliability expectations Security expectations Decision practices Collaboration rules Improvement mechanisms Design team boundaries
Evaluate:
Which teams align with customer or business value Which dependencies can be removed Which common capabilities belong in a platform Where temporary enabling support is needed Which subsystems require specialist ownership Clarify leadership roles
Define expectations for:
Engineering managers Directors Staff engineers Principal engineers Product managers Platform leaders Reliability leaders
Days 61 - 90: Implement selectively Do not reorganize everything simultaneously.
Choose a small number of high-value interventions, such as:
Assigning explicit service ownership Creating one stream-aligned pilot team Establishing SLOs for a critical service Removing a recurring approval step Launching a platform self-service capability Creating an architecture decision record process Reducing noisy alerts Introducing quarterly developer-experience surveys Establishing a policy for customer-specific development Review the impact before expanding. Organizational design should be iterative, but cultural principles must remain coherent.
Key Takeaways
Engineering structure must reflect the company’s strategy. A company competing through speed, reliability, data, customization, or regulatory trust requires different capabilities. Engineering leaders are company builders. Their responsibility extends beyond code quality and architecture to organizational design, customer outcomes, talent, operations, and business performance. The way teams work matters more than any individual technology choice. Tools can be replaced. Dysfunctional decision systems and unhealthy cultures are harder to repair. Culture should be documented operationally. An engineering manifesto should explain how teams prioritize, build, operate, collaborate, resolve conflict, and improve. Organize primarily around customer value. Stream-aligned teams with meaningful ownership usually reduce handoffs and increase accountability. Use platforms to remove complexity. Internal platforms should behave like products and make common engineering work easier, safer, and faster.
Use enabling teams to transfer knowledge. Specialized expertise should help product teams become more capable rather than creating permanent approval dependencies. Protect teams from excessive cognitive load. Team missions, technical scope, and operational responsibility must remain manageable. Balance speed with reliability through explicit mechanisms. SLOs, error budgets, incident practices, and toil reduction help organizations make rational tradeoffs. Measure productivity across several dimensions. Business results, delivery flow, reliability, developer experience, collaboration, and well-being matter more than raw activity. Treat AI adoption as an organizational transformation. Faster code generation requires stronger review, security, testing, ownership, and measurement. Control customer-specific engineering work. Short-term deals can create permanent technical and operational costs.
Reorganize deliberately, not constantly. Every structural change should be based on an explicit hypothesis and measurable expected outcomes. Design before crisis. The best time to clarify culture, ownership, reliability, and decision rights is before rapid growth exposes their absence.
Frequently Asked Questions
What is the best structure for a startup engineering team?
In the earliest stage, a small cross-functional team is usually more effective than multiple specialized departments. The team should remain close to customers, ship frequently, and avoid unnecessary dependencies. As the company grows, it can divide around products, customer journeys, or business capabilities.
How many engineers should an engineering manager oversee?
There is no universal number. Many organizations use a range of approximately five to ten direct reports, but the appropriate span depends on team maturity, technical complexity, manager responsibilities, geographic distribution, and the experience of team members. Managers overseeing highly independent senior engineers may support more people. Managers leading new teams, junior staff, or operationally intensive systems may need a smaller span.
Should engineering teams be organized by technology or product?
Product or value-stream alignment is often preferable for customer-facing work because it reduces handoffs and creates end-to-end accountability. Technology-based teams remain useful for internal platforms, infrastructure, security, data systems, or highly specialized subsystems. The goal is to use specialization where it creates leverage without turning every customer outcome into a cross-department project.
When should a company create a platform team?
A platform team becomes valuable when multiple product teams repeatedly solve the same infrastructure, deployment, security, data, or developer-tooling problems. The company should first verify that the problem is truly shared. A platform created too early may build abstractions for requirements that are not yet understood.
How do we know whether a platform team is successful?
Measure whether product teams can deliver faster, more safely, and with less cognitive burden.
Useful indicators include:
Adoption User satisfaction Time to provision resources Deployment lead time Support volume Reliability Reduction in duplicated work Onboarding speed
Should every team own its production systems?
End-to-end ownership is usually beneficial, but it requires adequate tooling, training, staffing, and operational support. A team should not be told to “own production” while lacking observability, incident processes, realistic on-call rotations, or authority to prioritize reliability.
What should an engineering manifesto contain?
It should contain practical principles governing:
Engineering’s strategic role Product development Decision-making Technical ownership Reliability Security Quality Collaboration Incident learning Technical debt Developer experience Organizational improvement
How often should the manifesto be updated?
Review it at least annually and whenever the company experiences a major change in strategy, scale, market, product portfolio, regulation, architecture, or leadership. Individual principles may remain stable, but their implementation should evolve.
How can engineering resist unrealistic sales requests?
Create a transparent process for evaluating customer-specific work based on:
Strategic relevance Reusability Contract value Opportunity cost Lifecycle cost Operational burden Product precedent Engineering should not simply say no. It should make the tradeoff visible.
Are microservices necessary for autonomous teams?
No. Team autonomy depends on clear ownership, modularity, interfaces, deployment capability, and decision rights. A modular monolith can support effective teams. A poorly designed microservices architecture can create severe dependency and operational problems. Organizational design should not be based on architectural fashion.
Which engineering metrics should executives monitor?
A balanced executive scorecard may include:
Customer or business outcomes Lead time for changes Deployment frequency Change failure rate Recovery performance SLO attainment Critical incidents Developer experience Retention and burnout indicators Platform adoption Engineering cost efficiency Metrics should be interpreted together.
How do we prevent engineering metrics from being gamed?
Avoid using isolated activity metrics to rank individuals. Use multiple measures, combine quantitative and qualitative evidence, examine trends at team or system level, and treat metrics as signals for investigation rather than automatic judgments.
How does AI change engineering-team structure?
AI may reduce effort for coding, testing, documentation, support, migration, and analysis. It may also increase the amount of generated software that needs review and maintenance.
Organizations may need stronger capabilities in:
AI tooling Evaluation Secure usage Code review Architecture Governance Developer education Human-agent workflow design The key challenge shifts from producing code to directing, validating, integrating, operating, and governing software creation.
Conclusion
The greatest engineering organizations are not created by accumulating the largest number of developers, adopting the newest architecture, or introducing the most sophisticated management processes. They are created by aligning people, technology, decision-making, and culture around the company’s purpose. Kevin Scott’s experiences at AdMob and LinkedIn show that engineering leadership must look beyond the immediate act of building software. Leaders must design the conditions under which software can continue to be built effectively as products, customers, systems, and teams multiply.
That requires answering difficult questions early:
What does engineering need to make possible? How should teams work together? What should they own? Which decisions should remain local? Which capabilities should be shared? What reliability does the customer actually need? Which customer requests strengthen the product? Which behaviors should the culture reward? How will productivity be understood? When should the organization change? An engineering organization is itself a system. It has inputs, constraints, feedback loops, dependencies, failure modes, incentives, interfaces, and accumulated debt.
It deserves the same deliberate design that engineers apply to critical technology. Companies that recognize this early can keep their speed as they grow. Companies that ignore it may continue hiring while becoming slower, more fragile, and less capable of turning technical talent into customer value. The objective is not to create a permanent organizational chart. It is to create an engineering system that can learn, adapt, and continue helping the company win.
Relevant Articles and Resources
1. First Round Review: How I Structured Engineering Teams at LinkedIn and AdMob for Success
The original interview and source inspiration for this article. Kevin Scott explains why engineering leaders must connect technical work with company success, focus on how teams operate, and proactively define engineering culture.
2. DORA Research
Google’s DORA program studies the capabilities associated with software-delivery, operational, and organizational performance. Its research is useful for leaders designing engineering measurement and improvement systems.
3. DORA 2025 Research Overview
The 2025 research focuses on AI-assisted software development and the organizational capabilities needed to translate AI adoption into meaningful value.
4. Google Site Reliability Engineering Workbook
A practical body of guidance covering service-level objectives, monitoring, alerting, incident response, postmortem culture, toil, overload, organizational change, and SRE team maturity.
5. Google SRE Team Lifecycles
Guidance for developing and scaling an SRE organization through different maturity stages while adapting practices to the organization’s context.
6. Microsoft Research: The SPACE of Developer Productivity
A multidimensional framework for understanding developer productivity through satisfaction, performance, activity, communication, collaboration, efficiency, and flow.
7. Team Topologies: Key Concepts
A framework covering stream-aligned teams, platform teams, enabling teams, complicated-subsystem teams, cognitive load, and deliberate interaction modes.
8. Google Cloud: How SRE Teams Are Organized
An overview of different approaches to SRE organization and practical considerations for companies beginning their reliability journey.
9. Google Cloud: How to Start and Assess an SRE Journey
A maturity-oriented guide for evaluating reliability practices and progressing toward more sustainable operational models.