5 Whys is a blog about technical leadership in the software world.

The three stages of learning team leadership

or anything else, for that matter: Shu-Ha-Ri :

  • Practices
  • Principles
  • Values

*see related to this:

 

 

 

This blog is right now at the "Practices" stage: Lots of "Do this" and "Don't do that", with just a little "Principles" thrown into the mix.

The values? Those take time to develop. It's those "Values" that will make people write comments on these blog posts that don't agree with the post's sentiment, as they talk about a practice, instead of a value (when they coexist nicely).

For example, on my "Own your team and territory" post, i got quite a few comments that say "You must let the team learn how to do these things etc, which is more in terms of a "value" system.

But in the context of a "Learn initial practices" system, it does make sense, since that person has not yet masterd and feels comfortable with the accompanying princinples and values attached. when they will (and they will eventually) they can (and should!) start questioning their tactics - for at this point, in this context, those initial practices are the right thing:

= they are easy to follow

= they will bring some peace to the team and the lead so they can start focusing on more principles

= the values will have to be "earned" during time.

 

Test Driven Development is the same way:

 

  1. you start out with the 3 rules of TDD (practices - failing test, code to pass, refactor)
  2. you learn why they matter (the principles - test the test, think small, have partial work etc..)
  3. you learn the values of a SOLID designed system, and the ability to take and get quick feedback, and start aiming how and when you use TDD within those values.

 

Immediate and delayed satisfaction in software development

One-Liners a new team lead should and shouldn't read