When you’re an engineering manager in a small team, you often find yourself in a frustrating situation — you still write code while performing your engineering duties.
At first, it feels okay. Managers should stay technical to really understand day-to-day work. Over time, though, it becomes clear that this setup isn’t working.
Imagine Ben, who manages a team of engineers but tries to take on complex features that touch multiple systems. Instead of collaborating like everyone else, Ben runs with it solo because of his limited time. The result isn’t pretty — the code is messy and seems rushed. Ben doesn’t have enough focus to handle such a level of complexity.
His engineers are drowning, trying to meet deadlines. They can’t provide enough code reviews to catch Ben’s issues. So, over time, teams accumulate a good amount of technical debt. As a result, their core flows become fragile and a pain to change, with even minor tweaks now needing bugfixing and thorough regression testing.
Plus, Ben misses chances to mentor others. And with poor standards for his code, it signals to junior engineers this is the bar. The best way to lead is by example, but the situation is awkward with Ben controlling critical projects and having so little focus.
Schedule Conflicts
The reality is Ben’s schedule as a manager just doesn’t work well with heads-down, complex coding work. His days are consumed by back-to-back meetings — 1:1s, product discussions, cross-functional things. There’s barely enough time for him to eat lunch, let alone focus for hours on designing and writing software in this position.
Coding, especially on critical paths, requires deep concentration for a prolonged time. It’s not something you can start, switch to a meeting, and then pick back up easily. Ben’s rushed code shows the impact of constant context switching. And when you’re an engineering manager, you work on the manager’s schedule.
On top of meetings, Ben has to prioritize team needs and move projects forward. There’s no time to dig into tricky technical problems while supporting engineers and unblocking them.
The only way for managers who insist on writing code is to stick to short, self-contained projects, like bugs, small tools, and minor tweaks. This lets you contribute without compromising the availability to the team.
Unless Ben gets very disciplined with time management and sacrifices his personal time (a terrible long-term option), his schedule and coding will always clash. The result is distracted, lower-quality work that slows the team down on all fronts.
Poor Development Skills
The other common issue with many problems is when a manager’s development skills don’t match the complex, high-impact work he takes on. This happens either with managers who haven’t been coding a lot daily for a long time or when they’ve been promoted to management early in their careers.
For example, I’ve been managing engineering teams for more than 8 years now. If I try to sit down and tackle something big today, chances are I will fail miserably or do everything extremely slowly. Even though I was a senior engineer back in the day, I’ve lost the tone of engineering muscles over the years. I’m sure I could restore it if I wanted to, but it will take quite some time.
Another problem is when someone is promoted too early, say, with only three years of experience. Being just the middle of the road at the promotion time, the manager would now try architecting the core features that keep our business running. The outcome would be rough — short-sighted designs that just don’t cut it for production systems.
Because the manager’s dev skills aren’t up to par, the team ends up with quick band-aid fixes rather than robust, thoughtful solutions. It just creates nothing but cleanup work for the rest of the engineers down the road.
This might work if the manager writing production code has at least 8–10 years of solid experience and keeps coding hardcore while performing management duties (which is unrealistic). Because otherwise, the mismatch really drags the whole team down.
Managers with engineering backgrounds are eager to take on some challenging coding projects. I am like that myself. But we should avoid the temptation and delegate these tasks to the team when our skills clearly aren’t ready for this level of responsibility.
Growing Technical Debt
One massive downside to Ben’s code lacking proper oversight is accumulating technical debt. Since Ben doesn’t have time to join developer standups, demos, and retros, his work is largely invisible. Engineers are usually heads-down in their tasks and don’t see what Ben is building until it’s too late.
Code reviews are likely rare and ineffective because of Ben’s senior position. By the time someone notices issues, changing the course is not an option. There’s no one to mentor Ben as he takes on complex tasks beyond his capability. And without guidance, he repeats mistakes and creates more debt.
Over time, the debt piles up as more features get layered atop fundamentally flawed designs. Eventually, it becomes an exponentially painful mess to pay back.
Of course, requiring reviews from the leading engineers could help. Enforcing more rigorous code quality practices and including Ben in team practices will have even more impact. But realistically, it’s challenging because of the limited time and awkwardness created by his leadership position.
Junior Engineers Follow Bad Example
I have also seen junior engineers modeling their work after subpar code someone like Ben writes. This creates some unhealthy precedents and slowly erodes the team’s coding standards.
The junior folks don’t have the experience to recognize messy, low-quality code. To them, Ben’s work is what proper software development looks like. So they start picking up bad habits — not collaborating, taking shortcuts wherever possible, and choosing quick fixes over quality solutions. The codebase becomes even more fragmented as more people optimize for speed over maintainability.
When Ben ignores best practices like testing, reviews, and refactoring, it signals to juniors these things aren’t necessary. So they stop doing them, too.
Leading engineers will try to guide them through reviews and pair programming, but it only works so long. And they get confused when the feedback they get contradicts Ben’s approach.
This situation also robs them of learning opportunities. Juniors progress fastest when mentored by more experienced engineers and see good code written by them. Ben doesn’t have enough time and focus for either of them.
Sadly, mediocrity becomes the norm over time unless someone builds a culture of excellence from the top down. It takes consistent modeling, enforcement, and coaching.
We all want to see junior engineers reach their full potential. But with Ben setting the example, it makes that much harder.
Walking the Thin Line
It’s tough for engineering managers to handle coding and people management roles. Doing both well requires walking a tightrope act. From where I stand, managers should manage, and engineers should write code. There are only so many hours in the workweek. If you want to do something well, you must maintain focus.
Yet, if your unique situation, team structure, and projects allow it, here’s how you can combine management and coding jobs:
- Block off calendar time for focused coding without meetings
- Only take on small tasks matched to your current technical competencies
- Increase visibility through code reviews and joining team rituals
- Set positive precedents for junior engineers through your own code that follows your team’s standards
- Gradually shift your time towards people management if you want to grow as a manager
The ideal situation is for managers to stay off the critical path and focus on lower-priority tasks. This for sure hurts your ego but allows you to write code without compromising your availability to support the team.
Transitioning away from coding takes a lot of work. But managers and teams can make it work with patience, coaching, and setting clear expectations.
Originally published on Medium.com