you’re not technical enough. writing code won’t fix it.

· 14min · leadership, career

introduction

One of the questions every engineering leader has to answer as soon as they become a people manager is “do I stop coding?” This was a terrifying time for me because I had no one to ask. I watched some managers code huge features while others delegated everything leaving me to wonder what they actually did.

Necessity forced my hand, since we didn’t have a product manager and I quickly had twelve direct reports, so I didn’t code. Would I consciously make the same choice? I can’t say. But I do know this: do whatever it takes to own that choice yourself by understanding the role, the team, and the stakes.

defining the role - engineering manager

An engineering manager’s (EM) primary role is to ensure the consistent delivery of high-quality technical work through their team. This work is delivered regularly with coordination through a product owner or equivalent. The most common argument they will bring is “we need to perform this technical upgrade” and will hear most often “why are your engineers too slow?”

Engineering managers are expected to be at a senior engineer level, as they will need to be able to evaluate work going to their team for completeness and feasibility, and sometimes to estimate that work directly and provide delivery timelines.

This role remains closest to the code and the teams delivering it, and they are often the first and only one advocating for the individual contributors (ICs).

what your team needs

The team that reports to you needs someone that can take them places they can’t get on their own, through facilitation, blocking, and guidance. The urge to jump in and solve problems yourself remains strong at this level, but remember that your impact is through force multiplication and empowerment of your team.

a manager more than a developer

A key thought I had when figuring out how to be a good EM was: if they just needed another developer, I would still be a developer. Remember that you are in this role to facilitate the team, and help them grow as both individuals and as a team. You are also there to block for the team, making sure that your team is able to focus on delivery. If you find yourself in a role that is simply coding plus yearly reviews, then I would challenge that you are not actually managing anything at all.

You’ll always wonder if you should just pick up a ticket to speed up the team, and this is a good instinct. You want to help, and you can code, so that’s a pretty clear line to draw. Sometimes it’s the right move, but you want to make sure that if you cannot finish a work item that you’re not the one preventing delivery (because you will inevitably get pulled away for the manager part of the role). Facilitate, don’t inhibit.

Engineers are bombarded with “simple” task requests and questions in their DMs. If someone isn’t jumping in the way, they’re prone to not have time for any planned work. You need to communicate to stakeholders (even your product owner) to come through you, and you need to make it safe for the engineers to say “put this in a public channel and tag my manager.” Be a “shit umbrella.”

Finally, you’re the career guide. How can you help them succeed at getting where they want to go in their career? You need to align their needs to the business outcomes, and work with them year-round. If you reach the year-end review and they’re surprised at your feedback, that’s your fault. Be direct, but compassionate. Give them credit for their wins, and help them refine their pitch for the next role. You are the most important voice in the room for your team at promotion time.

Work all year to deliver work everyone can be proud of, and then fight like hell for them.

early career: hands-on technical guidance

When someone on your team is early in their career, they’ll need you to be direct and hands on. You will need to free up your time to pair program and do hands-on code reviews. No, you don’t get to LGTM an associate developer’s pull request, even if they are really smart and capable. This has the added bonus of not interrupting (and blocking for) your more senior team members so they can focus on delivery.

One thing I appreciated early on was a manager who helped me prioritize, and he never made me feel like I should already know. Remember that even the best engineers get overwhelmed, so your early-career team members need even more guidance here. Sometimes you just need to tell a developer what to do, while the teaching moment comes later.

You’re helping them build the tools and habits they will use throughout their career. Be patient and encouraging, and they’ll dig deep for you.

middle+ career: delegation and peer review

Transparently, middle career team members can be harder to manage than early ones. They need less from you in their day-to-day, and they might not even realize how much you’re blocking and facilitating for them if they’re focused on their tasks. Some senior engineers may even challenge your feedback directly, especially if they have been coding longer than you did before managing. This is dangerous territory, as these are the first people to complain about useless middle management. These are the team members the product is built on, not people you can simply demand authority over, and you shouldn’t try.

Instead, treat them as technical peers. Have higher-level discussions about approach, testing, gotchas, and infinite edge cases. Bring them into architecture planning sessions. Help them level up their code delivery by ensuring they can tie it to business value. If they want to teach, make space for them to do so.

For their career growth, don’t think about directing them, but instead delegate where you can. I have more discussions around ownership and accountability at this level. Give them hard, interesting work and let them own it. Then support them, and hold them accountable to the outcome.

what your boss needs to see

You will be held accountable for what your team delivers and the quality in which it is delivered. You want to make yourself responsible for those items as well, through ownership, understanding, and communication.

improved velocity

Velocity has become a bit of a loaded term, and too often managers will push the team for “numbers going up” every sprint. This is pretty much guaranteed to backfire as the team will immediately start padding their estimates, which means you’ll see higher numbers and produce equal or less value. What you need to focus the team on is continuous improvement. Stop caring about improving the estimation number and work on the thing that truly matter. This has nothing to do with what your product owner is communicating either. Any good engineering leader will be interested in the same information, and they will feel like you should have those answers.

Focus the conversation on delivering value, not delivering developer hours.

developer ownership

Sometimes, a developer looks at a story, looks at the deadline, and produces a feature as narrow to the acceptance criteria as possible. You need to be involved enough, especially with those early-career engineers, to know whether they’ve covered failure states, edge cases, and other deviations from the happy path.

Why does your boss care? First, no feature survives contact with the users, and you need to be shipping features that can handle that. Otherwise you may be on the wrong side of quality deliverables mentioned above.

Ideally what you’re curating here are “heads-up” developers. They produce features that have had scrutiny and care poured into them before ever reaching a demo stage. These are the individual contributors that your boss wants to see you grow, the ones that become less dependent on you because you’ve mentored them to be so. Engineers like these go on to seed new teams and grow the depth of the organization while leveling up the quality.

full project understanding

Understanding where your team’s projects are and being able to communicate that is something you’ll end up doing way more than you expected. Sometimes your manager will be looking in Jira and asking follow-up questions. Other managers expect you to be pushing information to them in a way that is both valuable and clear.

This might be the hardest balance to find with your team and manager. Too much involvement in what your team is doing and you come off as untrusting and intrusive. Too little and you are giving vague updates to your manager, which makes you look detached.

The answer is exactly what the good managers above you are doing. Get into Jira (or whatever system you use) and see where work is. Follow up with your team after you’ve already dug in. Is the work stalling in development? Ask how to unblock. Pull request in endless reviews? Sit down with the engineer and go through it together. Product owner not reviewing? Facilitate.

You’ll know where the team is by being involved without hovering. Deep dive where and when you need to. As a side benefit, you’ll have a curated work board that you can tell your own manager to look at before asking endless status questions.

alignment to their expectations

This is the “it depends” section, and I would be remiss if I didn’t mention that there will always be caveats to statements of truth. At the end of the day, your role and expectations are governed by your direct manager, and you should align yourself to them. Sometimes this means directly coding (as I am in my current Team Lead position), other times you are asked to handle org-wide projects that pull your focus away from the team. Still others, you’re handling the product owner position as well as being the team manager position.

When you’re in these situations, you still have agency, and you should still take responsibility for how you want to lead and not just manage.

Drive your interactions with your manager so that you know what they expect at all times. Change the expectations where you can to align with your vision of a successful team, and lead the way for others to be successful in your wake.

the duality of man(agement)

I want to close out with some traps you can easily fall into when you over-index one way or another.

coding can make you a bottleneck

As mentioned above, if you take on some critical feature to deliver and you fail in that delivery, you can block the entire team. You also are putting your accountability and responsibility on them, as your role interfered with team delivery. Managers and stakeholders don’t care that you had something else that came up, they just know your team failed to live up to the expectations.

This is the easiest way to destroy trust and morale from your team, and luckily it’s easy to avoid. If you have to pick up coding work, take supportive tasks, not the critical ones.

not coding can hide your impact

As a Team Lead, I’m expected to deliver code, and I’m aligned with my manager on what that means. However, I’ve run into a situation at times where I don’t have the capacity to take on feature work during a sprint. This feels like I’m letting everyone down because my team doesn’t have the context of what I’m doing instead, only that they’re down a person.

This reinforces the engineering manager dilemma, and it requires communication both up and down the chain. If you aren’t going to be coding because of the role or by circumstance, your team and manager both need to know that. Set expectations clearly and then over-communicate with your team. Inform them of what’s taking your time, and be as transparent as you can.

The best thing you can do though is come through for the team via promotions, growing the team, reducing distractions, or generally showing up and being their voice. Show every individual contributor the value you are bringing by making it real for them.

don’t settle for disappointing everyone

You can’t always find the magical balance where everything works out. Sometimes you will absolutely have to focus on the business more than the team (or vice versa). If you try to do it all, you’ll fail at both.

You need to take responsibility, you need to lead and decide where your focus will be, and you need to communicate it more often than you think is necessary. Know what your team expects of you, make sure your manager is aligned to your vision, and then execute.