Engineering Manager Decision Authority at 10–20 Engineers: Operational Role Clarity for Scale-Aware Tech Leadership

Defining Decision Authority for Engineering Managers at 10–20 Engineers

At this size, managers juggle technical oversight and people leadership across several workstreams. Decision authority splits between technical calls, cross-team work, and people issues.

Scope of Supervisory and Technical Decisions

Supervisory Authority

• Reviews and sets performance and compensation for all reports
• Hires within approved headcount/level
• Approves time off and manages schedules
• Handles small policy stuff (remote, expenses, tools)
• Deals with interpersonal escalations

Technical Authority

• Decides on architecture within team scope (microservices, APIs, data models)
• Picks tech stacks for projects under $50K
• Sets code review and deployment standards
• Prioritizes sprints to match the roadmap
• Owns incident response and post-mortems

Shared or Escalated Decisions

Managers at this scale make 60–80% of daily technical and people decisions solo.

Impact of Span of Control and Organizational Structure

• Flat org (Manager → VP): Full architecture, vendor, and hiring up to Senior.
• Layered org (Manager → Sr Manager → Director): Technical choices bound by group standards, hiring capped at mid-level.

At 10–20 engineers, most managers are still both technical and supervisory.

Role Design: Direct Reports, Coordination, and Managerial Archetypes

Direct Report Mix

• Only ICs: Manager keeps technical authority, reviews designs
• ICs + Tech Leads: Manager delegates tech calls, focuses on coordination
• Manager of Managers: Supervisory focus, technical calls go to leads

Coordination Work

• Syncing dependencies across 2–4 teams
• Aligning tech with product goals
• Managing shared infra/platforms
• Representing the team in planning/resource talks

Manager Archetypes

The hybrid model is the norm at this size. Empowering engineers keeps managers from becoming bottlenecks.

Practical Decision Boundaries and Execution Models at the 10–20 Scale

Decision authority at this scale splits across delegation, performance systems, and compliance. Clear tech lead boundaries are a must.

Delegation, Project Leadership, and Technical Lead Dynamics

Two-Pizza Team Rule

• Teams split into 2–3 sub-teams of 5–8 engineers
• Each sub-team gets a tech lead who owns daily engineering decisions

Delegation Pitfalls

• Manager approves every tech choice (bottleneck)
• Tech lead can’t reject bad work
• No written boundary between tech lead and senior engineer

Performance Appraisals, Job Role Evolution, and Compliance

Role Evolution Triggers

• Managers document role expectations separately for tech and leadership.
• Promotions need proof across projects, not just one.

Special Considerations: Holacracy, Regulations, Cross-Disciplinary Teams

Regulated Industry Rules

• Managers must sign off on work affecting safety, compliance, or regulatory docs.
• Tech leads in regulated spaces need domain training before getting authority.
• Senior software engineers can't approve mechanical designs without credentials.

Cross-Disciplinary Teams

Decision authority always follows domain expertise, not just tenure.

Frequently Asked Questions

How does the role of an Engineering Manager change when overseeing a team of 10–20 engineers?

Responsibilities at 10–20 Engineers

• Set up tech lead roles for technical direction
• Create architectural review that doesn’t need manager sign-off
• Build scalable performance reviews
• Use project prioritization for multiple initiatives

Responsibilities That End

• Writing production code
• Reviewing every PR
• Attending all design meetings
• Making every technical call directly

Rule → Example
Manager shifts from "doer" to "designer":
Rule: At 10–20 engineers, managers stop solving every problem and instead ensure the right people solve them.
Example: Instead of reviewing every design, the manager sets up a review process and lets tech leads drive it.

What are the typical decision-making responsibilities of an Engineering Manager with a mid-sized engineering team?

Decision Authority Matrix

Strategic Decisions (Manager Owns)

• Budget allocation for projects
• Hiring plan and team growth
• Engineering culture and standards
• Cross-team dependencies
• Technical debt strategy

Tactical Decisions (Manager Delegates)

• Sprint execution details
• Code review practices
• Testing implementation
• On-call rotation scheduling
• Dev environment tooling

Better decision-making frameworks clarify which decisions need the manager and which can be delegated.

Rule → Example

• Rule: Manager sets direction and constraints; engineers own implementation.
• Example: Manager defines project goals; engineers choose the libraries to use.

What is considered an optimal span of control for an Engineering Manager in technology companies?

Span of Control Table

Capacity Reducers

• Many junior engineers: subtract 2-3 from max size
• Distributed time zones: subtract 2-4
• Multiple projects: subtract 1-2
• Frequent incidents: subtract 2-3
• Complex stakeholders: subtract 1-2

Bullet List: Optimal Span Range

• 10-12 direct reports is ideal for most managers
• 15+ requires formal tech leads and more delegation

Warning Signs Table

What are the key challenges of managing a team of 10-20 engineers and how can they be addressed?

Challenge Matrix

Scalable Communication Structure

• Weekly all-hands: 30 min
• Tech lead sync: 2x/week, 15 min
• One-on-ones: every 1-2 weeks, 30 min
• Skip-levels: monthly, 30 min
• Architecture reviews: as needed, documented

Mistakes to Avoid

• Attending every technical meeting
• Making all decisions yourself
• Skipping documentation
• Delaying org changes until crisis
• Avoiding tech lead roles in large teams

Process Checklist

• Written team vision and strategy
• Documented decision framework
• Clear promotion criteria and ladders
• Project intake and prioritization process
• Incident response and postmortems

Rule → Example

• Rule: Manager builds systems for visibility, not personal tracking.
• Example: Use shared docs so anyone can see project status, not just the manager.