Unbundling the Engineering Manager

Engineering organizations traditionally bundle a remarkable number of responsibilities into the Engineering Manager role.

Technical leadership. Delivery. Performance management. Career development. Feedback. Coaching. Conflict resolution. Team health. Change management. Organizational sensing.

These responsibilities are related. They do not necessarily need to be performed by the same person.

This paper examines an alternative: adding a dedicated Technical Coaching or Engineering People Partner capability that operates horizontally across the engineering organization.

The idea is not to eliminate Engineering Managers.

It is to recognize that some of the capabilities traditionally bundled into engineering management can be separated, specialized, and delivered across teams.

And adopting the model does not require an organizational transformation.

A company can introduce one coach alongside its existing structure without eliminating managers, changing reporting lines, reorganizing teams, or replacing existing People processes. The capability can sit within Engineering or operate as a dedicated People partner to Technology. Responsibilities can remain exactly where they are initially and shift only where specialization proves valuable.

A 15-month implementation inside a 125+ person R&D organization provides one real-world case study. A dedicated Technical Coaching function worked across Engineering, QA, Product, Design, Project Management, and technical leadership while maintaining direct access to senior R&D leadership.

Across the implementation:

Those numbers demonstrate adoption and perceived value. They should not, by themselves, be treated as proof of organizational impact.

The stronger argument comes from what the horizontal role made possible: earlier intervention in performance problems, leadership development, conflict mediation, career architecture, organizational sensing, support for difficult organizational changes, and individualized adoption of a broader AI strategy.

The implementation suggests a broader organizational design question:

The Engineering Manager occupies an unusually broad role within that structure.

Depending on the organization, one person may be responsible for some combination of:

There are good reasons this model became common. Engineering Managers are close to both the work and the people doing it, and strong Engineering Managers can perform many of these responsibilities exceptionally well.

But the model contains structural tensions.

The person accountable for delivery is also expected to protect time for development.

The person evaluating an employee's performance is also expected to be the employee's trusted coach.

The person accountable for a team's results is also expected to objectively diagnose dysfunction within that team.

And when a manager is part of a problem, that same management relationship may be the employee's primary mechanism for surfacing it.

These are not necessarily failures of individual managers.

They are properties of the role.

The Engineering Manager is, in effect, a bundle of organizational capabilities.

The useful question is not whether that bundle is wrong.

It is whether every capability in the bundle must remain there.

The word unbundling can imply dismantling something.

That is not the proposition here.

Unbundling means recognizing that technical leadership, delivery leadership, coaching, career development, performance support, conflict resolution, and organizational sensing are distinct capabilities, even when several happen to reside in one role.

Once those capabilities are recognized separately, organizations gain options.

Some may remain with Engineering Managers.

Some may be shared.

Some may benefit from dedicated specialists.

The resulting model can be represented simply:

The vertical structure preserves accountability.

The horizontal structure creates dedicated capacity across it.

This distinction is fundamental.

Many organizational innovations carry significant adoption costs.

They require reporting-line changes, new management structures, altered titles, redesigned processes, or a broad philosophical commitment before the organization knows whether the idea will work.

A horizontal coaching function does not have to.

An organization can add the capability while leaving its existing operating model intact.

Engineering Managers can remain Engineering Managers.

Directors retain their teams.

Technical leads retain technical authority.

HR retains its formal responsibilities.

Existing performance processes can remain in place.

The new function adds dedicated capacity for work the organization is already attempting to perform: development, coaching, feedback, leadership support, conflict mediation, change adoption, and organizational sensing.

This creates several possible adoption levels.

The model is also flexible in where it sits organizationally.

Two configurations are particularly natural.

Both configurations can work.

Most management systems are vertical by design.

Information generally moves through reporting relationships.

An engineer talks to a manager. The manager talks to a director. The director talks to a VP.

This creates accountability and local context.

It also creates information boundaries.

A manager may understand one team extremely well.

A director may understand several teams.

A horizontal role develops a different form of visibility.

It can work across teams, levels, disciplines, and reporting relationships.

Consider a simple example.

One engineer struggling to understand expectations may have an individual problem.

Eight engineers across five teams struggling with the same expectation may indicate an organizational problem.

A vertical system can discover that pattern.

A horizontal role is structurally positioned to encounter it repeatedly.

That changes the nature of coaching.

The conversation is no longer valuable only because it helps the person in the room.

It also becomes a sensor for the organization.

It is easy to interpret a Technical Coach as someone employees visit for career advice.

Career development is part of the role, but that framing significantly understates its potential.

In the implementation examined here, coaching touched:

The function therefore operated at two levels simultaneously:

Over time, hundreds of conversations can reveal recurring signals: unclear expectations, ineffective feedback, leadership gaps, organizational friction, resistance to change, career ambiguity, performance patterns, team dysfunction, and opportunities for process improvement.

That creates a feedback loop:

Traditional management contains an unavoidable dual relationship.

Managers want employees to speak openly about uncertainty, mistakes, frustrations, career concerns, interpersonal problems, and areas where they are struggling.

Managers also evaluate those employees.

Strong managers can create substantial trust despite that tension.

The tension nevertheless exists.

A dedicated coach occupies a different structural position.

Employees can discuss problems without assuming that every conversation is becoming part of their performance record.

But the coaching function cannot simply become a private organizational confessional.

It also has a responsibility to the health of the organization.

The model therefore depends on a critical distinction between individual confidentiality and organizational sensing.

Specific conversations remain private where appropriate.

Patterns do not have to.

When similar concerns appear repeatedly across teams, leadership can hear:

The model described above was implemented for approximately 15 months inside a 125+ person R&D organization.

Rather than relying primarily on traditional Engineering Managers, the organization placed substantial responsibility for architecture, execution, technical decisions, and engineering quality with highly technical leaders.

A dedicated Technical Coaching function provided much of the development, feedback, performance support, leadership coaching, conflict mediation, career development, change support, and organizational sensing capacity.

The role worked across Engineering, QA, Product, Design, Project Management, and technical leadership, with regular access to the CTO and other R&D leaders.

This provided an unusually broad test of the unbundling concept.

But organizations do not need to reproduce this structure to use the capability.

The case study demonstrates that these responsibilities can be separated.

A conventional engineering organization can choose to separate far fewer of them.

A voluntary coaching model depends on trust and repeated use.

The final coaching dataset contained 929 recorded sessions with 119 people.

Among those participants:

Across the full 15-month implementation, including people outside the final dataset, the function reached more than 130 people through more than 1,000 individual coaching sessions.

Post-session satisfaction data provided another signal.

Across 364 recorded responses:

These measures demonstrate adoption and perceived value.

They do not establish that coaching caused broader organizational outcomes.

That distinction matters.

Engineering organizations typically evaluate management structure in terms of headcount and reporting ratios.

Another scarce resource deserves equal attention:

Every one of these activities is valuable.

But they compete with architecture, engineering strategy, technical quality, execution, mentoring technical decisions, and solving difficult systems problems.

The question is therefore not:

Engineering organizations already make this distinction elsewhere.

Security specialists do not eliminate every engineer's responsibility for security.

Site Reliability Engineering does not mean application engineers stop caring about reliability.

Developer Experience specialists do not absolve teams from caring about developer productivity.

Specialization creates leverage while responsibility remains distributed.

Coaching and organizational effectiveness can be approached the same way.

The 15-month implementation provides an interesting initial data point for scale.

One dedicated coaching function served a population of more than 130 R&D professionals, conducting more than 1,000 individual sessions while also contributing to organizational initiatives, leadership development, performance systems, and change efforts.

That suggests that this is not necessarily a one-coach-per-team model.

A horizontal function can create leverage across a substantially larger population.

The more important point is that the model can be organizationally lightweight.

A company with 100 or 150 engineers does not necessarily need a coaching department.

It may need one well-positioned person.

That makes the model particularly interesting for engineering organizations large enough that senior leaders can no longer maintain meaningful individual visibility, but not so large that an extensive specialized people infrastructure already exists.

The important difference is not that the traditional model lacks these capabilities.

Without that capability, coaching remains primarily an individual benefit.

With it, coaching becomes organizational infrastructure.

A dedicated coach cannot compensate indefinitely for poor leadership.

It cannot fix a fundamentally unhealthy culture through individual conversations.

It should not become a substitute for competent HR, clear performance accountability, good technical leadership, or sound organizational design.

And the model introduces risks of its own.

These are meaningful risks.

But importantly, most do not require a large structural commitment to discover.

Because the model can be introduced additively, organizations can evaluate engagement, trust, outcomes, and role boundaries before expanding it.

This may ultimately be the most practical argument for the model.

An engineering organization does not need to believe this entire paper to test the idea.

All four are useful results.

The organization does not have to transform first in order to learn.

Engineering organizations routinely decompose complex technical systems into specialized components.

They do so because specialization can improve expertise, scalability, observability, and reliability.

Organizational systems deserve the same scrutiny.

The Engineering Manager is not an immutable unit of engineering organization design.

It is a bundle of responsibilities that evolved because placing those responsibilities together has often been practical.

Sometimes that remains the right design.

Sometimes specialization can create additional leverage.

A horizontal Technical Coaching or Engineering People Partner function offers one way to test that proposition without dismantling what already works.

The evidence from one 15-month implementation is encouraging: more than 130 people engaged in more than 1,000 sessions; nearly every participant returned; relationships persisted for more than a year; satisfaction averaged 9.4 out of 10; and the function extended beyond individual development into performance, leadership, conflict, organizational change, AI adoption, career architecture, and organizational sensing.

That evidence does not establish a universal model.

It establishes something more modest and potentially more useful:

The result does not have to be the elimination of management.

It can simply be better allocation of the work management is trying to accomplish.