Gabe's Axiom

This is a reprint from my own blog, but I think it's applicable to the audience here.

I devised a new platitude that I’ve dubbed Gabe’s Axiom:

Engineers make stuff work. Designers make stuff useful.

I did so in response to my overall experience as an engineer to date. This thought coalesced recently while reading the book The Design of Everyday Things. Engineers love making and using gizmos and gadgetry and they love figuring out how to use a new widget. Therefore they find it frustrating when Joe user isn’t as passionate about learning all 15 ways to shut down a Windows based computer. I’ve often seen this frustration manifest as rebuke when a layman has trouble using equipment in the shared workspace (office copier, coffee pot). I’m guilty of it myself. I’d posit that a great many engineers don’t design with elegance or ease of use in mind. Making stuff work is their MO. However, the gizmos that are most useful are ones that are intuitive. It’s not the users fault if a gadgets operation isn’t readily apparent. True engineering involves synthesis and distillation with an eye toward elegance, not tech savvy alone. It’s the simplicity on the other side of complexity. It’s more challenging, but definitely more fun. After all, if it isn’t useful then what’s the point?

In Praise of the Polymath

Here at RPL, we're big fans of people who don't stick to their allocated lanes in life. We're in favor of having lots of crazy hobbies and wide-ranging interests. We think it's a good thing when people are not content to just be good at one thing, and instead branch out and make meaningful contributions in several areas.

Personally, I'm a fan of GK Chesterton. The guy wrote mysteries, histories, travel books, theology, fiction, essays - and had something intelligent to say on just about every topic you can imagine. I also really admire Will Smith, and the way he's done music, tv & movies - comedy & drama. Both guys went way outside the narrow bounds of specialization - and I think that's awesome.

And then there are those who go way beyond diverse writing or different forms of entertainment. Consider the beautiful and talented Hedy Lamarr, a film actress in the 30's and 40's (and beyond, actually), who also has a patent for spread-spectrum, frequency-hopping communication system (and it's quite a story how she came up with it, by the way).

And did you know that William Marston, the guy who came up with Wonder Woman, also invented the polygraph machine? How cool is that?

No doubt people asked Ms. Lamarr what business a movie actor has getting involved with communications technology for the Navy. No doubt people told Dr. Marston that serious scientists don't create comic books. And the world is richer for the fact that they did it anyway.

This is not about being a generalist or a specialist. It's about being a multi-specialist, doing a deep dive into several areas of activity.

How about you? Content to stay in your lane? Or ready to branch out...?

Writing Length

My buddy Rhet passed along this link to an article about the impact of the web on writing. And now I'm passing it along to you, my favorite readers.

Now, this isn't technically a project leadership issue, nor a military technology issue. But it is about several topics that are interesting & (I think) relevant to the wider discussion here on RPL.

The basic idea in the article is that the internet expanded the scope of possible manuscript lengths. No longer are writers limited to books or magazine articles. We can go longer or shorter, thanks to the magic of the series of tubes we call the internets.

It's just one of the many ways the internet is changing how we do business, how we communicate, and ultimately how we think. It affects what ideas we are able to share and discover. And THAT is the secret sauce of the whole thing.

Read the article. It's real good, I promise.

Twitter Is Mission Critical

Gabe & I collaborated with our AT&L editor Carol on a fun little article titled Twitter Is Mission Critical. It'll be in the Oct issue of Signal magazine, and you can read a short preview here. We'll let you know when the full version is up.

Process Application

Most of the process advocates I've met recently have come from background like manufacturing and logistics. That makes a lot of sense - these are well-bounded, repeatable, concretely-defined disciplines. The problem is when we try to cut and paste successful manufacturing or logistics approaches onto other areas, like research & development or program management.

R&D is typically - and appropriately - an unbounded, unique, loosely-defined activity. That doesn't mean there are zero processes involved... just that the most significant parts of R&D are beyond the realm of process.

So, when I say that I'm a critic of the process-centric approach, what I'm really objecting to is the misapplication and the overapplication of these approaches.

I also want to point out that I'm not a skeptic of the utility of process-centric approaches in R&D and program management. I'm emphatically a critic. The term skeptic sounds like a person is unsure whether a thing will work or not. Not me - I'm not agnostic about this stuff. I've done my research, taken the classes, got the t-shirt, and came to a conclusion. I'm well beyond skepticism.

Diversity

"If the only tool you have is a hammer, I don't want you to help fix my windshield."

Presentation Skills Are Critical

The ability to stand up in front of a group of people and communicate effectively is a critical professional skill for program managers and other project leaders. It's particularly necessary for military engineers, defense contractors, and leaders in general. I can't say strongly enough how important this is as a matter of professional competence.

For better or worse, PowerPoint is the tool of choice for making presentations. When anyone gives a presentation with dense, complicated, unreadable, illegible and otherwise horrible-horrible-horrible presentation charts, they are demonstrating sheer professional incompetence.

In case you can't tell, I get kinda worked up about this.

For all the time we spend giving and receiving briefings, it's inconceivable to me that honing one's presentation technique is not treated as an important discipline and a core element of professional development. I've even seen professional educators, who brag about their ability to facilitate discussions and interact with audiences, use powerpoint charts that are frankly embarrassingly bad.

This stuff isn't hard. Sure, it's a little bit more work than doing it badly, but once you get the hang of it, it's not bad. Go check out Garr Reynold's Presentation Zen blog for some great examples of how to do it right.

Failure

You might have heard the saying "If you fail to plan, you plan to fail." Here's a different twist on it:

"If you don't plan to fail, you've failed to plan."

As I've said elsewhere, failure is inevitable. It shouldn't be a surprise that things don't work out the way we'd hoped. So, rather than trying to prevent and avoid all failures, we should have a plan to deal with it, learn from it, respond to it.

In The Mythical Man Month, Brooks writes that software programmers should "plan to throw one away." That sounds like planning for failure to me. I think it's a pretty good idea.

One Man's Poison...

One of the fundamental beliefs of the process-centric, best-practices-oriented worldview (such as Hammer’s Business Process Reengineering concept) is that imitation is the highest form of performance.

I’m not saying this is necessarily what the theory recommends, at least not explicitly. It’s just what happens when the theory is put into practice. When the organization’s highest values include compliance and conformity, when the organization rewards following best practices rather than discovering new ones, then creativity, imagination, accountability and initiative are stifled, no matter what the theory says.

The late Michael Hammer described BPR as an “antidote” to chaos and conflict. If chaos and conflict need an antidote, I guess that makes them a poison. And sure, in excessive quantities, they probably are. So is alcohol. On the other hand, an absence of chaos and conflict might not be the right answer either, anymore than prohibition was a good idea. Dee Hock, the wildly successful founder of Visa, talks about “the chaordic organization,” which is a combination of chaos and order. Not a balance, necessarily, because how do you “balance” chaos? Rather, it’s a harmonious coexistence between chaos and order. There's no room for such harmony in BPR.

As for conflict, Jerry Harvey argues that our main problem in organizations is not how to handle conflict, but how to handle agreement. Specifically, how to handle disingenuous agreement, in which people go along to get along and end up on the road to Abilene. Let me say this clearly: Dr. Harvey is right. Dr. Hammer is wrong. Conflict doesn't need an antidote. Neither does chaos.

So, I’m deeply disinterested in driving out conflict and chaos (or administering the antidote). In fact, in the kind of work I do, I insist that there be some chaos, some conflict, some confusion. These strike me as essential elements for discovery, creativity and rigorous performance.

FIST Handbook - Updated

Team Rogue and I put together an updated version of the FIST Handbook (pun intended - sorry!), which collects the best of our articles from Defense AT&L.

Unfortunately, the file format has some incompatabilities with Lulu, so the version you can download on RoguePress is out of date. The new version is 12Mb, and rather than try to email it, I stuck it on Rapid Share. You can download your own very version right here.

Enjoy!

Simplifying UAV Controls

Over at MIT, a small group of grad students recently figured out how to control UAV’s using an iPhone, instead of the “complex, suitcase-sized controller that soldiers must haul around to control hand-thrown Raven (UAV’s).”

As reported at Wired’s DangerRoom blog, “In six weeks, we went from the idea to a real flight test,” using MIT’s indoor robot range... The total cost? $5,000 for a new, commercially available, quad-rotor robot — plus the cost of iPhones for her crew… It relies on only the iPhone’s existing gear, and the phone can still be used for regular calls, web-browsing, texting, etc.”

Hmmmmm– a small team of talented people, working on a shoestring budget ($5K? Really?) and a cannonball schedule (6 weeks!), successfully use existing, familiar, mature technology as a way to simplify the operations of a previously complex endeavor. Now, where have I heard that formula before? All in favor of launching a 10 year, $2.7B project to confirm their findings, say “Kick me!”

Interestingly, the MIT crew touts the iPhone “Drone Control App” as having some cool real-world uses. “Not only would a iPhone-like controller make soldiers’ jobs much easier, it also opens up UAVs to a whole new, non-military market. If robot control is cheap and intuitive, people might find all kinds of new uses. Cummings’ own favorite: “Being able to launch one out of the window and fly it down to the Starbucks, to tell me how many people are in line, so I know when to get coffee.””

Sure, it’d be cool to send out a pocket-sized UAV, controlled by an iPhone, to scout whether the line at Starbucks is long. But a website with a Line Cam would do jus as well. What would be really cool is if the little drone could handle ordering, paying and hauling a cup of java back to home base. Now THAT’s a killer app. Moving atoms around is something the internet just can't do for us (yet?).

Second thought - I probably got that backwards. The killer app is for Starbucks to field a swarm of UAVs that can fly around the city and deliver coffee, which you ordered via your location-aware iPhone. The UAV swoops in and brings you coffee (or pizza, chinese food, etc) to your precise GPS coordinates. UAV delivery is coming, I tell you, it's coming...

USAF gets FISTy with new Light Attack Fighter

As reported at the DEW line (and other places), the AF sent out “a request for information on July 27 that calls for first aircraft deliveries to start in Fiscal 2012 and the first operational squadron to activate a year later.”

Let’s see, requesting information in Jul 2009, for deliveries to start in FY12 (which starts in Oct 2011, a little more than two years from now), and an operational squadron just one year later… now we’re talking! The question of course is whether we’ll be able to stick with these short timelines, well-focused mission and emphasis on simple, mature technology, but this project definitely seems to be off on the right foot.

A similar phenomenon is happening in the area of light mobility airlifters. We’re talking about picking up 60 of these “cost effective” aircraft, with an initial operational capability date of FY12.

Strikes me as precisely the approach to capability acquisition we should be taking. I hope it sticks!

UAV's: Imagine The Possibilities

In the Jul 09 issue of National Defense magazine, Col Eric Mathewson, director of the Air Force's Unmanned Aerial Systems Task Force discusses some of the things UAV's will never do: "There's no way you can replace an F-35 or F-22 or something like that... No way."

In related news, "Lt. Gen. Dave Deptula, the Air Staff's head of intelligence, surveillance, and reconnaissance, said it is not unrealistic to imagine an unmanned aerial vehicle as successor to fifth-generation fighters-the F-22 and yet-to-field F-35-in our national military strategy, however he added that UAVs still require some technology maturation before they would be ready to assume that mantle. (AF Magazine Daily Report, 27 Jul 09 )

Which reminds me of a quote I heard somewhere, that went something like this: When the esteemed and aged expert says a thing can be done, he is most certainly right. When he says it cannot be done, he is most certainly wrong. (can anyone help with that reference?)

Bad Power Point

Holy cow there's a lot of bad PowerPoint out here. In fact, there are almost no good presentations.

It's not a new problem. I found an article from 1985 titled Let There Be Stoning, complaining about boring presentations and suggesting that such people should have rocks thrown at them. I wouldn't go quite that far, and I dislike the part in the article where the guy describes his public criticism of a particularly bad presenter. But seriously, something needs to be done.

Nobody likes to sit through a dense, convoluted presentation, do they? And yet, the standard approach is exactly that. It hit me the other day that we design our presentation slides the same way we design weapon systems - complex, endless and ineffective.

I think a big part of the problem many of us never got any training on how to create good presentations. It just wasn't part of the curriculum when we were in school. And yet, that's a big part of the job. It seems to me that it's incumbent on us as professionals to educate ourselves on how to communicate effectively.

And I nominate Garr Reynolds' Presentation Zen book & blog as a great starting point. If you give presentations, please please please read his blog, get his book, and start doing things differently...

Hope

Several times in recent days I've found myself wanting to jump up and run screaming out of a meeting. Fortunately, my military training kicks in and prevents me from making a scene (actually that's probably unfortunate - one of these days, I should probably do it).

What stimulates such a response? Rampant cynicism, explicit statements of a preference for process over talent, descriptions of the workforce as "elementary schoolers," disparraging comments about the value of consensus and praise for top-down dictation of mandatory actions, enthusiastic condemnations of situations where people have been "given too much flexibility, and scoffing at the idea of hope. It's the sort of thing the villian would say in a movie or a book... except this is real life.

That last one really got me. I'd heard people say "Hope is not a strategy" before, but never with such venom.

Personally, I think hope is essential. Hope is a discipline. Hope is good. We should combine hope with planning, talent and thought, to be sure. But there is something foolish about throwing hope out the window and stomping on it with such enthusiasm.

And so, I persist in my hope that things will change. I hope I will be able to make a difference. I hope I'll succeed in nudging things in a good direction, a more human direction, where people are led and not pushed around... where people are treated as professionals, are trusted.

I've got a strategy to make this happen. I've got a plan. And hope is at the heart of it.

Is Lean FISTy?

I've mentioned Lean and Six-Sigma in several previous posts, and wanted to spend a little time exploring one question in particular: Is "Lean" FISTy?

If you read yesterday's post, you probably know the answer is "It depends." There are certainly some areas of overlap between the two approaches, and some common underlying values. But they're not exactly the same thing. Let's take a look at some of the attributes of these two approaches. Please understand that although I'm taking a somewhat binary approach below, the comparison isn't strictly an either/or in every case.

Lean is a process-oriented methodology.

FIST is a person-centered value set.

Lean is about value-chain efficiency and manufacturing. It values repeatability and focuses on program commonalities.

FIST is about effectiveness and creation. It values originality and emphasizes program uniqueness.

Lean strikes me as potentially introverted, focused on removing waste from processes in order to maximize value for the customer.

FIST is emphatically extroverted, focused on ensuring the capability is "affordable, available and effective." It has a higher tolerance for "waste."

Despite protests to the contrary, Lean strikes me as somewhat myopic - not in theory, but in practice. Lean is supposed to be strategic, but when it's actually implemented, human nature tends to devolve it to narrow applications (i.e. implement a change that saves my unit $10 even though the change costs the overall organization $20).

FIST, on the other hand, is systemic, and takes into consideration the human element of decision making and problem solving.

Lean's focus on removing waste is probably good. Lean's over-definition of waste might also be good. It focuses on optimization

FIST has a tolerance for what Lean calls waste, and maybe even an affection for waste. FIST is not particularly interested in optimization (which it views as impossible anyway). Instead, FIST is about near-term sufficency as a strategic objective. The ability to rapidly deliver a capability for a short/near-term need is itself a strategic capability.

OK, this is just a quick sketch of some differences. Lean and FIST do indeed have some things in common. And Lean has much to commend it, particularly in areas where the work is well-bounded, repeatable, etc. It makes sense to apply Lean to situations like invoicing, manufacturing, maintenance, etc. But in other areas, where the work is not repeatable or well-bounded, the FIST approach can still serve to guide decision making and problem solving.

The Answer

One of the truisms of program management is that the answer to just about any question is "It depends." So I had to chuckle as I was leaving one of the buildings on the Defense Acquisition University campus and this little marble pillar caught my eye.

There it was, engraved for all time, the answer to every program management question.

Class dismissed.

Contracting Fail

I recently came across this post from Cliff at the Sunlight Labs blog, talking about their failed attempt to bid for a government contract (thanks to Dick for the link!). I say "their failed bid," but in fact I think it's more like the government's failure to get their bid. The current government environment is so insular, jargon-heavy and complex that a new company ends up facing all sorts of unnecessary barriers. Sunlight Labs ended up not even submitting their proposal.

But that's a discussion for another day.

What I want to comment on is their attitude to the whole thing. They looked at it as a learning and growing opportunity. They looked at it as a failure, yes, but a head-held-high kind of failure. Something to reflect on, learn from, and discuss with a wider community. They even acknowledged that, as it turns out, the project they'd planned to bid on was probably too big for their organization to effectively achieve. Now that is clearheaded humility and insightful self-awareness.

Their experience definitely gave me something to think about. I love their story, and I love the way Cliff tells it. And so we award Sunlight Labs the coveted Rogue Medal of Awesomeness.

Getting Started

Let's take a look at two different approaches to starting a new development project:

1) I've got X dollars and Y months - what capabilities can I get?

2) I need to be able to do X - what's it going to cost me and how long will I have to wait?

In both cases, we have constraints. In the first situation, the constraint is resources. In the second, it's the need. I'm going to suggest that in reality, scenario #2 is much rarer than scenario #1. However, we all too often act like #2 is the only way to do business.

Here's the thing - we often don't really know what we need. We generally have some idea, but our understanding of the ultimate objective is going to change over time. The longer the time, the more it'll change.

That's not bad!

We should expect some change, plan for it, and seek it out. Attempting to lock down our requirements on Day 1 (when we know the least about the project) is pretty stupid... unless delivery is scheduled for Day 2. And it's entirely possible to end up with something that is simultaneously different than what we thought we needed and better than what we originally aimed for.

Let me put it bluntly: on a long project (i.e. anything over 6 months), requirements creep is good. It shouldn't be a surprise, and we shouldn't resist it. We should count on it and perhaps even insist on it.

Two additional comments: It's important for the user to be informed, educated and involved. The ultimate customer (warfighter, user, etc) needs to be continually involved in the development effort, communicating truths about the operational environment and learning about the possibilities and limitations of technology. It's also important to foster a trusting relationship between all involved. I refuse to do business with people I can't trust.

Unique

One more bit of wisdom from Alex Laufer. The only comment I want to add is an invitation for process-oriented people to reflect on these three words:

Projects are unique.