Book Cover

In week 14 of our re-read of L. David Marquet’s Turn the Ship Around!  we begin Part IV of Turn The Ship Around and tackle chapter 21. The first three parts of the book bring the story to the beginning of deployment of the Santa Fe, Part iV picks up from there.

Part I – Starting Over – This section profile why Marquet is frustrated with leader-follower model of leadership.

Part II – Control – This section profiles the change and command and begins to layout Marquet’s vision of a leader – leader model of leadership. This section delivers mechanisms for control in a leader – leader model.

Part III – Competence – This section builds on the story of how the Santa Fe prepares for deployment and Marquet lays out mechanisms for building technical competence, the second leg of his leader-leader model.

Part IV – Clarity – This section completes the leader – leader model, focusing on the third leg of the leader – leader model, clarity.

Clarity means that people at all levels of the organization understand the nuances of what the organization is about. I have recently changed job and have gone through a few weeks of difficult product training. At first, I bridled at not diving into the day-to-day activities of my coaching. Re-reading this section is a reminder that developing an understanding of the organization’s values by translating them into behaviors and product will pay huge dividends in the long run by pushing decision making down the chain of command.

Chapter 21: Under Way for Deployment (more…)

Book Cover

This week we tackle chapter 20 of L. David Marquet’s Turn the Ship Around! (have you bought your copy?). Chapter 20 completes part 3 which has focused on competence and the run-up to the deployment of the Santa Fe. The title of this chapter is Final Preparations.  We have six or seven weeks left  – Steven Adams is pushing for re-reading Release It, the other option is The Checklist Manifesto.  Both are great . . . thoughts? (more…)

Book Cover

In week nine of the re-read of L. David Marquet’s Turn the Ship Around! we continue to sail through the heart of Marquet’s leadership model.  This week the two chapters are Up Scope! and Who’s Responsible? (more…)

Book Cover

In week seven of the re-read of L. David Marquet’s Turn the Ship Around! we begin Part 2 of the book and tackle chapters 8 and 9, titled Change, In a Word and Welcome Aboard Sante Fe. (more…)

 

Audio Version:  SPaMCAST 203

David Marquet’s book, Turn The Ship Around, is about leadership.  In a recent interview, David spoke passionately to me about how he discovered the power of creating a culture of leadership at every level.  As I reflected on the message of giving control, rather than taking control, I find that the bottom line is that empowerment can release the passion and intellect of our organizations.  In order for an organization to embrace empowerment, the leadership needs to believe that their people inherently want to perform well and that the employees want to improve.

In an interview I did with Pawel Brodzinski, software project manager, blogger, coach and speaker, we discussed the negative impact on improvement and growth when organizations embrace the myth of 100% utilization.  The myth of 100% utilization and leader – follower models make the assumption that telling someone what to do is more effective than letting them think for themselves.  Effective process improvement and change requires a belief in people and their motives. Unfortunately this is not always the case.

Once upon a time someone rubbed two sticks together to create fire for the first time.  While I wasn’t there, I am sure the person that performed this strange, new process was exposed to significant derision from those around him at least until the process delivered value.  In many organizations today, stepping out-of-line is met with disparagement and pressure to comply with the standard process or a set of forms to apply for a variance. If you need proof, just look around most IT organizations; we have all sorts of mechanisms to ensure compliance.  In many cases the pressure to comply to a standard process is justified.  For example, we have laws to ensure standard accounting principles are followed and rules that make sure pilots are not doing tequila shooters in the cockpit.  The rationale for strict compliance, in the examples of accounting rules or pilots, is to insure against the risk of tremendous loss.  However in most cases the need for absolute adherence to the published process makes less sense.

Techniques, methods and frameworks were not passed down on tablets from on high and are therefore open to discussion.  All software methods and techniques were born when someone having a new idea and tried it out (I have written in the past about experimentation and inertia; therefore, I will won’t belabor those points).

Bureaucracies are honed by the past and are focused on delivering products and services as effectively as possible. But at the same time, the compliance bias of a bureaucracy often leads to a resistance to change.  Honing practices based on the past is big business.  Six sigma, lean six sigma and assorted engineering process groups tend to have a data-driven bias towards slow actions.  I am torn between the need to have common practices and the need to experiment. Therefore, the right answer is to have a common framework that allows experimentation and change (Kaizen).   A requirement for strict compliance or permission-based exceptions doesn’t leave enough flexibility for experimentation when the need or opportunity arises.

The principles espoused in the agile manifesto, the leader – leader model documented by David Marquet and by Pawel Brodzinski’s discussion of the Myth of 100% Utilization all express the need for empowerment.  Terms like empowerment and self-managed are merely hollow words if a team must get permission to tweak how they work.  Being empowered or self-managed also doesn’t absolve a team from the consequences of their behavior.  I recently had a scrum master tell me that a team decided that iteration planning wasn’t necessary, so they just didn’t do it.  I am not a fan of knowingly doing something wrong and then asking forgiveness. There is the difference between taking control of how work is done and acting randomly or in an ad-hoc manner.

Rote adherence to software development processes misses the point; thinking is required.  Developing, enhancing and maintaining software is a complex and dynamic business, one where no framework can anticipate how all work needs to be done.  Compliance is required where law or risk dictates, but that only covers a subset of projects.  Frameworks can be used to provide structured guidance, but even the best frameworks need to be challenged and honed through experimentation.  What is the worst that can happen if you tweak how a retrospective is done or occasionally discuss risks during a standup?    Without trying out new ideas, without experimenting, you will never be more effective and never   know if your customers can be more satisfied.