Options for a lead programmer who prefers programming to leading? [closed]

Question

At the beginning of this year I was promoted to a lead developer role after our team's lead developer moved to a different department. I have about 5 years of job experience and due to availability and past performance I was management's primary choice for leading the project. I was a little apprehensive but decided it was a good opportunity for career advancement and experience, so I accepted.

But my conclusion so far is that I don't enjoy it nearly as much as my previous developer position. Though I have successfully led a team of 5 developers through several releases, I almost never touch any code. Instead I perform planning and design and team management, along with code reviews. The need to keep track of many more things, and have tasks planned so they can be assigned to the team, literally gives me headaches most every day. Even though I rarely work overtime, I feel burnt out most every day when I leave work, and don't think I have even enjoyed off-work time as much as a result.

So my question: how would you handle, or how have you handled, such a situation? For people in similar situations, did you find ways to better manage your team, tasks and time that made you enjoy the work? Or did you find a way to transition back into a more development-oriented position? I know that lead developer positions almost always pay a higher salary, but I can see myself getting to a point where I care less about money and promotions than I do about my enjoyment of my current job.

I have not discussed this with anyone in management as I thought I should try to adjust for at least a year.

Answer 1

The answer I'm providing here is my best guess at what could potentially work, but I haven't seen it work as I myself am trying to get out of similar situation where you are finding yourself. The whole thing is still a learning experience for me but I am seeing positive trend on my team.

In my company I've been promoted to a team lead (they call it "design lead") and because of shortage of people who know the product and have enough experience, I volunteered to lead 2 different teams. Few months ago "to help with the schedule", management doubled the size of these 2 teams.

Some thing I've been trying to do...

1. Make it clear to everyone (including management) that mine and everyone else's position is not a permanent assignment. Everyone is welcome to step up to the plate, take a broader view of the project and participate in architecture/design decisions. I will have the final say (for now) if there's a disagreement with no resolution, but so far that never happened.
2. Focus on helping other people develop and grow. I've had (almost philosophical) discussions with different developers at different times about coding and design and different approaches to doing things. Some of those discussions are related to actual work, other ones are pure thought exercises. I had a guy with over 20 years experience, go back to his bookshelf and pick up a C++ book because he was interested about some low-level stuff I did with template meta programming. These discussions are somewhat infectious and after you bring up these topics enough times, people start thinking about this stuff on their own.
3. Delegate as much as I can onto other people. Although I look over a lot of things, I do not participate in every single code review. Instead I do code reviews for our intermediate guys and I let those guys do code review for some of the greener people. I see code reviews as more of a knowledge transfer tool, rather than "let's make sure we read every line and find every possible bug".
4. Once the interfaces are defined and basic design is in place, I let even the newer guys have as much freedom as possible coding internals of classes. Yes, a lot of that code is far from perfect, but it gets tested and it works. If it crosses a certain subjective boundary in terms of "code smell" and they haven't refactored it, I would suggest that certain classes must be broken up or rearranged. It is painful sometimes, but when I check back few days later and get a response, "I hate to admit it, but this code looks so much better now", that actually gives me a warm, fuzzy feeling.
5. Challenge people. Instead of just assigning feature for them to add to the product, ask them to add those features, but do so without increasing the number of functions/data members in existing classes. If you have to put something new in, you have to take something existing out, and take the time to figure out what it is. Everyone knows about refactoring, but without extra force in the beginning, it seems that people need help making that jump to actually doing it. At a minimum, I make it a point to visit this point during just about every code review.
6. Everything is about BALANCE. You cannot be the only senior person on the team looking over everyone else. You cannot spend your entire week in meetings and doing reviews. You cannot expect that you will catch every mistake that your team makes. At the end of the day, you need to allocate the time for yourself to be the lead, but you also need to allocate time to be a developer. I'd go crazy if I couldn't code. Even with everything else, I still make sure I have time to write code and not just code but some really, really nifty stuff. I just got my hands on template meta programming books and started digging inside Boost. Guys who came up with that stuff have to be insane(in a good way). If your management starts bugging you about why not everything is being reviewed or why a noob is reviewing another noobs code, you just need to explain the whole balance thing and that the team simply doesn't have enough experienced people and at the end of the day "it is what it is". If your team has senior folks, then it's time to empower then and give them the freedom of doing their own designs/reviews/helping others and don't treat them as simply code generators. With empowerment comes freedom and people love freedom. If you have developers that don't care for freedom/empowerment, that's fine. Every team still needs pure coders, just make sure you strive for the balance.
7. Your time is valuable. So ask the team to e-mail you all non-time critical questions that they can wait on few hours before getting an answer. When the question is asked, the entire team should be copied on it. Eventually, when you have a break in your day, you can take a look at the issue and help the person, but many times, someone else may have already beaten you to the answer and you don't have to do anything. Obviously as the lead, I still make myself available and make that fact clear because I do believe that one of my objectives is to make sure no one on the team is getting stuck for a prolonged periods of time without making progress.
8. Make sure your team uses as many tools as possible to make communications more effective. For example we have a wiki site and any time the same issue crops up multiple times, I ask the last guy I helped to create a wiki page.

Answer 2

I have not discussed this with anyone in management

I think you know this would probably help. Communicating your discomfort with a position is not necessarily specifying anything concretely. It lets management know what cards they hold, and if it's good management, they will try and find a way to use your best potential. Don't settle for less.

Answer 3

When your project ends, look for a more programmer oriented postion in your company or outside of it.

Discuss with management that you would like less management and more technical "hands" on skills.

It sounds like your in a PM position versus a lead developer. I would consider a lead developer to be coding more.

Answer 4

Employers perspective:

If you enjoy the current job and have a good history there then I would want to keep you on and would find a place for you so I wouldn't worry to much about talking to them.

A great developer is a valuable thing, but you need to sell them that you are worth more doing coding and maybe design than you are the juggling act.

Give them a path to back you out by setting up a succession plan. Basically you find someone in the current team who is interested in doing the things that give you a headache, over the next 6-9 months you train them up, giving them your tasks one at a time.

Pick something easy first up, like weekly status updates:

• Sit them next to you when your doing a status update.
• Sit next to them as they do the next status update.
• Let them do it on their own and review it before it goes out for the final.

Then progressively give them the extra tasks until you have handed over the majoirty of your additional responsibilities.

The reason these less desirable jobs are paid more is because if they weren't no one would do them, not nessacrily because they require a higher level of skill ... supply and demand.

To keep you pay higher though ... If it were me I would want to hear that you are staying around, you will help out this person when required, will be a mentor to the newer guys, will be the designer/key brain/domain expert rather than project lead. Basically this is a valuable position, someone else can do the running around and juggling act (for more pay obviously).

I think if you were to present your employer with a 6-9 month plan which said

• Good explaination of why you think it is better all round that you go back to being focused on coding over the other responsibilites.
• Who to subsitiute in ... or do they have to find someone ... this will be a key decider I think.
• Rach month for 6 months what responsibilties you would hand over to the new person
• What responsiblites you would keep shouldered (like design, maybe sitting in on code reviews etc).
• An idea of the decrease in wages you would be willing to take (somewhere between original and now) though let them bring this up.

If you get that together as a plan for me, as an employer, I would be more than happy to work with you in making that happen.

Good luck.

Answer 5

2 questions that aren't obvious from your post:

• Are you in a firm that directly makes money from the software you write (like Google, Microsoft, or Fog Creek) or are you in a subsidiary function (like at a bank or a food company)?

• Is the CEO a technologist, or someone who rose up via business roles?

If you're a software firm with a technologist CEO, don't worry. The corporate leadership will know who the valuable developers are, and will do whatever it takes to keep them. If the execs are all folks who got their stripes "managing people" or "managing budgets", be concerned. Be doubly concerned if you're in an internal IT department. If this is the case, then you have to accept that a good work-life balance is the reward for staying a developer.

One last point - do what will make you happy. Everyone else's advice on career choices like this is about what would make them happy - and this is about you.

Answer 6

I've been in exactly your situation. the answer comes down to the relationship you have with your manager. In my case it was a very good one, so I took him aside one day and said that I was not enjoying the work, was feeling too stressed and wanted to move back to coding. He was much happier to hear that than to have me walk in and quit. So we worked out a plan for someone else to take over as Team Lead and me to go back to coding.