Technical Competence

I recently read an excellent book by David Marquet entitled Turn The Ship Around. David is a former U.S. Navy nuclear submarine captain who was given command of a ship that was the worst-performing in the submarine fleet. He leveraged his experience as a junior officer in previous assignments to attempt to bring his sub up to the expected norms of the Navy.

While the story is based in a military setting, anyone in the agile community would recognize that David was a classic servant leader, delegating responsibility and decision-making to the people closest to where the decisions needed to be made. Indeed, I found out about David because he was the keynote speaker at the Gatineau-Ottawa Agile Tour 2013!

I highly recommend reading the book, because it's essentially a textbook about how to turn around the mindset and actions of a group of people. I found that there were very direct applications of his concepts to what we encounter in agile adoptions for organizations larger than a single team! I won't go into all the details with a comprehensive review of the book, but I would like to touch on one point that really struck a chord with me.

David wrote an entire section of the book on Competence. When he started pushing control and decision making to lower and lower levels of the crew, they started to encounter safety and operational issues. He realized that the mistake he had made was to assume that the people had the technical competence to make those decisions when in fact they didn't have it. He states,

Control without competence is chaos.

This wasn't a knock against the people or their training, because under traditional leadership models they had relied on the competence of their commander to know what decisions were appropriate. So, David sat down with his officers and chiefs (chief petty officers - the naval equivalent of sergeants), and they hashed out the values and principles for the ship. Core to those principles was constant, continuous learning. Not just learning, but learning by doing.

This had the effect of pushing the ability (competence) to make decisions further and further down the chain of command on the ship. In the space of a year, the submarine went from having the worst ratings in its squadron to the best, receiving awards for its performance.

Anyone who has been involved in a transition to a self-organized, self-managed model would recognize many of the actions David took. He speaks of replacing a leader-follower organization with one that's leader-leader. The notion of empowering people, and the resulting increase in engagement and motivation are quite familiar.

The one thing, though, that I believe that David saw that many involved in agile transitions don't is the effect of not having the technical competence to make decisions. For example, if developers have been empowered to go ahead and change workflows within a product, do those developers have the proper skills to understand the consequences of those changes? Even if those developers aren't touching external-facing functionality, do they have the knowledge and skill to understand how their changes will affect the overall architecture of the system? When business people are making decisions about features and schedules, do they really understand the capacity of the group or groups who will implement those features? Are they including them in the discussions? When operations people are making infrastructure changes, do they understand the ramifications on the business if there is an outage? Do people anywhere in the organization feel that they can question decisions by their leader without repercussions because they have enough knowledge to be able to understand the effects of the decision?

To truly be effective, people building systems need to ensure that constant learning is taking place and being shared in order to push the required knowledge and skills to as many people as possible so that they can make these decisions. This will create the kind of environment where people are motivated to do great work and feel they can experiment in order to try different approaches to technologies. This is the fertile soil from which innovation grows, but it can only work if everyone is constantly learning.

As a final note, it took David a full year for the submarine he commanded to transform. There were potholes along the way, and David mentions more than once that he questioned himself and the process and thought about simply reverting to the old way. He had his commander's support, and persevered. This isn't something that can happen overnight, and it does that time and patience.

In the end, though, the engagement and innovation creates a great environment in which the whole of the people will become greater than the sum of the parts.