The Elastic Leadership Book



        RSS Feed

Latest Entries

First time here?


Be a Book Reviewer for 'Notes to a Software Team Leader'

Want a free book? Willing to review it on Amazon when it is published? Willing to give me valuable feedback?

Fill out this form.


Audio: Preface–Notes to a Software Team Leader

Here is a little experiment. Below is the audio version of the Preface of my upcoming book “Notes to a Software Team Leader”.


I am thinking of turning this into a saleable audio book. How much should I charge for the entire book, with each chapter being an mp3 (book is about 110 pages)

and where should I sell it? (I do not live in the US, so cannot use Stripe)


Developing Critical Team Thinking

Borrowing a few terms from critical thinking, this is another map, or model, of how I feel I need to guide my teams. When do I feel like I have successful gotten my team where they could have been all along?

Here is a great quote from this PDF file on critical thinking:

From the cognitive scientist’s point of view, the mental activities that are typically called critical thinking are actually a subset of three types of thinking: reasoning, making judgments and decisions, and problem solving.

I say that critical thinking is a subset of these because we think in these ways all the time, but only sometimes in a critical way. Deciding to read this article, for example, is not critical thinking. But carefully weighing the evidence it presents in order to decide whether or not to believe what it says is.

Critical reasoning, decision making, and problem solving—which, for brevity’s sake, I will refer to as critical thinking—have three key features: effectiveness, novelty, and self-direction.

Critical thinking is effective in that it avoids common pitfalls, such as seeing only one side of an issue, discounting new evidence that disconfirms your ideas, reasoning from passion rather than logic, failing to support statements with evidence, and so on.

Critical thinking is novel in that you don’t simply remember a solution or a situation that is similar enough to guide you. For example, solving a complex but familiar physics problem by applying a multi-step algorithm isn’t critical thinking because you are really drawing on memory to solve the problem. But devising a new algorithm is critical thinking.

Critical thinking is self-directed in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took.


the last part hit home on many levels about what it means to coach someone to learn a new skill.:

Critical thinking is self-directed in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took.

Learning a new skill  means that they do not need you there to continue doing something. that you are no longer a bottleneck.

A self organized team is a self-directed team, as far as critical thinking is concerned. But we want our team to not only be self directed, but also effective, by avoiding common pitfalls as as discounting new ideas, seeing only one side of an issue, etc. Learning to be effective is to acquire a set of new skills, of each of these pitfalls, if they occur for members of the team.

A critical thinking team uses novel ideas, not always blindly applying templates to different problems, but always experimenting, and finding new, better ways, of doing new, or even the same things. there is always something new to be learned.

As I usually say, if everyone is too comfortable, you’re not learning anything. so something new has to jump into the equation in the form of a new experiment (‘what if we did no iterations for 3 months?’)


Elastic Leadership in Devops Survival Mode

This blog post from the devops guys, shows that the idea of “survival mode” or chaos can exist in many different places. and a command and control leadership can help buy valuable time that you can then use for learning. to quote :

Step 1. Kill the current fires, so sanity and actual thinking resume.

“When I took over the Operations of a high-volume UK website about 8 years ago I spend the first 3 weekend working fighting fires and troubleshooting Production issues.

My first action after that baptism of fire was to revoke access to production for all developers (over howls of protests). Availability and stability immediately went up. Deafening silence from Development – Invitations to beers from the Business owners.


Next step, get some friendly forces to help with the effort, if no one within has any idea what you are driving at:

Next step was to hire a build manager to take over the Build and Deployment automation, and a Release Manager to coordinate with the Business what was going into each release, when etc. End result – 99.98% availability, with more releases, being deployed within business hours without impacting the users, and a lower TCO. The Business was much happier, and so was the Development Manager, as he was losing far fewer developer-hours to fire-fighting Production issues, and hence the overall development velocity improved considerably. Win-Win.


Their view of survival mode Command and control:


Was that a DevOps anti-pattern? Did I create more silos? Probably… but in a fire-fight a battlefield commander doesn’t sit everyone down for a sharing circle on how they are going to address the mutual challenge of killing the other guy before he kills you. Sometimes a command & control model is the right one for the challenge you face (like getting some suppressing fire on the target while you radio in for some air support or artillery!).

The post goes on to talk about using the freed time for learning and getting better (in not so many words):

That said, once we had developed a measure of stability we did move partway to a more DevOps pattern – we had developers on-call 24×7 as 3rd line support, we virtualised our environment(s) and gave Developers more control over them, and we increased our use of automation.

Later on, the post mentions that organization influences (see ‘structural motivation - six forces) like different incentives, stopped the continuous learning from breaking up any new silos of knowledge.

overall, this is a very interesting read for me, as I can see many parallels in the ops word to the software world and the elastic leadership principles.


Feeling Stupid is Highly Recommended

So, to show you that the whole idea of taking risks and feeling stupid or frustrated is actually a good thing, because it's the only way to really learn a new skill, here are videos from my second day ever doing any kind of skiing. This is from a few hours ago:

this is from the first day


My muscles are still calling for help, but on the second day, things are much much better. I am happy I didn't give up trying, and I watched a lot of online videos on how to successfully get up after falling from skies. The first day was HELL. Second day - Not Hell, but a country side road with a view to hell very close by.

Page 1 ... 2 3 4 5 6 ... 32 Next 5 Entries »