Overhaul 19a: Carrier Team One Reflections
Introduction
Some things about ship overhaul are given: staffs will try to operate the ship as much as possible before overhaul-often seeking to delay it without consequences*, sailors will complain about shipyard conditions (especially parking), there will be rework, ship senior leaders will fret about doing things “on the backs of the sailors” and —most importantly—everyone will still hate being in the shipyard (mostly).
*There are always consequences and they are never good.
This post kicks off a series of reflections about Carrier Team One (CT1). It’s not a historical chronicle*—those are boring and misleading (see below). It’s a personal perspective on what made CT1 special (and effective) in its early years. I make no claims about how CT1 functions today. I’m also realistic: nobody’s been waiting on the edge of their seat for my opinion.
*If you’re actually looking for CT1’s origin story, try Blanton’s 2008 article (accurate, but boring just like most professional journal articles) or the logistics award submission I wrote before it was cool—available upon request.
*Blanton, G.B. (2008). Carrier team one: Making decisions “mindful that a carrier must last 50 years”. Naval Engineers Journal, 120(2), 61-67. https://doi.org/10.1111/j.1559-3584.2008.00124.x.
Important safety tip (like not crossing the streams): both sources, like most histories, suffer from the same flaw—retrospection. They make it all sound cleaner than it was. The early days weren’t full of insight and clarity—they were full of uncertainty, awkward trial-and-error, and more questions than answers. The only thing that was consistent before 1997: carrier overhauls were bad.
The professional challenge isn’t pulling off one successful overhaul—it’s doing it again. And again. And … (you get the idea). Consistent good performance, especially in something as complex as carrier overhaul or a posse, doesn’t happen by accident. It takes a system. A good one (bad systems are easy to design). The best systems make doing the right thing the default rather than an heroic exception or demonic exorcism (one of the few things scarier than ship overhaul). Come to think of it, sprinkling holy water before an overhaul isn’t an altogether bad idea.
This series aims to reflect on how CT1 changed the game in carrier maintenance by turning systemic dysfunction into collaborative reform—one dumb thing at a time.
Some Causes of Bad Overhaul Performance
To set the stage for my reflections on CT1 and systemic overhaul improvement, I offer this biased opinion: episodic bad overhaul outcomes can result from many factors, but consistently bad outcomes take leadership. Usually, it comes from leaders and their organizations doing dumb things (often because “the Admiral said so”). My top ten list of dumb things that leaders need to stop doing to improve ship overhauls:
1) stop underfunding maintenance (maintenance doesn’t vanish because you don’t like what it costs),
2) stop trying to take “unnecessary” work out of Class Maintenance Plans (unless you have data justifying it),
3) stop ignoring the negative consequences of optimizing just one part of a process; end-to-end performance is what matters (this was W. Edward Deming’s insight in the 1940’s),
4) stop failing to plan for maintenance that lifecycle DATA show MUST be done (e.g., tank inspections, structural repairs, and preservation),
5) stop listening to anything a program office says about maintenance for a new class of ships (they don’t lie as in “I know what I am saying isn’t true,” but their predictions are like religious cults predicting the return of Jesus on a specific date: their story changes when the prediction fails to come true),
6) stop dictating anything about overhaul to SYs,
7) stop ignoring recommendations of the maintenance planning activity or SY (they have DATA),
8) stop expecting a ship’s crew to understand the ship’s material condition well-enough for overhaul planning (they have other priorities),
9) stop letting ship CO’s decide how they will comply with Navy instructions in SYs (complicating things because of poor crew performance only delays the shipyard further),
10) stop doing things merely because of a rule, policy, instruction, or anything that isn’t a law.
It didn’t take me long to write that list. Many of the items are specifically called out in GAO reports. Despite the dumb things leaders and their organizations do, all is not lost. It is possible to stop doing dumb things once you know what they are.
One way to learn about dumb practices is to talk to the people impacted by them. That was done with aircraft carrier maintenance in 1997, which will be the focus of this post and a few to follow. A second way to stop dumb things is to get really disciplined about performance. When you don’t have many degrees of freedom (i.e., lots of path dependence in tightly coupled systems), you reduce dumbness through a focus on compliance to a performance standard. That was done with the SSN 688-class Baseline Project Management Plan (something for later posts).
The Setup
Histories of CT1 often start with, “the carrier maintenance community convened a shipyard overhaul performance summit in February 1997.” Everything in this sentence is false except “in February 1997.” First, in 1997, there was no carrier maintenance community. The sense that one is part of or lives in a community is inside their head. It only shows up as something you can observe when they talk and act
Before 1997, there were many organizations involved in carrier maintenance, but they didn’t talk and act like they were part of a community. That awareness was an outcome of years of work by many people participating in CT1. Eventually they came to think of themselves as a community, however.
The second falsity is that the meeting wasn’t called a “summit.” If you call something a summit, Admirals show up. Summits also scare shipyard (SY) people because their experience is they become punching bags at any meeting attended by lots of Admirals. Senior leaders don’t know anything about maintenance, but excel at blaming shipyard personnel for the dumb practices they oversee (see list above). No wonder SY personnel are hard to find at summits. They usually stand at the back of the room near the exits.
Senior leaders know (actually, their staffs convince them) they have to attend summits or risk getting blamed. SY personnel attend summits expecting to get blamed. The event in February 1997 was called a “lessons learned” meeting. That kept the Admirals away and was less scary for some of the SY personnel (except for department heads as you’ll see in the next post).
Senior leaders from organizations outside the SYs did attend the meeting, but they weren’t Admirals. These civilians came at the request of meeting organizers. The organizers of the first CT1 meeting (more in the next post) suspected these organizational leaders could be motivated to stop doing dumb things once they knew where to start. I know the meeting organizers thought this because they later became my mentors and told me.
Conclusion-I’m just getting warmed up
Improving warship overhaul isn’t as simple as documenting problems (no offense, GAO)—or as grand as a mythical quest. It’s hard. It’s possible. CT1 improved carrier maintenance and proved it.
Real progress is possible—painful, slow, but possible. The early CT1 meetings weren’t summits. Like ship maintenance, they weren’t glamorous. But they were honest (_after_ senior leaders stopped the guillotine treatment). They kicked off one of the most successful periods of carrier maintenance reform in decades.
What made Carrier Team One different was its decision to focus not just on what happened inside the shipyard, but what happened between organizations—especially the ones that usually blamed each other. Past practice: yelling. New approach: processing mapping.
In the next post, I will provide my perspective on the ways the first meeting was remarkable.
Spoiler alert: The biggest breakthroughs in carrier maintenance didn’t come from new tools or radical ideas (okay, process mapping was pretty wild). They came from identifying the dumb things we were doing—and stopping them. People like to call that “harvesting low-hanging fruit.” I call it finally realizing we’d been standing in an orchard the whole time—just too busy tripping over our own rakes to notice. Maybe the lights were off and we didn’t realize it.
