Michael Palmer's Command at Sea: Naval Command and Control since the Sixteenth Century didn't turn out to be the book I wanted it to be. But, Palmer highlights several themes in the history of naval command that turn out to be surprisingly relevant to today's mangers and leaders.
When I was a grad student in history, I used to find it annoying that book reviewers faulted an author for not writing the book they wanted to read. And yet, here I am doing the very same thing. But, as I'll explain, I think we can draw some interesting conclusions from the book.
I had hoped for a study of leadership at sea. Perhaps a discussion of the different methods captains have used to motivate and lead crews. Given the number of negative examples—mutinies and so forth—there would seem to be at least some material that could be brought to bear on this subject.
Instead, Palmer gives us a rather conventional history of naval command at sea from the seventeenth century to the present. He focuses on the great men and great battles. While he often describes battles in detail, the focus is on the macro level, and we rarely see the interpersonal details I had expected. Fortunately, there is a good deal of interest to be found in the big picture.
Palmer weaves two big themes throughout the book. The first is the tension between centralized and decentralized command and control. The second is the evolution of communications technology, and the effect on management.
The centralization/decentralization tension Palmer discusses is readily apparent in modern management. I think everyone has worked, at some point or another, for a micro-manager. Palmer describes many commanders who sought to tightly manage fleets, sometimes even from land (royalty seems to have been especially guilty of this desire, often to poor effect). But the centralized approach often didn't work well in the heat of battle (the "fog of war"). The chaos of the fight, combined with the limited commands that could be conveyed using flags, didn't make it easy to manage a fleet from a flagship.
Lord Nelson is the canonical example of the decentralizing commander. Knowing the chaos of battle, he didn't even presume to control his fleet once the fight started. Instead, he did his work prior to battle. Says Palmer:
Nelson met whenever possible with his captains so that all became acquainted with his "ideas and intentions." He believed the surest path to victory lay not through centralization, but through decentralization. He placed his trust, confidence, and faith in his subordinates. He chose to rely on the initiative of men who had, he hoped, absorbed from him an overall philosophy of battle. In a letter to Lord Howe after the victory at the Nile, he borrowed a phase from Shakespeare's Henry V to describe these men: "I had the happiness to command a Band of Brothers; therefore, night was to my advantage. Each knew his duty, and was sure each would feel for a French ship.
Nelson's ideas passed the ultimate test when he was shot and mortally wounded during battle, and yet the fleet carried on to victory.
Very few of us will need to go into battle, but this concept of decentralized management can apply to management today. From Nelson's experience, we can learn of a few requirements. First, this approach requires trust in subordinates. In the age of sail, commanders could—and were—executed for failure, so it was key to ensure that a leader had quality subordinates who can take initiative. And, if the subordinates aren't up to snuff, the leader needs to move them along.
The second key is "indoctrination." Don't let this word's negative connotation get in the way. The root here is "doctrine." In other words, the leader has a strategy, a doctrine, and spends time clearly explaining the strategy to the subordinates. Nelson didn't just dash off a letter to his captains and hope they picked up the lesson. He spent lots of time with his team, talking over his ideas and making sure all understood his strategies and intentions. Ironically, decentralizing requires spending centralized time together.
Palmer's second theme is the advance of communications technology. For centuries, commanders have used signal flags to pass messages from ship-to-ship. Over time, the complexity of these systems increased. Later, telegraph technology allowed shore-based commanders to manage far-flung operations without waiting months for ships to deliver written communications. Moving into the twentieth century, radio communications brought danger of detection along with the utility of wireless messaging. Today's navies have computers and satellites at their disposal.
At every step, the centralizers tried to use the advances in technology to increase central control. Of course, other technologies quickened the pace of battle, mitigating any advantage the new communication techniques might have brought. Palmer points out that one American World War II commander, Commodore Arleigh Burke, "hesitated for only ninety seconds and nearly lost his ship."
Modern managers have plenty of communications technologies (email, IM, phones, etc) that could increase centralization (micromanagement). But, the lesson presented by Palmer says that perhaps a more decentralized approach would better serve all involved.
Peter Van Dijck posted a chat transcript with some interesting ideas about the future of tags.
I'll preface my comments by saying that I really haven't been following the world of tags that closely. Sure, I've used tags, and even built a system that featured tags, but I haven't dived into the conversation about the future of tags. So, I guess everything I say here might well have been said before. Oh well.
Anyway, Peter and Emanuele talked about a couple of interesting concepts: facets, heirarchies, and tag UI.
The information manager in me *loves* the idea of combining facets with tags. Del.icio.us has an embryonic version of this with their "for:username" tag (letting you "send" a bookmark to someone else). You can see how it might be useful to tag something with "place:seattle" or "color:red" or "size:venti".
Hierarchies also make lots of sense. It would let people create tag taxonomies, rather than the flat universes that are created with most tag systems right now. Peter and Emanuele mention the hacks that people use on del.icio.us right now.
Then there is the UI problem: how do people enter these tags? What syntax is used? As the saying goes, "be liberal in what you accept..." In other words, you can easily come up with multiple ways to specify these relationships using plain text (we'll ignore any sort of GUI interface for now). Tag systems should accept and deal with multiple syntaxes:
place:seattle
place=seattle
United States > Washington > Seattle
United States/Washington/Seattle
place:United States > Washington > Seattle
and so on.
Anyway, fun stuff.
Kasper Andersen wrote in with some interesting ideas on the backup front:
Actually I use Subversion for backing up all files (both sourcecode and other files as well), using the Windows explorer extension allows easy manual adds/commits + browsing of your repository.
You can get subversion hosting plans in a wide range of prices. I run it off my own server (which again is backed up - using a real backup system to different datalocations) - therefor I have no recommendations on the "best value" shared host.
Kasper included some of the benefits of this approach:
- It's fast.
- The 3rd party client tools works really great, and outperform any backupclient tool in ease of use (for MS users it integrates into the winexplorer very nicely - and some equivalent tools for osx/linux are probably available).
- It works cross OS.
- It's easy to set up on the client.
- Besides "Just doing the backup", it's a great developer tool, which amongst many other features - integrates into my different IDE's (Visual studio/Eclipse).
- You are able to browse your files online.
- It offers logging and statistics (which are great if you sometimes mark a commit/backup as being special - commenting when backing up sometimes makes sense, other times - it does not).
- It is collaborative/team enabled, you are able to share working files this way without worrying that data might be overwritten, lost or outdated.
- It is open source - it's mature - a lot of people use it - which basically means, that the software itself will continue to evolve and improve AND that the ecosystem of 3rd party software is doing the same, most of which are free (as in free speech) - of course you should do some appropriate donations.
Sounds good. Of course, I should warn readers that one needs to have bit of a technical inclination to take this approach. I haven't looked, but it would be interesting to see if anyone has built any sort of automatic backup functionality into any of the Subversion client. If not, that sounds like a good project for someone out there in open source land.
John Battelle points to an important speach given by University of Michigan president Mary Sue Coleman on Google Print. The full text of the speech can be found in this PDF.
Michigan is one of the schools involved in the Google book digitization project. Coleman spoke to Association of American Publishers, an organization that is currently suing Google to stop the project.
The speech is worth reading if you're interested in the future of libraries, information dissemination, archives, copyright, or the internet.
I've written about backups a few times in the past, so my ears always perk up (no, not literally) when I hear about someone else's backup strategy. This someone was Tim Bray. Lots of good stuff here. He's using an external hard drive. The paranoid part of me says that you should keep an offsite copy. This is why I like the idea of backing up to a network server. Still...
I can't help but think that someone out there must have come up with a good way to do sane, reliable backups in a non-geeky way.