Managing and Coding: Finding the Right Balance as a Technical Leader

Companies that expect managers to spend more than 50% of their time coding has a leadership mentality that does not align with mine. In my experience, it is difficult to be both an effective leader and a highly productive individual contributor at the same time. Success in management comes from fostering a strong technical team with skilled tech leads, allowing both the manager and the team to be productive in their respective roles.

The Role of a Manager Should Not Be Writing Code

A manager cannot be an effective leader if they spend more than half their time coding. Even spending more than 25% warrants an evaluation of priorities and responsibilities. If an individual prefers coding over leadership duties, they may be better suited for an individual contributor (IC) role, focusing solely on technical goals rather than the broader responsibilities of management.

While staying technical holds value, excessive coding comes at the cost of leadership, strategy, and team development. A manager’s primary goal is to promote the success of the team and unlock each engineer’s full potential. Team success should be measured by collective output, not by how much the manager contributes in code.

Core Responsibilities of an Engineering Manager

Managers should focus on key areas that enable their team’s success:

- People Development — Coaching, mentoring, performance reviews, and one-on-one meetings to support career growth.
- Strategic Planning — Roadmaps, cross-team alignment, and architecture decisions to ensure long-term success.
- Unblocking the Team — Removing barriers, handling escalations, and ensuring smooth workflows.
- Hiring & Retention — Recruiting top talent, growing the team, and maintaining a positive work environment.
- Stakeholder Management— Communicating effectively with leadership, product teams, and other departments.

I genuinely enjoy these aspects of management, but they are not for everyone. If these responsibilities do not align with personal interests, staying as an IC might be the better path. A manager coding more than 50% of the time is likely neglecting these responsibilities, which can hinder team success.

The Danger of Over-Coding as a Manager

Spending too much time coding as a manager introduces several risks:

- Slows Down Decision-Making — Deep focus on code leaves less time for strategic thinking and roadmap planning. Both require significant mental bandwidth, making it overwhelming to juggle both effectively.
- Creates a Bottleneck— The team may be blocked waiting for the manager’s code reviews or approvals. In my most recent role, I was an admin for merge requests, and engineers often pinged me for approvals while I was busy in meetings. If they were waiting on my code, the delays could impact productivity.
- Reduces Team Growth — ICs miss opportunities to take ownership if the manager is too involved in coding. I prefer to empower my tech leads to drive their projects, and over-involvement in coding can feel like micromanagement.
- Context Switching Overhead— Switching between deep work (coding) and leadership duties (meetings, 1:1s) leads to inefficiency and burnout. I advise my engineers to dedicate uninterrupted time to coding, minimizing distractions like emails and Slack. The same would apply to managers as any context switching can disrupt productivity.

Context switching has been widely studied in cognitive psychology and workplace productivity. Here are some key findings from research:

1. Cognitive Cost of Context Switching

• A study by Rubinstein, Meyer, & Evans (2001) found that task-switching leads to time losses due to the mental effort required to reorient. These “switch costs” can range from a few milliseconds to several seconds but accumulate significantly over time.

2. Decreased Productivity

• The American Psychological Association (APA) reports that switching between tasks can reduce productivity by up to 40%. This is because each switch forces the brain to refocus, leading to inefficiencies.

3. Increased Error Rates

• A study by Mark, Gudith, & Klocke (2008) found that frequent interruptions lead to more errors. Participants took longer to complete tasks and produced lower-quality work when frequently interrupted.

4. Impact on Deep Work

• Cal Newport’s book “Deep Work” (2016) discusses how frequent context switching prevents deep, focused work, which is essential for complex problem-solving and creativity.

5. Effects on Developer Productivity

• A study by Microsoft Research (González & Mark, 2004) found that software engineers spend an average of 10–15 minutes recovering their train of thought after an interruption.

Measuring Success as a Manager

Traditional metrics like lines of code or hours spent coding do not reliably indicate performance. As noted in the Stack Overflow blog, the best measure of engineering impact is “tasks completed multiplied by complexity,” rather than commits or raw coding time. Managers should focus on team outcomes and overall productivity rather than individual contributions to the codebase.

With AI copilots, coding efficiency has improved, but AI-generated code still requires validation and testing. While development may become faster, leadership responsibilities remain unchanged — mentoring, decision-making, and strategy still require human oversight.

When Can a Manager Code More?

There are cases where a manager coding 50%+ of the time is reasonable:

- In Very Small Teams (Startups, Early-Stage Companies) — If managing fewer than 4–5 engineers, more hands-on work is expected.
- During Critical Incidents — Urgent production issues may require a manager’s deep expertise.
- If the Role Is a Hybrid “Tech Lead / Manager” — This setup works for small teams (typically 5–7 engineers max), but does not scale as teams grow.

Once a team grows beyond this, staying hands-on for more than half the time becomes a liability rather than an asset.

The Right Balance for a Technical Manager

The optimal coding involvement for managers depends on team size and stage:

- Small Teams / Startups (4–7 engineers): 30–50% coding (Hybrid Tech Lead/Manager role).
- Mid-Size Teams (6–12 engineers): 10–30% coding (Architecture, PR reviews, prototyping).
- Larger Teams (12+ engineers): <10% coding (Technical guidance, but ICs own execution).

A good rule of thumb is to code just enough to stay relevant but not so much that it slows the team down. Side projects, MVPs, and proofs of concept are ideal ways for managers to stay hands-on without becoming a bottleneck.

A last point I want to call out is that my experience has been mostly in the Devops/SRE/Platform infrastructure space.

I think there is definitely more validity in more coding as an Engineering Manager for development teams vs Infrastructure/SRE teams. Generally there are more support responsibilities, incidents, firefighting, toil tasks, On Call rotations, releases, etc for Infra and SRE teams. So whereas the manager for a development team may be more focused on projects and delivery, there may be more emphasis on delivering code vs for Infra/SRE teams where stability, reliability, and security of the platform/system is usually the highest priority.

Effective engineering managers measure success by how well their team delivers, not by their own coding contributions. The best managers create an environment where engineers can thrive, grow, and deliver high-impact work. If leadership responsibilities are neglected due to excessive coding, both the manager and the team suffer. Finding the right balance ensures long-term success for both the individual and the organization.