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 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.