This post is a response to
Step #1 – Claim Your Territory, Own your team, one of the
first steps a developer needs to take when moving to a leadership role. In it Roy states
The key takeaway is that you must be in charge of the boundaries that your team operates within, or you quickly lose control of what is really going on, and find yourself mostly running around trying to see what people are actually doing instead of making sure that the right things get done.
I actually think the first step is to work with the people around you to define what the role you're taking on is. For instance, what does a team leader do? My current role is "Development Team Leader" and I have line management responsibilities for 8 people, most of whom are working on different projects, I help to allocate them to projects, as well as maintaining a technical overview over some of our more active and/or complex projects. Previous roles have been "Project Lead" or "Lead developer" which have had project responsibilities - i.e. day to day work allocation, active development responsibilities etc. These are 2 very different roles, with very different responsibilities, and "owning the team" means very different things.
In fact, the more I think about it, the less I like the idea of owning a team. The definition of
ownership in Wikipedia is
the state or fact of exclusive rights and control over property
I can't, and don't want to, claim that over a group of individuals. I want to work with a team, lead a team, help a team - none of these sound as strong as "own a team" but they're all to me much more what leading is about - inspiring, being
democratic not
autocratic, helping team members to deliver on their promise, make the most of opportunities and above all else learn.
Anyway, back to what I'd do next. As a Project Lead I'd want to sit down with the Project Manager and/or project sponsor and understand what challenges they face at the moment with regards to the team (I bet they say communication). I'd try and agree a set of responsibilities with them so that I knew what I was being measured against, what my role was, what they expect of me, what I expect of them and what areas we're going to need to work together on. Without this clarification there will be areas that aren't covered at all, and areas that we step on each other's toes about. Then we need to communicate the boundaries between myself and the PM/Sponsor to the team as a whole, so they know who to turn to with certain items - who do they tell about external issues (i.e. waiting for something from client?), who do they notify of delays, who do they see to get holiday signed off?, who do they tell about sickness or other absences? Additionally, if I planned to act as a gatekeeper so that everything comes through me, I'd inform everyone of this, both within and outside of the team. I'd make sure I also had someone to delegate this gatekeeper role to in my absence (does the PM/sponsor take this role on, or another member of the team? If another member of the team, then who?).
As a Line Manager, I'd want to sit down with the previous line manager for the team and get their feedback on the individuals, I'd want to get hold of their appraisal comments, CV and other material that helps me get a background. In fact, this is what I did 18 months ago when I took on my current role. I asked a lot of questions both of the previous line manager, but also of the team member, all to try and get an idea of who they are and what they currently do, have done in the past, and want to do in the future.
In both cases, I would also start by getting to know the team. So, I'd have a 1 to 1 chat with each of them over a coffee or beer, whichever suits the culture better. Find out what drives them, what they're interested in, what they think has been going well and not so well recently. Even if I was currently a developer on the project and was being promoted internally, I think these are all worthwhile. It's all about starting the conversation, being open to ideas, being ready to listen and act on what you're told. Just because you've got this new role, it doesn't mean that suddenly, overnight, you've gained the answer to every question - in fact you've probably gained a whole new lot of questions to work out - it just means that you've got some new responsibilities and somebody thinks you're capable of working with others to deliver on them.