There is a leadership problem hiding inside many Engineering Manager job descriptions: the expectation that one person should simultaneously manage people, write production code, make architecture decisions, mentor engineers, deliver features, handle performance reviews, and somehow remain equally excellent at everything.

It sounds efficient on paper.

In practice, it can create a leadership role where nobody gets the person they actually need.

The Engineering Manager becomes too busy solving technical problems to properly manage the team. Then, when management responsibilities take priority, the same person is questioned for not contributing enough code.

Eventually, the manager learns an unhealthy lesson: visible technical output is valued more than the invisible work of helping people succeed.

That is where the problem begins.

A Tech Lead and an Engineering Manager can both have strong technical backgrounds, but their responsibilities are fundamentally different.

A Tech Lead is primarily concerned with the technical direction of the work: architecture, implementation decisions, technical trade-offs, engineering standards, and helping developers solve difficult technical problems.

An Engineering Manager has a different responsibility. The central question is not, “How should this system be built?”

It is, “How do we create the conditions for this team to do its best work?”

That means thinking about career development, team health, hiring, feedback, communication, performance, trust, psychological safety, stakeholder relationships, and the obstacles preventing people from succeeding.

Those responsibilities do not become less important simply because they are harder to measure.

In fact, they often become more important as a team grows.

A developer can point to a feature and demonstrate exactly what was delivered. A manager may spend an hour helping an engineer work through a difficult career decision, resolve a conflict, regain confidence after a mistake, or understand what is holding them back. There may be no obvious artifact at the end of that conversation.

But the impact can last for months or years.

Tip: Measure an Engineering Manager primarily by the health, growth, effectiveness, and stability of the team—not by how much code they personally produce.

The hybrid role becomes especially dangerous when leadership assumes that managing a small number of people automatically leaves enormous amounts of time for coding.

Three direct reports might mean three weekly 1:1 meetings. On a calendar, that could look like only 90 minutes.

But management is not simply the time spent sitting in a 1:1.

A manager is thinking about the engineer before the meeting, remembering previous conversations, preparing feedback, following up on commitments, coordinating with other teams, reviewing performance, considering career opportunities, addressing interpersonal problems, communicating organizational changes, hiring, onboarding, planning team activities, and watching for problems before they become serious.

Good management has a large amount of invisible work.

The problem with assigning an arbitrary split such as 80% engineering and 20% management is that it treats management as a collection of meetings rather than as a continuous responsibility.

Imagine trying to have a meaningful conversation with someone about their career while mentally debugging a production issue. Or trying to coach an employee through a difficult situation while worrying about an architectural decision that needs to be completed before tomorrow.

The problem is not a lack of effort.

The problem is divided attention.

Tip: Don't calculate management capacity by counting meetings alone. Account for preparation, follow-through, coaching, coordination, and the mental responsibility of leading people.

None of this means an Engineering Manager should be technically clueless.

Quite the opposite.

A strong Engineering Manager often comes from an engineering background because technical experience provides valuable context. It helps the manager understand the pressures of the work, recognize when a problem is genuinely difficult, communicate credibly with engineers, and understand the consequences of technical decisions.

Technical credibility can build trust.

But technical credibility is not the same thing as being the team's primary technical contributor.

There is a meaningful difference between understanding the codebase and owning the codebase.

An Engineering Manager should be able to participate in technical discussions, challenge assumptions when necessary, understand major architectural choices, and provide useful guidance based on domain knowledge or previous experience.

That does not mean the manager needs to be the person designing every system or writing the most important code.

In many teams, senior engineers and Staff Engineers are closer to the implementation details than the manager is. They may have more current context and more time to explore the technical trade-offs.

Delegating technical authority to capable engineers is not a sign that the manager is weak technically.

It is a sign that the manager understands how leadership scales.

Tip: Stay technically credible enough to understand and challenge important decisions, but resist turning technical involvement into personal ownership of every difficult engineering problem.

The obsession with the “unicorn” manager often comes from an understandable desire for efficiency.

Why hire separate people for management and technical leadership when one person might supposedly do both?

Because specialization exists for a reason.

A healthy engineering organization can pair an Engineering Manager with a Tech Lead or Staff Engineer.

The manager can focus on people, team health, organizational alignment, and execution. The technical leader can concentrate deeply on architecture, technical mentoring, engineering quality, and difficult implementation decisions.

Neither role becomes less important.

They become clearer.

This creates a useful division of attention. The Engineering Manager does not have to abandon technical understanding, while the Tech Lead does not have to suddenly become responsible for performance reviews, career development, hiring, team culture, and every interpersonal issue.

On larger teams, the same principle can extend further. Product leaders can focus on product direction. Design leaders can focus on user experience. Project or program leaders can focus on coordination and delivery.

The goal is not to create more titles.

The goal is to prevent critical responsibilities from competing for the same person's limited attention.

Tip: Design leadership partnerships around complementary responsibilities. Ask who owns people, technical direction, product decisions, and delivery coordination instead of expecting one person to own everything.

The hybrid-manager problem becomes much harder to solve when senior leadership treats technical output as the highest form of credibility.

If Directors and CTOs continue to emphasize code, architecture, and technical control while giving little attention to coaching, communication, empathy, or team health, that behavior becomes a model for everyone underneath them.

Future managers learn what gets rewarded.

If the engineer who writes the most code receives the strongest recognition, while the manager who develops five people receives little visible credit, the organization sends a very clear message about what matters.

Over time, technical ability can become the organization's unofficial currency.

That can produce leaders who are technically impressive but uncomfortable with the human side of leadership.

The consequences are not always immediate. Teams can still ship software. Projects can still meet deadlines. Technical systems can still work.

But people may become less willing to speak honestly, ask for help, challenge decisions, admit mistakes, or stay with the organization.

A technically sophisticated company can therefore have surprisingly poor leadership.

Tip: Look at what your organization rewards, not just what it says it values. Promotions, recognition, and performance reviews reveal whether people leadership is genuinely respected.

One of the hardest parts of becoming an Engineering Manager is accepting that much of the most valuable work no longer looks like individual contribution.

Hiring a strong engineer may take weeks but create value for years.

Helping an employee grow into a senior role may take months.

Resolving a team conflict may prevent weeks of lost productivity.

Creating psychological safety may allow someone to raise a serious technical or organizational problem before it becomes expensive.

Building a relationship with another department may remove a recurring source of friction.

None of these accomplishments necessarily produce a pull request.

That does not make them less real.

It means the organization needs different ways to evaluate them.

An Engineering Manager should be accountable for outcomes such as team development, retention, performance, collaboration, hiring quality, clarity, and the ability of the team to operate effectively.

Technical understanding should support those outcomes rather than replace them.

Tip: Make invisible management work visible through meaningful outcomes: stronger teams, better decisions, healthier collaboration, successful hiring, employee growth, and fewer recurring organizational problems.

There is also a personal decision hiding inside this organizational problem.

If the most satisfying part of your week is designing systems, debugging difficult problems, learning new frameworks, and writing software, there is nothing wrong with wanting an engineering career.

You may simply be better suited to a Staff Engineer or technical leadership path.

If what genuinely interests you is helping someone grow, understanding what motivates different people, improving team dynamics, coaching engineers, resolving difficult conversations, and creating an environment where others can perform at their best, management may be the better path.

Neither direction is superior.

They reward different strengths.

The mistake is assuming that becoming a manager means continuing to perform the old engineering job while adding people management on top.

That eventually creates two full-time jobs competing for one person's attention.

And when the organization inevitably forces a choice, something suffers.

Usually, it is the team.

Tip: Pay attention to the work that consistently gives you energy. Your long-term career path should reflect whether you want to multiply your own technical output or help other people become more effective.

There is another warning sign worth taking seriously.

Suppose an Engineering Manager suddenly becomes responsible for a large portion of the codebase because the team has lost people. Or leadership becomes suspicious because the manager is no longer contributing enough technically. Or a staffing reduction leaves the manager as one of the only people who understands a critical system.

The obvious response may be to roll up the sleeves and start coding again.

Sometimes that is necessary in an emergency.

But there is a difference between temporarily helping a team through a crisis and quietly becoming the team's missing Staff Engineer.

If the organization repeatedly depends on the manager to fill technical staffing gaps, the role has effectively changed without anyone acknowledging it.

That creates a dangerous cycle: the manager spends more time coding, people-management quality falls, the team becomes less supported, and leadership then interprets the decline as evidence that the manager should become even more technically involved.

The solution is not always “work harder.”

Sometimes the real problem is that the organization has failed to staff the team appropriately or define the role properly.

Tip: If a management role repeatedly requires you to rescue the codebase, treat the staffing and role-design problem separately from the immediate technical emergency.

The distinction between Engineering Manager and Tech Lead is ultimately about more than job descriptions.

It is about what happens when technical organizations forget that software is built by people.

A team does not become effective simply because its engineers are technically talented. People need clarity, trust, feedback, growth, recognition, psychological safety, and a manager who actually has enough attention to understand what is happening around them.

That does not mean management should become soft or disconnected from results.

Good people leadership is directly connected to execution.

A team with strong communication can surface problems earlier. Engineers who trust their manager are more likely to raise concerns. People who see a future for themselves at the company are more likely to invest in their work. Senior engineers who are trusted with technical decisions can develop stronger ownership instead of waiting for a manager to approve every detail.

The best Engineering Manager may therefore write less code than the engineers on the team.

That is not necessarily a failure of technical leadership.

It may be evidence that the manager is doing the actual job.

The real measure is not whether one person can perform every role simultaneously.

It is whether the organization has created a system where the right people can focus on the right work—and where leadership recognizes that helping people succeed is itself serious engineering work.

Tip: Don't build teams around heroic individuals who do everything. Build leadership systems where technical expertise, people management, product thinking, and execution each have enough dedicated attention to succeed.

Instead of asking, “Can this Engineering Manager still code?”

A better question is:

“What does this team need this person to be accountable for?”

If the answer is technical architecture, implementation standards, and deep technical mentorship, that sounds like a Tech Lead or Staff Engineer role.

If the answer is developing people, building trust, improving team health, hiring, coaching, handling performance, and creating the conditions for sustained execution, that is management.

An Engineering Manager can absolutely understand technology.

A Tech Lead can absolutely understand people.

But understanding both does not mean one person should be expected to perform both jobs at full intensity.

Your team does not need a unicorn.

It needs clarity.

And sometimes the most mature technical leadership decision is knowing which responsibilities should belong to someone else.

What’s your next spark? A new platform engineering skill? A bold pitch? A team ready to rise? Share your ideas or challenges at Tiny Big Spark. Let’s build your pyramid—together.

That’s it!

Keep innovating and stay inspired!

If you think your colleagues and friends would find this content valuable, we’d love it if you shared our newsletter with them!

As the world becomes increasingly digital, this question will be on the minds of millions of people seeking new income streams in 2026.

The answer is—Absolutely!

Thank you for taking the time to read today’s email! Your support allows me to send out this newsletter for free every day. 

 What do you think for today’s episode? Please provide your feedback in the poll below.

Share the newsletter with your friends and colleagues if you find it valuable.

Disclaimer: The "Tiny Big Spark" newsletter is for informational and educational purposes only, not a substitute for professional advice, including financial, legal, medical, or technical. We strive for accuracy but make no guarantees about the completeness or reliability of the information provided. Any reliance on this information is at your own risk. The views expressed are those of the authors and do not reflect any organization's official position. This newsletter may link to external sites we don't control; we do not endorse their content. We are not liable for any losses or damages from using this information.