First - you're not alone! I see this alot in folks that are only just starting in technical leadership, particularly when they are promoted from within an organization where they were excellent individual contributors.
Some thoughts - I find this to be an oddly assorted collection, even in my own mind, so I never really have a perfect model... but here's some tidbits I've picked up over the years.
The Efficiency Ratio
The efficiency ratio is the time it would take for you to do something vs. the time it will take the person to whom you are delegating. First, realize that your time is now precious for reasons other than your ability to be a great individual contributor - you need to address communication needs that team members simply can't do, you need to see a big picture and get the team moving in the right direction, you need to set out rules that lead to consistency and coalition - in many cases, team members can't do that part, and if you skip these parts, you decrease the efficiency of the whole far more than you increase team efficiency by doing work better than anyone else.
To compensate, I use a ratio for work that can be delegated:
2:1 - IMO, the absolute minimum - if you can do it twice as fast as the person you give the work do, you should still delegate. At 3:1, maybe keep it. Seriously. Two big reasons - people get more efficient through learning by doing, so the first time your team member may take twice as long as you would, but the second time the ratio will be more in their favor. Second - you add at least that much value by coordinating the team's work.
5:1 - a better ratio still for a busy team of 5 or more with a reasonable level of "organizational overhead". "Organizational overhead" is the work that only a manager can do - that includes getting annoying people off the back fo your team, coordinating with other groups so work transitions smoothly, seeing the big risks and preparing for them, etc. The more of it there is, the more your time is at a premium, and you need to let your team take on more work. Even if it will take you 1 hour and your best team member 5 hours - let them do it.
20:1 - the ratio I actually used when I last ran a team that did the same things I could do. I was a subject matter expert in the work, but I wouldn't touch a box until 1 hour of my time would save my folks nearly 3 days of work. It reduced my individual contributor time to mere hours in a week, but when leading a team of 12-20 people, with a high organizational overhead load - it was absolutely critical.
The final point on this element being - it's a sliding scale. A small team, in an informal situation can operate with a way more hands on lead than a big team in a highly structured company. But keep an eye on your own ratio and adjust as needed. You know you have this ratio wrong when you are working 60+ hours and everyone on your team is going home in 40-45 hours.
I go so far as to voice this ratio and vet it with senior management. My management pretty much patted me on the back when I mentioned my insane sounding 20:1 ratio - they knew how much they needed a manager to be managing and they were very happy that the only time I took my eye off the management stuff was to go putout a 5 alarm inferno.
Don't let the best be the enemy of the good
Easy to say, hard to do. Realize that while you are free to make yourself crazy with your own perfectionism - if you nitpick your team member's work to the point of perfection, you will both drive efficiency into the ground and cause a rapid turnover in employment.
My best advice here is to focus on the goal - you want to develop something, it has certain requirements. When they are met, you are done. Dicuss these requirements, get folks that work on the team to re-iterate them so they can be agreed upon, then at the end, look for a demonstration of the requirements. If they can demonstrate success, leave it be.
From time to time, there will be a need to go through and clean up the mess of imperfect decision making. This is going to be true whether you were perfect or not. For the most part, that last 10% of perfection is only perfect to a specific individual. Doing consolidated cleanup is healthy and worth doing with an eye to setting a standard that becomes part of the work requirements. Get group buy in on these standards, and you'll get a status quo that people will enforce without much work from you.
A key test for this is "what will go wrong if we do it not-my-way?" - if the answer is nothing or not much - leave it be.
Stay hands off
If you take a part of the project to work on - fine.
But stay out of the way when you've delegated. If you have issues with the work, and these issues really do matter for the success of the project - give that feedback to your people and let them fix it. Fix it for them, and you break a type of trust - the trust that if you have issues or concerns, you'll come to them and ask for a fix.
Where you can - cross delegate - avoid looking over every part of the code yourself - set a standard and ask the team to help each other. Peer reviews are a great tool here. So is paired programming. Anything that gets multiple eyes (not just yours) on a peice of work.
This is one of the nicer places to stay absolute - if you find your hands twitching on the keyboard to just change this one little thing, don't do it. Give the note instead to the developer and ask them for a fix.
Pet Projects
For those that like leading, but won't be happy with out a peice of the technical fun, get yourself a pet project. A pet project is a peice of work thatL
- Is meaningful and interesting to you, but that might otherwise be done by an individual contributor. There's no management work here, and it satisifies that craving to stay hands on.
- Can be accomplished without harm to the project schedule, even in light of the management work that is also part of your job. It has to be the right size that you can get both done with no harm.
My general guidelines for this are:
- Don't leave a mess. If you can't do it completely, including the boring repetitive work that every other individual contributor would have to do - then you can't do it. Giving yourself special waivers on shirking the work you don't like sets a REALLY bad example.
- Don't hurt the schedule. If you find the schedule slipping because your work isn't getting done, fire yourself and give the work to a regular individual contributor.
- My general heuristic (if I'm really up to speed on the tech) is that I take something that is between medium and medium-low on the priority scale. I leave the glory to my best individual contributors and take something that is meaningul but low enough on the priority scale that I can see the schedule slip well before it becomes an issue.
Be true to yourself
Not everyone loves being a leader. It sounds like you've been very happy not being a leader - so you know at least one career path works for you. Give this opportunity a shot, but be true to yourself. If after 6 months of leading, you find that the only true joy at work comes from having that time by yourself to do individual contributor work, and you know you're doing more than you really have time for because it gives you such joy - then have a frank discussion with your management.
You don't have to like it - management work and being a mentor and a senior individual contributor are very different.
Give it an honest shot, but in the end, a desperately unhappy manager is worse for a team than a new manager, or a manager with weaker technical skills but strong enough people skills.
