I'm not a 'Real' Engineering Manager, I'm a Player-Coach

The Myth of a full-time "strategizing manager"

For a small team in a startup environment strategizing isn't an 8-hour day 5 days a week. Management work often comes in bursts. If you force it, you end up with meetings that don’t move work forward.

On a small team, you either ship or you invent work.

Now that's not to say there's not a lot of work to be done, my job has consisted of the following and more:

• Establishing baseline standards and etiquette for PRs, and codebases
• Guiding the direction and strategy for consolidating tech stacks
• Researching, advocating for, and acquiring industry solutions for things like feature flags, Sentry, AI tooling
• Advocating and setting standards for tech debt work within sprints
• Establishing and evolving our delivery and agile processes over time
• Work with product on features, and MVP direction, requirements, and feasibility
• Regular bi-weekly 1:1s and 6-month reviews with each team member.

If you're in a similar role none of this is new. But as a leader you should allow the team the freedom to explore and bring the solutions. Your job and experience allow you to see the whole picture and guide and decide based on what you're given.

So what do you do with the leftover? You get in the trenches with the team and you produce. I try to contribute meaningfully every week, without stealing ownership from the team.

Unfortunately right now I'm not always succeeding at that, we're thinner than we used to be in some key areas, and the work still has to ship. This isn't an attempt to outshine anyone on the team.

It's the complete opposite. It's a way to show I'm here with you. I will push as hard as I can to ensure we all make it across the line together. I don't always meet that goal, some weeks are heavier with strategizing than others, but at the end of the day that's what makes me feel like I've actually "worked" for the day.

How did I get here?

I love the company I work for, I work for an extremely fast-paced small startup in the Christian space. I remember it clearly when I was offered the role of Engineering Manager, at the time I was hired as a lead Frontend Developer who somehow ended up maintaining three legacy Java codebases as a solo dev, and troubleshooting users' personal PCs. I had no idea how I got into the position I was in. It surely wasn't any Frontend Lead position I was used to.

When I was approached for the Engineering Position at the company's adjacent startup I jumped at the role. During the interview process for the EM role I was told I wouldn't need to develop, and in fact I shouldn't. I was taken aback, the role was to manage 6 engineers in the startup, along with the current role I was leaving. I thought to myself there's no way with so few people we could afford to NOT have someone actively contributing to solutions.

What my role actually looks like

Every time I take training on EM roles, read up on what I should be doing I begin to feel like a failure, like I'm letting the team down. I should be doing MORE strategizing, MORE unblocking, and no development.

I realized I'm not failing, and that I'm doing the best I can as an EM.

• I unblock hard problems for the team and provide direction
• I prevent regressions
• I set standards
• I keep the team focused on what's important now, and most importantly the WHY
• I translate the chaos into something we can build
• I try as hard as I can to protect people from thrash.

Coding is not the enemy.

If I'm not close to the code, I'm not close to reality.

It keeps me connected to reality, it keeps my judgment sharp, it gives me credibility, and it lets me remove some of the hardest blockers fast.

Much of my leadership style comes from what I learned from the military. The best leaders I remember by name didn't hide behind rank, they worked with us, trained with us, and didn't delegate effort they weren't willing to give themselves. That's always stuck with me.

The Warning

This is all well and good. The danger isn't me developing. The real danger is me becoming the bottleneck and the single point of failure. If that happens, it means something is broken, and there is a possibility I could be part of the problem. With recent staffing changes I'm closer to being a single point of failure than I want to be.

Before the recent departure of my teammate and friend, there was a healthy split. I took baseline work and small bugs so big features can move and the developer didn't need to focus on the noise, or we would swap the roles depending on risk and priority. I would stay out of the way but I made sure I was present when it mattered. No matter what the day looked like I would review PRs that same day.

How can we ensure we don't fail? As a leader you're the one who has to make the hard decisions. This one could be the hardest I've made yet. The goal now (and one I've started) is to train other members of the team on the Frontend stack. We still need to ship as fast as we were. We still need to get features done. The hard part is we're just going to have to be more pragmatic about scope and polish while we rebuild the redundancy we had in the past.

Am I failing?

If the system isn't stable it will feel like you're failing even when you're doing everything right. No matter what it's impossible to "lead" your way out of things like shifting priorities, and limited staffing redundancy.

What I'd tell anyone in my position is the following.

Don't apologize for doing the work. Just don't become the work.

• Do not apologize for being hands-on.
• Protect a commitment window.
• Always make risk visible
• And do not measure yourself against roles especially when your company size doesn't match.

I don't see myself as a manager who develops on the side, I'm a builder who leads, because that's the job this company actually needs from me right now, and that's the role I'm here to fill.