The Elastic Leadership Book



        RSS Feed

Latest Entries

First time here?


The first five Whys

You might also like to:

1) Why create this blog in the first place?

Because I wanted new team leads and want-to-be team leads (as well as existing want-to-learn team leads) to have a good blog to go to and find out some great techniques for managing and driving software people.

2) Why?

Because 99% of team leads I’ve seen in the wild seem to have no idea what it is that drives people, or how to drive the things that they believe in inside the company.

3) Why?

Because lots of people seem to give no importance to the human-to-human techniques it takes to lead a great team, not just technical practices.

4) Why?

Because no one has ever put a great deal of emphasis on this in the software industry. What they did do is put emphasis on the technical emphasis of software leadership.

5) Why?

Because software is a pretty new profession, and we are all learning as we go. We tried to learn from other industries and only in the past few years are the successful practices from manufacturing and production starting to cross over into the software business. And those practices (the successful ones, at least) give high value to coaching and driving people, as opposed to “resources”.

What to do now:


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.

Page 1 ... 29 30 31 32 33