RSS Feed

Latest Entries

Saturday
Sep052009

Step #1 – Claim Your Territory, Own your team

Many dev leads don’t seem to easily see that their territory is constantly compromised by people from the outside.

Compromising territory can be in many simple forms, but they all hurt the leadership and ownership aspect you have as a lead. as yourself these questions:

  • Do you get to choose the way you implement the features requested by customers, or do you get told how to implement them?

Internal team implementation decisions that weren’t specifically asked by a customer or have nothing to do with a feature’s integration with other technologies usually should stay fully internal to the dev team. Things like what technology or language to use, what type of database to use and others are things the dev team needs to figure out for themselves.

It’s up to you to go up to whoever is doing this and say “The way we implement features is not your problem. Just tell us what you need, don’t tell us how to build it”.

A good technique to see why this is happening is to ask yourself and whoever is telling you this, why they feel compelled to tell you how to do your job. you’ll find that most times there is a deeper issue underneath that needs to be solved.

this is where the five whys technique helps a lot.

  • Do people feel the need to come by and tell specific team members what to do instead of going through you?

You should be the only entry point to your team. Your team depends on you to make sure they get as least distractions as possible from the outside.

Go up to whoever keeps asking them things find a way to make sure you are the one asking people to do things, and not anyone else. In fact, if you are using some sort of a kanban system, such a thing will not even be necessary.

 

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.

« The first five Whys | Main

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (4)

Hi,

congrat on the new blog. I think it will be very interesting.
I would say however that what you describe here is not the job of the team leader.

You as a team leader do not "own the teritorry" and defenitely not the team. ( ithink there are laws against that)
It's the job of the team to define its bounderies its the job of the team to resist outside interefernce.
You as the team leader is just the tool for achieving this.

September 6, 2009 | Unregistered CommenterLior

Lior - all fine and dandy - but in most teams no one gets up and does this, so it's the team lead's responsibility to take the reigns and do this, as a preliminary step - so that things can start to go down the road you mention.

September 6, 2009 | Registered CommenterRoy Osherove

Roy - I would say in this case, that this is exactly your first responsibility as the lead. To teach the team how to do that.
Which starts by saying to the team, I expect YOU to do that. (of course in the meantime if its a big issue you should help)

I just really dont like the tilte of the post. "own the team" is such a bad term for me.

September 6, 2009 | Unregistered Commenterlior

Roy, congrats on your new blog!

I really hope it wasn't the shock of coaching me as team lead that drove you to take this sort of measure... And if so, I hope someone will learn from my mistakes.

September 7, 2009 | Unregistered CommenterDoron

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>