The Elastic Leadership Book



        RSS Feed

Latest Entries


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 #2 – Use a big visible board with post it notes | Main | Step #1 – Claim Your Territory, Own your team »

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    I created 5Whys because… well – here’s why . This blog will remain about TDD and other things, but 5Whys

Reader Comments (2)

I wouldn't say "no one has ever put a great deal of emphasis" on human-to-human techniques... Gerald Weinberg has written and workshopped on this area for decades.

September 14, 2009 | Unregistered CommenterKeith Ray

Agreed, that was bad word choice, but the point / message is fair enough. If "nobody" verbiage was changed "rarely" ("rarely do people put a great deal of emphasis") it'd be reasonable.

Congrats on the blog, I got sucked here from Twitter and agree with most points. Too often, a dev team lead is "the guy who knows more than you do and can do whatever he wants". A team lead should recognize that even though he reports to his boss, his job is to work for his subordinates. I wish people would recognize that.

September 17, 2009 | Unregistered CommenterJon Davis

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):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>