Eric Feigenbaum
Compare notes
For CTOs, CIOs and VPs of Engineering

Your engineering organization invests heavily in technology.Who invests, full-time, in the people who build it?

Technical Coaching is an embedded engineering-effectiveness function — I built and operated the role inside a 120+ person R&D organization, working across Engineering, Product, QA, Design, and leadership.

The gap

The work exists in every engineering organization. Ownership usually doesn't.

  • Managers navigating difficult people situations
  • Engineers unsure how to grow
  • Performance concerns that linger too long
  • Career expectations that vary by manager
  • Organizational friction reaching leadership late
  • Change — like AI adoption — that requires real behavior change

A Technical Coach gives someone responsibility for connecting those pieces.

Fig. 01 — Where the role sits
Technical Coaching
Individual
Growth, confidence, career direction
Manager
Feedback, delegation, hard conversations
Team
Practices, expectations, working agreements
Organization
Systems, signals, change that sticks

The role runs underneath all four layers, not beside one of them.

What I actually did

One role. Five leverage points.

At Real, the work came down to five recurring leverage points.

01

Stronger managers

I coached managers through feedback, difficult conversations, delegation, and the judgment calls that come with leading people.

Highest-leverage surface
02

Clearer growth and performance

Career ladders, competencies, development plans, and performance expectations.

03

Earlier organizational signals

Patterns, not gossip. Trends, not anecdotes. Confidentiality preserved.

04

Change that reaches daily work

Strategy — AI adoption, for example — translated into changed workflows and behavior.

05

A bridge between Engineering and People

Technical context plus people systems, without replacing either.

A conversation might range from a difficult feedback conversation to career direction, manager judgment, engineering practices, architectural thinking, or how AI was reshaping someone's day-to-day work.

Better managers. Clearer expectations. Earlier signals. More effective change.

The numbers

Technical Coaching in practice — one person, one organization

Coaching conversations
1,000+
Coaching conversations
Technical professionals and leaders coached
130+
Technical professionals and leaders coached
Average post-session satisfaction
9.4 / 10
Average post-session satisfaction
Of surveyed sessions rated 8 or above
96.7%
Of surveyed sessions rated 8 or above
Based on 350+ post-session surveys · Lead Technical Coach, Real BrokerageEngineering · Product · QA · Design · Project Management
From the inside

Eric joined Real as a Lead Technical Coach, which, at that point in time, sounded really weird. But over time, I realized how important his role was and the impact it had on the whole organization.

Shubham Randive · Engineering, Real Brokerage

I'm genuinely a more confident engineer because of his coaching.

Ashish Parimi

I always came away from those conversations with something specific to work on or think about, not just general encouragement.

Amrit Seshadri

He played a unique and valuable role at the intersection of technical leadership, people development, and organizational effectiveness.

Manish Kumar
More recommendations on LinkedIn
Why not just…

Embedded enough to understand the system. Independent enough to see across it.

Working inside the organization, I kept running into the same question: how is this different from the roles that already exist?

Engineering Manager
Should coach their own people, but carries delivery responsibility and sits inside the reporting line.
Dedicated development capacity, neutrality, cross-organizational visibility, and support for the managers themselves.
People / HR
Builds company-wide talent systems.
Deep technical context, embedded R&D relationships, and translation between engineering reality and People systems.
External Coach
Provides neutrality and coaching expertise.
Internal context, long-term relationships, pattern recognition across teams, and connection to internal systems.
Engineering / Agile Coach
Often focused on delivery, process, architecture, or Agile systems.
Careers, performance, leadership, and communication, alongside technical growth.

The point isn't to replace these roles. It's to connect the spaces between them.

Fig. 02 — Organizational sensing

How organizational insight actually moved. Trust worked in both directions.

Employees needed confidence a conversation wouldn't become a management issue. Leadership needed confidence I'd recognize what genuinely mattered.

Input · many private signals
Individual coaching conversations. Held in confidence, one person at a time.
Boundary → patterns only
×14
×9
×6
Only what repeats becomes a theme. Names, details and context stay behind the line.
Output · insight → action
Organizational insight
Leadership action
Leadership responds to systemic issues, not to individuals.
The exception, not the default
Individual conversationJudgment boundaryLeadership escalation

Patterns, not gossip. Judgment, not automatic escalation.

Most conversations stayed individual. Repeated themes became anonymized patterns. Genuinely material issues were surfaced when they had to be.

How I coached

The work was technical. The coaching was human.

What's going on with you outside of work?

Not empty small talk — I opened most coaching conversations that way because the engineer struggling with a manager, the new leader questioning their confidence, or the person deciding what they wanted next didn't stop being a human being when they opened their laptop.

Knowing the person made the conversation about the work more useful.

Outside the org chart

The person behind the coach

None of this makes me a better coach on its own. But staying curious about people outside of work — what they run toward, what they're learning, where they've traveled — carries into how I listen inside of it.

Running
Guitar & music
Spanish & travel
Photography · Scouting & mentoring
About Eric

I didn't learn engineering organizations from the outside. I spent two decades building and leading inside them.

Eric Feigenbaum is a technical coach and longtime engineering leader with more than 20 years in software and technology organizations.

He started his career writing software, then moved into technical consulting before spending nearly two decades progressing through engineering leadership — from engineering manager through Senior Director of Engineering at Syneos Health. Along the way he led global teams, developed managers and technical leaders, and worked through many of the same organizational problems he'd later coach others through.

Becoming a Technical Coach wasn't a move away from engineering — it was an evolution of it: from building software, to leading engineers, to focusing full-time on helping engineers, managers, and technical organizations become more effective.

Fig. 03 — Credibility came first
01Software Engineer
02Technical Consultant
03Engineering Leader
04Senior Director of Engineering
05Technical Coach
Builder → Leader → Coach
PMP · CSM
Get in touch

Curious how your organization handles this today?

If some of these problems feel familiar, I'd be interested in comparing notes.

No pitch deck required. I'm just as interested in hearing how other engineering organizations approach this.

Connect on LinkedIn
Replies come from Eric, not a sequence.