For a lot of developers the team leader position is a coveted one, it is as if when you become team leader the business is acknowledging you and your skills, but unfortunately for a lot of developers that reach this position it is not always what it seems.
From my experience the team leader role will usually fall into one of the 3 following categories:
- Team leader as Development manager
- “Normal” Team leader
- Team leader as technical lead/architect
Lets take a quick look at what each of the categories entails.
Types of team leader
Team Leader as Development Manager
This type of role is often sold as the next type, “Normal” Team Leader, but due to organisational pressures (expectations?) you will find no time available to do any coding, instead you will be pulled into endless meetings, have to deal with process, policy, HR, etc.
If you decide you want to take a more managerial career path this role will suit you down to the ground, with communication often being the main skill you will need as you will most likely be expected to act as translator to the business in relation to software development and how it benefits/impacts the business.
On the other hand for those developers that love to code this is the worst type of role they could end up in and will quickly destroy their morale and crush their soul.
“Normal” Team Leader
The “normal” team leader is where you are told that the role is 50-50 with half your time being spent doing managerial tasks and the other half coding.
This is often seen as a good compromise by developers as they go into the role expecting to be able to keep hands on coding but accepting the need to perform management related work as a necessary evil.
Frequently though this role turns out to be a little unbalanced in relation to the amount of “management” that is needed and it may become 70-30 or even 80-20 in relation to managerial work vs coding.
Team leader as technical lead/architect
The nirvana of developer jobs, all of the prestige, all the authority but no management related work.
This type of role with near 100% coding (not 100% as we all end up in meeting of one sort or another) is, in my experience, very rare.
A technical lead role is often an additional responsibility that is given to a senior developer in relation to a project, not a promotion with appropriate salary and benefits. An architect role usually needs the person to be spending a lot of their time talking to people either in a technical or business capacity which will reduce the amount of time they can code (but I firmly believe that architects should code with the team).
What’s my experience?
In my career I have experienced both the “Normal” team leader role and the Team leader as Development manager and it was my experience with the latter role that prompted me to take a step back from the managerial career path. I found that to keep my enthusiasm and morale I had to do a lot more coding in my own time which was to me a clear indicator of what I actually enjoyed doing.
Do you recognise your role?
Have I captured your role in the 3 types above or do you have a completely different role? If you have a different type please leave a comment with the details.
So, what type of team leader are you?
I honestly do not believe there is a job that has 100% coding - as developers most our time us spent planning, collaborating, retrospecting etc. even when I was a full time developer I still only managed 70% dev time
ReplyDeleteI would say you need to be all of them; IMO a team leader is someone who figures out how to make the team as efficient as possible.
ReplyDeleteI would say you need to do all of them depending on the situation; I wrapped it up in a blog post a while ago here: http://www.corebvba.be/blog/post/Continuous-thinking-Essay-The-secret-sauce-of-great-leadership-IMO-B)-.aspx
Paul, as I said I think the 100% coding jobs are rare as hens's teeth.
ReplyDeleteHere's a question - even if the job was mainly coding would it be a team lead? Do you need that managerial aspect to a job to make it a team lead?
Tom,
ReplyDeleteI would question whether you should be a "development manager", surely that's the role of an actual person and should be seen as such rather than tacking it on.
Your blog post describes what I'd consider a good agile team leader and would fall under the "normal" type of team lead.
As always just my humble opinion
I agree with Paul's comments entirely, although I think your choice of methodology can affect the amount of time a developer spends doing other tasks. I would also add that anyone senior in the team will also carry other duties such as mentoring and code-reviewing, which I am unsure if you would class as 100% development.
ReplyDeleteI fulfil all three roles you outline above, this is only achievable through automating most of the requirements on me as a "Development Manager" alongside introduction of methodology/process to support a self-managing team. Tasks such as prioritisation, scheduling and forecasting have been handed back to where they belong - the business (only HR/recruitment stands out from this).
So out of my 100% time I achieve about 80% towards team/project leadership, architect, mentoring, and coding; of which I would say I achieve 50% coding. It's the Holy Grail of developer/manager, and confess sometimes have to fight to maintain it ;)
I personally think that if you are actually a team leader, then immersing yourself in the team's day to day responsibilities is actually going to hinder you.
ReplyDeleteIf you are the "tech lead / architect" and doing the coding and not the management (3rd on list), I don't particularly think you are a team lead at all - you are simply a team member that has a lot to offer to other team members in promoting best engineering, design and process practices.
The other 2 need to adopt the servant leader mentality, looking at lean management, saving teams from administrivia and thinking strategically about how to help the team improve their performance.
This "Agile Manager" role is still poorly defined, but this article: http://www.scrumalliance.org/articles/103-the-managers-role-in-agile is a good starting discussion point.
Personally I see the Agile Manager as another role which has been neglected and therefore poorly appreciated and championed. The role should work in symbiosis with the team members, PO and SM/coach
just my tuppence :)
Nathan,
ReplyDeleteI was not familiar with the term "development manager", but I looked up and it was indeed a better fit.
What strikes me the most is that all this lean management/agile/[add whatever new buzz fits here...] is actually an approach that some of my personal mentors have been using ever since they started doing business (not ICT-related, starting somewhere in the seventies):
1. You have an idea
2. Brainstorm/prototype/verify with prospects
3. Implement the absolute minimum
4. Sell it to your prospects
5. Measure and adjust accordingly
6. Go to step 2
Except for the fact that they did not publish a manifesto about it, I do not see a whole lot of difference with agile etc....
Tom what you are describing sounds like "lean startup". which isn't really analogous with agile rather its an addition to agile.
ReplyDeletePlenty of info about agile in other posts on the blog ;-)
Hehe, apparently my interpretation of agile does not match the general public's... Fair enough ;)
ReplyDelete