You need to delegate tasks, it's part of your job. Train the new hires, add them to your project and let them do the majority of the work. And you shouldn't work on weekends and holidays.

This so many times. This has been my journey to becoming a competent manager in the past year. What’s helped is framing it as: if I was someone’s manager after a year have they grown more or less than if I wasn’t there. We grow through being challenged and trying on new responsibilities. Delegating running meetings, scoping larger amounts of work, giving presentations— whatever. If you do all these things yourself you’re both making more work for yourself and keeping growth opportunities from your reports. The positive feedback loop is your team gets more done AND when you see someone go from struggling to crushing it at something you used to do it’s incredibly rewarding.

Another lesson hard learned was realizing it’s not my job to do everything like an IC. And especially not my job to personally fix all people problems. I’m merely just here to guide and coax along the right path. And give lots of specific feedback on what’s good and what’s not so good.

A hope maybe this helps the grandparent poster. Your post resonates heavily with where I was at a year or two ago. Being a manager ain’t easy. I’d argue much more so if you were a really strong IC.

I wish that this helped. But my job title is programmer, and managing the 5 other people is just a side task. And there's so much work that the team is always split on several different projects. So in theory delegation sounds like a good idea, but I don't have spare capacity to delegate to. Nor do I have control of which projects we prioritize, those are coming from the CEO and CTO, and head of product -- one major project each.

I've known since university I'm bad at delegating things. Do I just have to learn by doing it?

Finally, what do you mean by IC? I'm pretty sure I'm not an integrated circuit, but I've never gotten the head X-ray to check for sure.

Personally I think I would write down your first paragraph or something similar to it and have a conversation with your manager using that as your guide. I’d be looking for clarity on what your priorities and responsibilities really are. E.g. does managing come first or programming? And if push comes to shove is one ok to drop for the other?

Another topic might be communicating the lack of bandwidth for the work. Maybe there’s scope creep or too much work on the plate and some needs to be dropped.

As far as learning delegation, yeah, that’s how I did it: trial and error. For me finding really competent people who I trust and who want opportunities to grow and take on new responsibilities has helped a lot as a kind of prerequisite.

And yeah sorry IC = Individual Contributor, i.e. not managing anyone.

You feel responsible for the project, that's normal and i would definitely pick you as a colleague. But you have to let go some of this responsibility; start being responsible for the delivery of the project and the internal goals, leave the technical work to the team. Instead of assigning tasks to yourself, assign them to your team members. Start with low priority tasks and move forward. If the team is competitive and the project is good, they will shine and you will feel better that you have guided them. It's definitely not a walk in the park, and at least you will fulfil your role as a team lead.

They probably mean Individual Contributor, which seems to be an American term for "just a dev, nothing else".

First, sorry to hear your story, that stinks.

Second, since you’ve presented this to upper management and they aren’t understanding, I’d take that as a serious signal to look for a new opportunity.

If you do want to stick it out, the best advise I have for you is to 100% drop coding even though you think you can’t. Allow yourself to whiteboard, pair program and review PRs, but don’t allow yourself to be the owner of single programming ticket.

Suddenly you’ll have a lot of time to pour into training, equipping, and leading your team. You’ll probably be surprised how much they improve.

It still might not work out, but given you already know how to be a programmer, taking a shot at 100% managing for a while gives you more opportunity to learn than sticking with the status quo you’re saying doesn’t work.

If you’re really struggling and would like more help, I’ve been doing some coaching lately and I’d be happy to book a chat. My gmail is the same as my HN username :)

This is really sad to hear. I'm curious to know why you have to do the majority of the programming?

It's a security-related task that required deep knowledge of how various parts of the monolith fit together. Half my team -- the side with the other senior dev -- is busy on another even higher priority project. Which leaves me with the choice of explaining to new hires how the system works, or doing it myself. Or really, which takes longer to do. Because of the security implications, I didn't want to take the risk with people who, well, don't have my level of paranoia.

Maybe I should have gone the teaching route, I'd have other people to blame. But a good manager should protect their employees, not the other way around.

Thanks for listening. I guess I'm just complaining on a throwaway because I don't have anyone else to talk to.

Don't write another line of code. Setup mob programming with your colleagues and stay away from the keyboard. Instruct them what to do and answer all their questions. It will be slow at first but highly deliberating when they've understood the task and they can be more or less autonomous.

“Effective delegation requires giving up some control of exactly how the work is to be executed.”

I believe the right option would had been to delegate, mentor and trust. Is never too late. Have been in a similar position myself a couple of times...

> Which leaves me with the choice of explaining to new hires how the system works

No documentation?

From experience I'd say there doesn't tend to be a great deal of documentation, or up-to-date documentation anyway, on a large monolith application.

Good software engineers are not necessarily good writers, so even when there is documentation it's not always helpful either. Especially to completely new people in a project without background information. For security related work, how much background can you assume? How in-depth does the documentation have to be? etc etc..

Documentation, even when it's there, doesn't always fix this.

Handing documentation over the wall is usually a futile exercise anyway. Documentation should be usually be pair-written by a knowledgable person and a newbie.

always train others

Can you not exercise what you’ve vested and move on to a more reasonable org?

Nothing has vested yet, nor will it until the company does an IPO. No IPO is planned. It's a 10 year old company, but only just raised its first round last year. In the old days, we were forced to survive on revenue generated from B2B sales, which was honestly not too bad.

My employee number is under 25, but it's still just pretend equity at this point.

Seems like you're labouring under false pretenses then.

A. What is the value of your equity?

B. What is the likelihood of it vesting in the next 5 years?

C. How much "total benefit" (salary increase, stress decrease, etc) would you gain from moving to a different company over the next 5 years?

If A*B < C, move.

Heck, even 5 years might be too long of a consideration here.