As a father of two daughters, I have had frequent opportunities to spend countless quiet hours straining mightily to open the @#$!@!% packages that encase various dolls and small plastic toys. I'd almost come to the conclusion that the Package Engineering profession is wholly populated with misanthropic sadists who are paid by the hour... and when I say hour I mean the amount of time it takes to open the packaging they design.
However, today's post is not a rant about bad design. Quite the opposite. I am writing to report some good news of great joy. After years of suffering through unending inconveniences and unnecessarily difficulties associated with removing Object A from Package B, I am happy to report the discovery of an example of packaging design so simple, so thoughtful and so right that I almost wept.
The picture below, taken as always by my my handy-dandy, oh-so-out-of-focus little camera phone, shows this magnificent piece of customer-loving art:
In case it's difficult to tell, let me explain. This is a photo of a car charger for a cell phone. It is still in the package... except for the part that isn't. On the right side of the picture, you can see that the business end of the charger is actually sticking out of the package. When it's on display, that particular bit is snapped into a snug little concavity... but this thoughtful design allows potential customers to tug the cord free and actually plug it into their phone to make sure it fits, before actually buying it, bringing it home and opening it!
On the side of the package you can see the obligatory list of all the phone models this charger supports. But if you have your phone with you in the store (and you probably do, right?) you don't have to actually look at the list. You can just plug it in. If it fits, you've found the right charger. Buy it! If not, then keep looking.
This is a great example of literally thinking outside the box. I'm sincerely impressed that someone was able to challenge the unstated assumption that a product has to be inside the package... and in doing so, made life much easier for the consumer.
Now if only they'd do the same thing for Barbie...
OK, I've been poking at the still-sidelined F-22 a bit lately. Let's step back a bit and look at some of the principles involved.
For starters, I very much believe in planning ahead. I think it's a good idea to start cooking dinner before you get hungry. It's a good idea to save up some money before your car breaks down. And yes, we need to build weapon systems before the conflict arises. As my SOCOM friends often point out, "Competent Special Operations Forces cannot be created after emergencies occur."
I also believe the future is going to be surprising. We don't know what demands will arise, what seemingly eternal threats will go away and what new ones will emerge. We can't anticipate Black Swans. The only thing we can do is maximize our flexibility and our ability to respond to the unexpected. Read Taleb's book for more on that.
I'm also quite convinced we cannot build an effective fighter jet in 20 years, but we can do it in 3-5 years (the same holds true for all sorts of other technology genres). If we spend 20 years building something, we're going to end up with something that's technologically obsolete, operationally irrelevant or both. The basic principle here is it's important to minimize the time between stating the need and addressing the need. Our 1980's era predictions about the 21st century didn't quite pan out. And our current predictions about what we'll need 10 years from now aren't going to be correct either. There are many reasons I don't think we'll have an air war with China... and one of the reasons is that people keep predicting it as a likely future.
I think we need to take a closer look at the stuff Chuck Spinney wrote, about how less expensive systems tend to outperform more expensive systems, and simpler systems tend to out perform complex systems. I believe thrift and speed are not merely fiscal or political values. They are desirable technical attributes for a system. You want to build a really fantastic capability? Do it quickly & inexpensively (and keep it simple). And please keep in mind that the cost, delay and complexity associated with systems like the Raptor are not inevitable. We could rapidly deliver inexpensive air superiority jets if we wanted to, but only if we try. Speed, thrift and simplicity were never objectives on the Raptor.
So let me be really clear: if we want to ensure air superiority (or any other technical advantage), spending billions and decades is the wrong way to go about it.
Finally, I believe our development efforts should be guided by a prioritized set of requirements (as our Agile development friends do). Deliver the most important capabilities first. Deal with less important capabilities later. So, for example, if you're in the middle of two or three wars where air superiority jets aren't relevant, maybe bump that particular capability to a lower position on the stack.
When it comes to the defense acquisition process, change seems to be the only constant. In fact, we change things often enough that it's pretty difficult to attribute any improved (or degraded) results to a particular change, because by the time the weapon system is delivered, the policies and procesess have changed a five or six times (or more). Hard to get any correlation going with that much flux.
Of course, if we'd just shorten program timelines we'd be able to finish projects before the process changed excessively and thus could measure the impact of our "improvements," but that's a topic for another day.
Here's the thing - all too often the changes are blatantly superficial and have virtually no impact on the actual management or engineering of weapon systems. It's bananas but it's the sort of behavior the system rewards. Anyway, that observation inspired this sketch, originally intended for the 13 Theta series for Defense AT&L magazine. I figured I'd post it here instead.
For those who aren't familiar with the structure of the defense acquisition process, it involves moving through a series of milestones. In 1996, we used Milestones O, I, II and III. In 2000 it changed to Milestones A, B and C. And now here's the gag:
What would I recommend doing instead? Focus on honing decision-making skills and using the FIST approach to rapidly deliver affordable systems.
In an earlier post, I mentioned a report that the F-22 Raptor might finally see some action over Libya, after watching Iraq and Afghanistan from the sidelines for five years. Alas, according to the Air Force Times, that seems to not be the case.
One might wonder why we wouldn't use "the most capable air superiority fighter" to accomplish a mission or two over Libya. Say, accompanying B-2's on their bombing runs... which is one of the things the F-22 is supposed to do, right?
Well, the article points to the fact that it can't communicate well with other aircraft as a big reason for not using it. Also, that it can't actually hit ground targets very well. So the Libyan Air Force's strategy of staying on the ground looks like a pretty effective counter-measure against the Raptor.
Other than its inability to communicate with the good guys or to make the bad guys go boom, it's a fine, fine aircraft. Technically, the only thing wrong with it is that it apparently doesn't support any of our actual mission needs.
Now, I'm not an operations guy. I'm not even an airplane guy. I really don't know much about what sort of capabilities this country requires when it comes to jet fighters. But I am an acquisitions guy and a techie. And I know the objective of acquisitions & system development is to deliver affordable systems that support mission needs. From where I sit, it seems like we've spent a whole lot of time & money developing a system that doesn't contribute to any of the various fights we're currently engaged in. Where I come from, that doesn't count as success.
Might the Raptor contribute to some future mission? Of course. And I can't say for sure that these hypothetical future scenarios aren't actually right around the corner. All I know is that given current operational and fiscal realities, the Raptor looks like a strange investment. I might even say an unfortunate investment. This isn't hindsight - I've been saying this sort of thing for a pretty long time now. Frankly, even if we start using it 10 years from now, I'm not sure that would quite make up for the long trail of non-contributions.
Is there a lesson to learn here? Maybe something about the wisdom of shortening our development timelines, using the budget to constrain the design and focusing our requirements on a prioritized set of real-world needs. The opposite of the FIST approach - spending decades and billions to develop a multi-role system that doesn't support any of the three major operations we're currently performing - leads to situations like the Raptor.
Someone once told me that the FIST approach would never have produced a weapon system like the F-22. My answer to that: precisely!
I keep coming back to my post titled The Effectiveness Of Signs. It's one of my favorite posts on this blog. I like the way it blends design principles with an important aspect of leadership - namely, doing stuff.
Now, the topic of Leadership-with-a-capital-L generally turns me off (I blame John Maxwell's horrible books for that - and no I'm not linking to them). But this blog is titled Rogue Project Leader, so I guess I'm not completely against the topic.
Anyway, several years ago I sat in the office of a very high ranking person. In the course of our conversation, he expressed his frustration over his inability to get the people who ostensibly worked for him to do what he asked them to do. I was part of a small bureaucratic spetsnaz team that he had put together for the purpose of undermining the Defenders Of The Status Quo who were ignoring his direction. That conversation, and his frustration, have haunted the back of my mind ever since.
Now, with the perspective of some years, I wonder if maybe he was a bit like the sign maker in my earlier post. His sign was clear and unambiguous... but still the trashcan was not where it was "supposed to be." It's not a perfect analogy - I'm not saying he posted his sign behind the door or was asking anyone to put the trashcan in an inconvenient place. But clearly there were divergent priorities and interests. And just like with the trashcan story, the power lay in the person who actually moved the can.
The Raptor was declared operational in Dec 2005, but so far it hasn't flown any combat missions. There's talk now about possibly using it to take down radar sites in Libya... that is, if there are any radar sites left after the US Navy's bombardment with their Tomahawk missiles. Also, the French, British and Canadian Air Forces already have fighters in the air over Libya, so if the Raptor is going to see any action it's going to have to move quickly.
One might wonder whether the F-22 is really the best platform for doing this kind of work, or if perhaps Tomahawks and Rafales are sufficient.
On a completely unrelated note, check out Krog's New Weapon, a sci-fi story I published in Defense AT&L magazine in March, 2008. Why? Oh, no reason...
There's no excuse for why it took so long to do this, but I finally made a FIST page on Facebook. It's called the FIST Acquisition Network (FAN), because Dan's Acquisition Network (DAN) was just too self-referential. Stop on by and click the Like button to clip in.
My plan is to use the FAN page to announce upcoming events and provide links to new articles & blog posts - stuff like that. But it's also a place for people to ask questions, meet other people who are trying to do this FIST thing.
Just a quick shout out to all the new friends I met at the DIA Acquisition conference in Miami this week (and to the old friends too, of course). It's encouraging that so many of you said the FIST concept resonates with you and what you're trying to do. I hope you came away with some new ideas you can use.
Watching recent events in the Middle East got me thinking about, what else, project leadership.
Specifically, the revolution in Egypt reminded me of one of the most important aspects of just about any kind of leadership, project or otherwise: planning for your eventual absence.
People like Castro, Mubarak, Gaddafi and Steve Jobs drive me nuts. Why? Not just because they won't go away, but because they have no succession plan. That's fine if you're immortal, but even Castro will kick the bucket some day (seriously, how is that guy still around? He's going to out live me at this rate.). And please, a half-hearted hand-off to your brother Raul doesn't really qualify as a plan.
Yes, I know it's difficult to find a replacement. Good help is hard to find, blah blah blah. If you've been leading a place for 30 or 40 years, it's hard to imagine anyone else can take your place. Nobody else knows as much as you do. Nobody else is as well informed as you are. Nobody else is as connected. But here's the thing - at some point, you won't be around. Also, the world won't end when that happens.
This isn't just an issue for dictators. It happens in organizations as well. I've come across more than one senior authority figure who regularly make it clear they zero plans to ever leave... and thus they don't taken any steps to groom a successor. That's irresponsible. It's bad leadership. Also, it's lazy.
As a leader, the best legacy you can leave is a good hand-off to the next guy. If you really want to keep doing the same thing until you drop dead, that's fine... just don't take one of those top-of-the-pyramid jobs, where large numbers of people will be negatively affected by the chaotic impact of your sudden departure.
Sure, it's easy for me to say all this stuff. I never stay in one place for more than a year or two. One of the first things I do when I come into a new job is start thinking about how I'll hand it to my successor. Not because I'm itching to move on, but because I don't want to leave a mess behind... 'cause unlike some people, I know I won't be here forever.
I had a great time at Coast Guard HQ today, talking about FIST with a very cool group of America's Maritime Guardians. I wanted to say a public thanks for the warm welcome and the engaging questions... I hope they enjoyed our time together as much as I did. And a special thanks to those who were able to stick around for lunch afterwards. I look forward to continuing the conversation and hope you'll all keep in touch!
I also wanted to mention I recently updated the FIST Handbook. for those who haven't seen it previously, I should explain that in keeping with my preference for simplicity, the handbook is just a Google Document with a bunch of links for further reading. The big update is this: it now it also has links to some of the tools I talk about (extreme programming, SEI's Acquistion Archetypes report, etc). Whee!
Let me start by stating the obvious: the default status of a door is "Usable."
I mention that because in my experience, there's no need to put up a sign saying "This Door Works" on every door that works. People just assume if the door is there, it can be opened. It's a reasonable assumption.
On the other hand, doors you can't use generally merit an explanatory sign to warn would-be openers that such behavior is not allowed. These signs generally say "Door Blocked" or "Use Other Door" or some such thing. With me so far?
And continuing the theme of "let me state the obvious," a red sign with white lettering generally means one thing: DANGER! Yes, they can also mean STOP or DO NOT ENTER, but these three concepts are related, are they not? They're all variations on the theme of "do not proceed." You hardly ever come across a red sign with white letters that says FREE KITTIES, and if you do, don't take one 'cause they're probably demon kitties.
Given these facts, can someone please explain the sign below? It's posted on the door that leads out of my office area.
Tell me you didn't have to read it twice, just to be sure you read it right. And no, this is not an emergency exit. It's the door I go through several times a day.
Now, I get that as a military organization we use words like Egress. Fine. I won't quibble over word choice, even though it's a stupid word (ok, I'll quibble a little bit). My objection is that this sign is on the door I'm supposed to use. It gets better. The twin door right next to it, the one that's locked in place and cannot be opened... is unmarked.
Let me just say Aw, come on! Seriously? Who does that? Jeez!
Alright, it's not a huge deal, but it does cause some unnecessary confusion. For example, we recently had a visitor to the office. He'd never been here before. When our meeting ended we all walked towards the exit. We were talking. He was distracted. He didn't read the sign, but simply did the logical thing - steered away from the RED DANGER sign he saw out of the corner of his eye and instead slammed into the unmarked, unopenable door. He didn't read the sign because a) he was in a conversation and b) he didn't think he'd have to read it, 'cause it's a RED DANGER sign. Like I said, demon kitties.
The point, of course, is that standards matter. They are powerful shortcuts to communication and when used well, they allow a person in a conversation to catch a warning and steer away from the locked door. Yes, inverting their meaning can be a useful exercise in creativity. It can make some thought-provoking art or deeply funny pranks. But sometimes the right answer is to let a door be a door, and put the red sign on the door that doesn't open.
I've often said that any program with the word "Future" in its name is doomed from the start, because if you're building a system for the Future, well, you'll never deliver it because the future never comes. We all live in the present. Two infamous examples are the Future Combat System and the Future Imagery Architecture (both were cancelled).
Seriously, what was the plan for those two once they were fielded? Were we going to change the name to the Present Combat System? Or how about Today's Imagery Architecture? Lame.
The thing is, these names reveal something about their purpose and design values. Calling something the Future X means we think it's going to be cool (eventually) as we fly around in our silver jumpsuits and jetpacks. It's also an explicit acknowledgement that the thing isn't relevant to today's activities. To borrow the old cliche, it's the system of the future... and it always will be.
But it occurred to me that in the FCS case, maybe the word Future wasn't the only problem. Maybe the word System was inappropriate as well.
See, FCS wasn't really building a system. It was a collection of largely immature technologies that were not ready for prime time. The FCS program was trying to bring these technologies together before they were actually usable, integrating things that had no business being integrated. The phrase "it's not soup yet" comes to mind. That's not how you build a system. That's building new technologies, which is a whole other ball of wax.
Just something to keep in mind on your projects. If you're building a fieldable system, it should consist of mature, proven technologies. If you're still messing around in the lab with breadboards, call it what ever you want, but don't call it a system.
In a land of reptiles and mammals, a bird is an odd duck.
That is, if the only two categories you have are reptiles and mammals, where do you put a bird? It's warm blooded, so it's clearly not a reptile. Therefore, it must be a mammal. But it lays eggs and has no hair, so it's not a mammal. Therefore it must be a reptile. If you find enough birds you'll eventually make a new category. If you only find one or two, you're just gonna have a problem.
And what about Australia? Is it a continent or an island? Um... both? Neither? If we had more land masses like Australia, we'd have a term to describe them. But it's the only one, so we're kinda stuck. This doesn't mean the concepts of continents and islands are useless... just that the boundaries between the categories aren't as firm as they might appear. Incidentally, by some definitions, Madagascar actually counts as a continent! And one could certainly make the case that Europe is really just a set of peninsulas sticking off the western edge of Asia rather than an independent continent.
This is a problem with almost any taxonomy. Sure, it's useful to group like objects together, but outliers require adjustments. When we encounter something that doesn't quite fit, we can make a new category (Bird!), change an old category's definition (continental status is now based on local belief), or just shrug.
The thing is, our categories affect our perception... and that's a big deal. For example, different cultures divide up the color spectrum differently, and thus they "see" colors that people in other cultures do not. The way we categorize things affects our perceptions, and the way we perceive things affects the way we make decisions. Different perceptions will lead to different behaviors which leads to different outcomes. That's some serious stuff. The point is, even when we're being logical, we may be heading in the wrong direction.
George Lakoff has a book titled Women, Fire and Dangerous Things that explores the impact of categories on the mind. The title comes from an term found in an aboriginal Australian language which refers to a category that includes "women, fire and dangerous things." Definitely worth a read if you want to explore this idea further.
The point of all this is simply to say that boundaries between categories are often not as solid as we'd like to think. Beware of excessively binary thinking - and don't be too surprised when you come across a duck-billed, egg-laying creature that is otherwise mammalian (man, those Aussies have a knack for messing with categories, don't they?).
Want to read more about the relationship between perception, mental models and decision making? Check out my article titled Metaphors Are Mindfunnels, from the Nov/Dec 08 issue of Defense AT&L magazine.
The traditional approach to system development is often described as the Waterfall Model, which is a series of sequential steps that makes sense at first glance. Unfortunately, it doesn't work in practice (let me say that again: as a general rule, it does NOT work).
In fact, the first documented description of the Waterfall is from a 1970 paper by Royce, in which he describes it as a failed, broken approach that people should not use. Naturally, it's been widely adopted. Despite frequently disastrous results, people still talk about it as if it was a best practice.
I put together this little sketch for the 13 Theta comic series but decided to post it here instead.
I'm a huge fan of Hugh MacLeod. His cartoons-on-the-back-of-business-cards are everything that art and comedy are supposed to be - compelling, insightful, entertaining and thought-provoking, all in a wee-little package. I signed up for his daily emails as soon as he started doing that. It's the only daily email signup I've ever not regretted (sorry Writer's Almanac).
Hugh's first book, Ignore Everybody, was brilliant. And even though I adore his work, I must admit I was a little skeptical about his second book, titled Evil Plans. I was a bit worried about how much of it would just be a rehash of the first book. That didn't stop me from pre-ordering it, of course. But as I did so, I braced myself for disappointment. It turns out I needn't have worried.
Evil Plans is even better than the Ignore Everybody. Wait, can I really say "better" when the two books are so different? For that matter, maybe "different" isn't the right word either - they're both full of his trademark cartoons and insights. You won't mistake this book for a book by anyone else in the world. So they're the same in that sense. But they're also, well, distinct from each other.
I hope you'll pick up a copy, then start making your own Evil Plan.