Unbundling the Engineering Manager

A bad version of this model would take feedback and mentorship away from people who understand an engineer's work and replace them with a coach outside the delivery chain. That was not the arrangement.

Feedback and technical mentorship that depended on seeing someone's code, designs, decisions, execution, or behavior stayed with leads, managers, and senior engineers. They had the local context to judge the work.

Career development was different. If someone wanted to think through what skills to build, how to grow toward another level, what direction to take, how to navigate a career decision, or what was getting in the way of their development, I was generally the person they talked to.

Career conversations and ongoing follow-through on development goals were primarily part of the coaching role. Leads and managers still wrote and delivered performance reviews, which could establish formal goals, but the continuing conversation about career direction and development generally happened with me.

Other responsibilities sat between those two ends. I helped leads and managers prepare for difficult feedback, worked through performance situations with them, advised on promotions and calibrations, mediated conflicts, and sometimes acted as an intermediary when two people were no longer hearing each other clearly. In those situations, the lead or manager still held the conversation or decision; my role was to prepare, advise, coach, or help afterward.

I also advised on performance improvement plans, terminations, promotions, and calibrations and could and did influence outcomes without owning the final decision.

The unbundling was selective. Work that depended heavily on seeing the work or exercising formal authority stayed close to the reporting structure. Career development and several kinds of developmental support moved to the coach. A horizontal role also made cross-team pattern recognition someone's explicit responsibility.

The practical constraint is attention. Career development, difficult feedback, conflict, and thoughtful coaching all take time, as do architecture, execution, technical quality, hiring, planning, stakeholder management, and everything else expected of engineering leaders.

Organizations have choices about where that work goes. They can give managers smaller spans, ask leads to absorb more of it, rely more heavily on People partners or external coaches, or create dedicated internal developmental capacity. The arrangement I worked in took the last option.

That did not eliminate the need for leads and managers to develop people through the work itself. Someone still needed to say: here is what I observed, here is what good looks like, and here is where you need to improve.

But the person making that judgment did not also have to be the primary person helping someone think through an entire career, resolve a conflict, translate feedback into development goals, or notice that the same problem was occurring across multiple teams.

A manager can understand one team extremely well. Someone who has recurring conversations across many teams develops a different view.

At Real, I worked with people across Engineering, QA, Product, Design, Project Management, and technical leadership. After one performance-review cycle, I repeatedly heard that people did not understand where their ratings had come from or what stronger performance actually looked like.

Any one of those conversations could have been treated as an individual concern. Hearing variations of it independently made it look systemic. I took the pattern to the division leads, and together we built role-specific performance rubrics and a self-assessment tool.

Coaching is not the only way to discover organizational problems. Skip-levels, engagement surveys, HR partners, calibration sessions, and attentive executives can all surface them.

A recurring coaching relationship creates another stream of information. Those conversations happen while people are trying to solve their own problems rather than responding to a survey or participating in a formal organizational process. That may reveal things other channels miss.

It also creates information asymmetry. A number of people told me things they had not told their lead or manager, and some said so explicitly. That was part of the value of the role and part of its risk.

A lead or manager has local context and accountability. They understand the code, the commitments, the history behind decisions, and how someone actually performed on a particular project. Their feedback can be precise because they saw the work.

A horizontal coach necessarily knows less of that detail. I generally understood what teams were working on, their organizational circumstances, individual challenges, and important interpersonal dynamics, but I did not know implementation details the way someone on the team did. When I lacked enough context, the right answer was sometimes to say so and involve someone who had it.

My engineering and delivery background appeared to help narrow that gap. People did not have to explain the basics of how an engineering organization worked before we could get to the actual problem: delivery pressure, technical career paths, team dynamics, or the language of the work. Trust formed faster than I expected. I do not know whether someone from a different professional background could have established the same credibility.

What distance provided was independence from day-to-day delivery pressure, broader visibility, and time. It was not independence from the organization. I reported to the CTO, advised on consequential personnel decisions, and could and did influence outcomes. That made clear boundaries around confidentiality especially important.

I told people they could share things with me in confidence, but I was also explicit that I was not HR or a therapist. If something affected the business, or management or HR needed to know about it, I could not promise it would remain inside the coaching conversation.

In practice, very little that people explicitly considered private overlapped with organizational decisions. Personal matters stayed private; organizational issues were surfaced when relevant, often as patterns rather than individual disclosures.

There was also a sponsorship cost. Someone close to the work is better positioned to say that an engineer is ready for a larger project, has demonstrated performance deserving promotion, or should be trusted with greater technical responsibility. I could help someone prepare for those opportunities and could influence promotion discussions, but my view was necessarily based on what the person and others told me rather than direct observation of the work.

The model depends on those perspectives complementing each other.

The individual coaching relationship was only part of the role. A significant amount of the work involved improving feedback happening elsewhere.

I worked with leads and managers before difficult conversations, helped turn vague criticism into specific expectations, discussed performance situations with them, and pushed for developmental feedback to become goals someone could act on.

Participation in optional midyear reviews was roughly 90 percent during the period. There is no prior-year baseline, and I personally tracked completion and followed up with people, so I would not treat that number as evidence for the organizational structure. Retrospectives also became more frequent by my observation, although I did not systematically measure them.

The point is what the role was doing: not taking contextual feedback away from the people who understood the work, but trying to make that feedback more frequent, clearer, and more useful.

In one performance case, management believed an engineer was approaching formal escalation. I was not independently evaluating his technical performance. Management had a view of what was going wrong; part of my job was to make sure he heard it clearly, help him examine what was holding him back, and coach him through what came next.

He eventually moved to a different project, and leadership later told me he was performing much better and had been given greater responsibility. His own effort, the project change, his manager, and other factors may all have contributed. The example shows how the role operated, not what would have happened without it.

Across the full period, the role reached more than 130 people through more than 1,000 individual coaching sessions. At the end of my tenure, 119 people were in the active coaching population. Most recurring sessions happened every six or seven weeks on a schedule I set. Participation was voluntary; people were not sent to me by leadership.

After sessions I offered an optional one-to-ten rating through Slack. There were 364 responses across those 1,000-plus sessions. The average was 9.4, and 84.1 percent were a 9 or 10.

Those numbers have obvious limitations. The ratings were not anonymous, respondents were rating someone with whom they had an ongoing working relationship, and the meeting cadence mostly reflected my scheduling rather than employee demand. Toward the end of my tenure, more people began requesting additional time on their own, which I regarded as a stronger signal of value, but I did not systematically count those requests.

The evidence therefore supports a narrow conclusion: the role reached nearly the entire organization, and people who chose to submit ratings generally reported valuing the sessions.

It does not demonstrate that the structure improved engineering performance, retention, delivery, or business outcomes.

There were encouraging individual outcomes, including the performance case above and situations where conflict improved after separate coaching and mediation. Those examples illustrate ways the role could contribute. They do not isolate coaching from the managers, leads, leaders, circumstances, and individuals involved.

One risk is fragmented accountability. I could and did influence consequential personnel decisions without formally owning them or being the person ultimately accountable for the decision. That places significant weight on the coach's judgment.

Feedback can also conflict. An employee may hear one interpretation from a lead, another from a coach, and another from senior leadership. The structure does not eliminate that possibility, so someone still has to reconcile those views.

Confidentiality creates another tension. The same privacy that encouraged candid conversations meant a lead could sometimes know less than the organization collectively knew. Clear expectations about what was private and what could be surfaced were therefore essential.

The role can mask weaknesses elsewhere. In one case, an employee's manager did not have time to write development goals, so I suggested that the employee draft them and give the manager something concrete to respond to. It worked for the employee, but it also compensated for a management-capacity problem rather than fixing it.

Not everyone wanted coaching. A few senior individual contributors declined regular sessions, and others participated without really opening up. I pushed some people toward sessions they did not want when I should have looked for other ways to be useful to them.

The implementation also had a single point of failure. I was the sole person in the Technical Coach role. Whatever worked depended on one person's credibility, judgment, relationships, and calendar, with no redundancy.

Some organizations may simply not need this structure. If managers already have manageable spans, strong development skills, and enough time to coach well, separating responsibilities may create more coordination than value.

This was one implementation in one organization, with about 35 technical leads for roughly 125 people, supportive senior leadership, broad access for the coaching role, and a coach with substantial prior engineering and delivery experience.

I cannot separate the effect of the structure from those conditions or from the specific people involved. Nor do I know how the model translates to an organization with sparse technical leadership, a different coach, substantially more or fewer people, or a different relationship between Engineering and People functions.

The traditional Engineering Manager role bundles these responsibilities because putting them together is often practical. Separating them is not inherently better, but the bundle is a design choice.

The useful question is which responsibilities benefit from being kept together—and which may work better when they are deliberately separated.

That is what one implementation cannot settle, but it makes the question worth asking.