The Captain of The Ship
May 06, 2018
Spend time leading any kind of team of skilled workers and you’ll quickly find yourself in a position of significant and unintuitive anxiety.
It seems like everyone is better than you.
If it’s a good team that you’re privileged to be on, you’re probably right. No matter how good you are, everyone really is better than you. There’s a good reason for this. If you’re working together to accomplish a complex task, like building a piece of software, everyone on your team needs to go deep into some area of the task and understand it fully. Everyone except the leader; the leader’s job is to go broad and understand the scope of the entire task and make sure everything is going to work in sync.
That’s why this is so unintuitive too. We naturally visualize our organizational structures as a tree, and we think that the higher up that tree you are, the more expertise you have. But in a good organization, it’s the opposite. The subject matter experts are the leaf nodes. The difference when you go up the tree is how broad your perspective needs to be, and this is an entirely different skillset.
The captain of a ship is the best analogue. The engineer knows more about the engine and the navigator understands the details of the course and bearings of the ship. The pilot knows what to do with engine speed, rudder, or thrusters; in fact everyone on the bridge of a ship has a more detailed perspective on the workings of their expertise than the captain. Even the deckhands on deck will have more detail about the immediate surroundings of the ship.
The captain’s job is broader than all of these. He has to have some knowledge of all areas, not as deeply, and he must effectively use all of this knowledge across multiple domains and concerns to make concrete decisions about what is needed next. The ability to synthesize that much information together and to provide vision going forward, along with the respect and authority to ensure that the commands are carried out properly.. those are skills all their own.
I don’t think the software industry as a whole knows how to understand these skills, how to recognize them, or how to grow them. Instead we focus on tools like JIRA, or we try to outsmart ourselves with all sorts of process hacks. That’s what Scrum, Agile, standups, Kanban, Six Sigma, etc. etc. all are: process hacks.
But Agile only works if the leader makes it work. The process itself will circle out of control quickly. JIRA only works if it’s a tool in it’s proper place. Everyone has seen a team with a perfect JIRA board, great process, and zero
Agile doesn’t work without a captain that works.
In the modern world, no single person can build hardly anything on their own, and certainly not at scale. Go try to build a pencil yourself and see how you do. Now build 1,000 of them. Oddly enough, we tend to revel in the scarcity of “handmade” items because of this, but often the handmade thing is just a nostalgic vision from the past. As Jeremy Clarkson said in Top Gear, “handmade is just another way to say the doors will fall off.”
The leader embodies the breadth necessary to put all the pieces together. They represent not only the process, but also the shared vision of the end product, and the responsibilities, fears, and goals of everyone on the team. The leader doesn’t know everything, but they can help allow the shared vision to come into being. They enable.
A lot of people think this is raw intelligence. And certainly a level of intelligence is required. But the more important skills are less obvious: ruthlessness, patience, initiative, and precision. It would be great if we could figure out some sort of credential for this set of skills. What we have now fails completely. Green Belts, Scrum Masters, PMPs, whatever. They’re all worthless.
You learn to use these skills from others that demonstrate them. Navies around the world promote first mates, commanders or other lesser roles up to captain. Similarly, the commercial licensing process requires a year of service as chief mate which, in turn, requires a year of service as a second mate which, in turn, requires a year of service as a third mate.
It takes time and familiarity to build these skills with others, but in the software world, people often flip between jobs and companies frequently. Software companies often move too quickly to build these kind of skills over time in any kind of substantial way, which is probably why we default back down to training for specific processes like Scrum.
Joel wrote that Good Software Takes Ten Years. Chad Fowler points out that the word “legacy” in software is a bad thing, but it’s a good thing in virtually every other field. There’s a parallel here for software leadership. We don’t understand it enough and we don’t select for it well. All of us need to slow down.