developer or team lead : pure development role to team leadership role

Few months ago, my role was evolving in pure development.My day used to be pure coding.I had generally enjoying it. Since last few months my job responsibilities are changed from developer to team lead.Now, I still have a largely full plate of coding duties, but few others are added in my duties like I'm expected to mentor other developers,work on requirements, make design decisions for other developers, evaluate bug reports from users, assign them to developers,team communication etc.

I find that my day has become on interruption after another and the prolonged periods of sustained concentration needed to get any actual quality coding done are becoming rarer and rarer.

As an individually-contributing developer, my job was to turn my own time in to software that the business could sell for a profit.

As a team lead, my job is to see that the team effectively turns their time in to software that the business could sell for a profit.

Some things fundamentally change when your perspective changes like that. These things have become much more important:-

• Keeping other members of the team in a state that they can be productive
• Delegating tasks to the least loaded team member
• Strategically choosing which developer needs to learn which new skill to better load-balance the team, and investing some degree of my time in helping them learn that skill
• Effectively communicating requirements (somebody told "Think twice before you start programming or you will program twice before you start thinking")

Notice that "writing good code myself" is no longer on my list of top concerns. If the task of "develop this major new thing" falls on me, it's almost always for one of a few reasons:-

• The new thing is a framework item that will enable the rest of the team to be more productive (thus keeping them in a productive state)
• The thing I'm working on is super-critical for customer satisfaction (usually that means it has to be done quickly and with little risk of failure)
• The thing I'm working on has poorly-understood requirements, requiring someone with a high degree of domain knowledge to make quality requirement decisions while simultaneously doing development (one could argue that in this case, my inability to adequately form the requirements is the real shortcoming.)
• helping the team most efficiently and effectively turn collective time in to software that the business can sell for a profit.

However it's debatable but i believe it will works well and rocking. willing to know what others thinking ?

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

– Rich Cook