The Special Operation Forces Truths

I found these in some professional reading material recently. For your benefit, Special Operations Forces (SOF) include the Navy SEALS, Delta Force, Army Rangers, etc. Their values always seem to be spot on.

Humans are more important than hardware

Quality is better than quantity

Special Operations Forces cannot be mass produced

Ops

I'm an engineer.

I do engineering and program management. That means I spend a lot of time in design discussions, technical interchange meetings, and test and evaluation procedures. The days can be hectic at times, and sometimes there's even a sense of urgency, but generally we're never talking about timelines measured in minutes or hours. It's always months & years.

Last week, I had a rare opportunity to work on an operations floor for a few days, supporting relief efforts in Haiti. The pace was jarringly fast, coming as I do from an engineering background. I'm a big advocate of "Fast" development, but it took me a while to get used to the speed of ops. To be honest, I'm not sure I ever did get used to it. Maybe I would if I did it more frequently.

The point is that it's important to spend time with the users, to understand their current capabilities and any shortfalls which engineers could/should address. It's something I've advocated for a while, but frankly it's been a few years since I've been able to do something as hands-on as this. The experience just reiterated for me how important it is to field reasonable capabilities quickly, and not make the users wait endless years while engineers perfect the design of systems for an environment we don't understand.

I remember being told once that "program managers don't need to talk to the customer" (I talked with the customer anyway). I've had trips cancelled because a Higher Up didn't think we needed to send an engineer to visit the users (so I used the phone instead). In my experience, there's nothing that can compare to spending time with the end user, breathing their dust and seeing what their capabilities and shortcomings actually are.

So, my advice to all you Rogue Project Leaders - make sure you spend time in the field.

Weird Wednesday

Welcome to another edition of Weird Wednesday. Today's topic: things that will unexpectedly kill you.

Everyone knows it's important to eat right, get enough exercise, and not smoke. Nonetheless, I thought it was kinda weird to hear that watching tv increases your risk of death. Of course, when we talk about "the risk of death," um, I think we're all 100% guaranteed to die someday. I think the finding is that if you watch a lot of tv, you're likely to die sooner. The point is, when we're talking about risks and percentages, it's important to be precise.

The other factor that was recently associated with early death is of particular interest to me. Apparently, people whose name begins with A outlive those of us whose name begins with D. It supposedly has something to do with a subconscious link to report cards (A = good, D = bad) and self-esteem.

At the risk of making an explicit connection to project leadership in what is supposed to be a somewhat random and weird blog post, let me just offer two words for your consideration as you make decisions about your project: unexpected consequences.

Zen of Python

I recently came across this little piece by Tim Peters, titled The Zen of Python (the programming language, not the snake). I'm not a programmer, but it seems to me that these principles are relevant to all sorts of creative pursuits, including system development and design (which IS something I do).

I'm not sure I understand everything he's talking about, and I probably think I understand more than I actually do. If I understood more, I might quibble over a line or two. But nonetheless, I think this is worth reading and pondering. And just in case the image above is difficult to read, here it is in plain text:


The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Go Big or Go Home

I'm a big fan of Hugh MacLeod. His blog and his minimalist "back-of-a-business-card" cartoons continue to be thoughtful, thought-provoking and insightful. I particularly like this one, and I'll just let it speak for itself.

Efficency Is Overrated

I just finished reading a fascinating paper from 1973, titled "Dilemmas in a General Theory of Planning" (thanks for the link, Phil!). It's where we get the term "wicked problem," which is "a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize."

The authors, Rittel and Weber, point out that tests for efficiency are less useful in wicked problems than in tame ones (like math & science problems), and that we need to focus on effectiveness rather than efficiency in such situations.

It's a great paper, with so many interesting concepts, but the one I want to focus on for a moment is the question of efficiency. One of the key assertions of the Rogue Project Leader approach is that efficiency is overrated. It's not bad, but people tend to overvalue it.

Specifically, it's important to not be content with the superficial appearances of efficiency, or with the ability to expend very few resources on something we shouldn't have been doing in the first place. It's equally important to not insist that every activity have a direct, visible, conscious link to the desired outcome. Sometimes the most important cause/effect relationships are invisible and impervious to analysis.

So, spend time in quiet, unhurried reflection. Spend time connecting, playing, exploring. Go for a walk. Don't worry if you can't directly connect these activities or non-activities to the end result. If the outcome matters to you, it'll connect eventually. Maybe not in a way you can identify and describe, but trust me, it'll connect.

Simplicity Cycle Update

Quick brag: The Simplicity Cycle has now been downloaded 1,952 times. Get your own free copy at RoguePress. I love that this little project has grown legs like that...

What's particularly cool is that I still find references to it on blogs. Just last month it appeared in a post on the Preventing Project Failure blog, by Michiko (who calls it "Dan Ward's brilliant Simplicity Cycle") and on Michael Krigsman's blog (who calls me Don Ward, then gets mildly criticized by readers for using an ambiguous word like "goodness" - oh well). The important thing is that people are still downloading it, reading it, and talking about it.

I also made it onto the Quotations Page of MyElectronicsProf.com.

UPDATE: I generally do my blogging in advance (on the weekends). So I wrote this posting about a week ago. Then yesterday, a handy-dandy little "Google Alert" let me know that the Simplicity Cycle got mentioned by a blogger named JCardente. It's a very nice, thorough and thoughtful review... stop on by the JCardente blog and check it out.

Weird Wednesday

Welcome to Weird Wednesday, in which I will write about something weird I found on the web.

Today's weirdness: How To Measure A Celebrity's Height.

OK, it doesn't matter how I stumbled across this article. What matters is that it's out there - full, detailed, even somewhat technical (he uses the phrase "interpupillary distance") instructions on how to estimate the height of a celebrity. Even if you never wanted to measure a celeb's height, it's worth clicking over and reading it.

What does this have to do with Rogue Project Leadership? Um, just about everything! It's a strange, strange world out there, full of weird ideas and unexpected tutorials. Weird Wednesday is therefore offered as a counter-point to the certainties and efficiencies of the engineering and project world.

Enjoy!

Enhancement Fail

A buddy recently passed along a newsletter called the "Defense Travel Dispatch," compliments of the DoD Center for Travel Excellence.

The nice people at the Center for Travel Excellence recently updated their online travel system software, which gov'ies use when making travel arrangements. Here's what they have to say about it"

"This release also included an enhancement known as “Tech Refresh,” which led to degraded system performance over a two-month period..."

Um, I don't think they're using the word "enhancement" correctly. I thought enhancements are suppose to improve performance, not degrade it. At least that's what all those spam emails tell me. Anyway, the newsletter got even more specific:

"Release 6... involved transitioning out-dated software language to a more commonly used code that is more efficient and facilitates quicker, simpler, changes to the system. This element led to degraded system performance over a two-month period, causing many users to experience difficulty accessing the system and slow response times."

No doubt the new code is better than the old code, when the new code is working. But when the new code isn't working, it's worse than the old code. If only there was some way to test this sort of thing before fielding it.

And hey, they're the Center for Travel Excellence, not the Center for Excellence of Making Reservations and Booking Travel...

MOSA Makes Me Sad

I recently came across the term MOSA, which stands for Modular Open System Architecture (or Approach, depending on the source). As one source explains, "Modular Open Systems Approach (MOSA) is both a business and technical strategy for developing a new system or modernizing an existing one." That document goes on to explain that MOSA helps project teams to:

1) design for affordable change
2) employ evolutionary acquisition and spiral development, and
3) develop an integrated roadmap for weapon system design and development.

Although I think terms like "integrated roadmap" are kinda dorky, I really dig MOSA. At the same time MOSA makes me sad.

First, what I like about it. It's a very thoughtful approach to dealing with uncertainty and change. MOSA is FISTy in its preference for affordability, simplicity and iterative design. It provides practical, actionable principles and tools for engineers and managers alike. It seems like it would be a very constructive approach. I LOVE that it addresses both the technical and the business side of things.

So why does it make me sad? It was adopted by the DoD in 2004... and I just heard about it a few months ago. It was incorporated into DoD 5000.1 (the policy directive for defense acquisitions), but it seems to have fallen by the wayside anyway. It was adopted by the Open Systems Joint Task Force, which is no longer in existence. There's a cool MOSA website, featuring a tool called PART (Program Assessment and Rating Tool) and several documents... and I'm not sure anyone's using it.

In short, MOSA achieved a level of official acceptance that I can only dream of for FIST... and it just isn't being used. Do a google search for MOSA and the first thing that pops up is the Monmouth Ocean Soccer Association. Really? Ocean Soccer? What's that? There are also links to the Midwest Organic Services Association and the "Montgomery Otsego Schoharie Solid Waste Management Authority." Come on, that doesn't even spell MOSA! That's MOSSWMA!

There's an asian bistro and a radio network named MOSA and even a Museum of Sentimental Art. But the first three pages of results didn't provide any links to the Modular Open Source Architecture (approach). I didn't look any deeper into the Google results than that.

This is kinda discouraging because MOSA advocates got so much farther than I did with FIST... even farther than I probably ever will. But despite their success in officially integrating MOSA into the formal guidance, creating a snazzy website, etc... it seems to have fizzled. Damn.

Or maybe it's being used all over the place and I just haven't heard about it yet. That's possible. I hope so.

Great Books, Part 2

The book I'm in the middle of now is The Reflective Practitioner, by Donald Schon. It's another book that I've read a few times over the years, but always from a library. Now I've got my own copy and I'm marking it up like crazy.

"Reflective Practice" is about "knowledge-in-action," an intuitive, often undescribable approach that is more craft than process. Schon looks at the practice of medicine, law, engineering, architecture and urban planning, and examines the divergence between academia and practice (also described as the dilemma between academic rigor and practical relevance). He argues that skilled practitioners exhibit "a kind of rigor that is both like and unlike the rigor of scholarly research..."

Schon writes about the practitioner who makes "innumerable judgments of quality for which he cannot state adequate criteria, and he displays skills for which he cannot state the rules and procedures." It's basically the antithesis of the idea that "if you can't describe what you do as a process, you don't know what you're doing."

Schon says a good practitioner does indeed "know" what he or she is doing. The knowledge is expressed in the action, because words and diagrams are inadequate to convey the knowledge. He's quite critical of the positivist model of technical rationality and its belief that "empirical science was not just a form of knowledge but the only source of positive knowledge of the world." In contrast, Schon asserts that "competent practitioners usually know more than they can say."

It's a great book - albeit heavily intellectual and occasionally a bit dry. But I love it and heartily recommend picking up a copy.

Great Books, Part 1

I got some great books for Christmas, and just finished (re)reading one of them.

It's titled Up The Organization, and it's a classic. First published in 1970, it's the leadership and management philosophy of Avis CEO Robert Townsend. He was a real Rogue Leader, and I'd read this book a few years ago, but it was a library copy. Now I have my very own, and I can write it in as much as I want to!

A few excerpts for your reading pleasure:

"Big successful institutions aren't successful because of the way the operate, but in spite of it. They didn't get to the top doing things the way they're doing them now."

"If you're going to function effectively in our organizational society, it's important that you have a healthy contempt for our major institutions, public and private - especially for their leaders."

"Too little is almost always better than too much... A tight budget brings out the best creative instincts in man. Give him unlimited funds and he won't come up with the best way to a result. Man is a complicating animal. He only simplifies under pressure."

Finally, here's the text of a memo he left behind every time he was out of the office for more than a week:

"I've gone away. Until I get back Henry is chief executive officer. Please don't hold up decisions. Anything you do in my absence will have my complete support when I return." [Note - it doesn't say when he'll be back or where he's gone off to. That's a deliberate omission].

Unexpected Data

The phrase “seismic echo” recently popped into my head for no reason that I can explain. When I Googled it I discovered that it’s not a common phrase. However, I did come across an interesting paper from 1970, published by one A.I. Mukhamedzhanov.

The paper is titled The Nature of the Lunar Seismic Echo. Sadly, the full text is not available online, but the abstract alone was worth a read:

One of the interesting effects discovered during the recent Apollo 12 mission was the unexpectedly long duration of the Moon's seismic reaction to the impact of the ascent stage of the lunar module. Instead of the expected few minutes, the oscillations continued for about 55 minutes. No less unexpected and indeed somewhat disconcerting was the reaction among the specialists who were immediately faced with the difficulty of explaining this effect. The specialist world, under such circumstances, is reminiscent of a beehive reacting to an unexpected intrusion. However, the seeming chaos of conflicting opinions here involves three attitudes: (1) disbelief in the instrumentation; (2) the desire to construct, without delay, a new theory; (3) the attempt to account for the new phenomenon on the basis of some old theory. The duration of the seismic oscillations is calculated directly in terms of a theory worked out by the author back in 1965 (the multiple-cascade fall of material ejected by the impact of a meteorite on the lunar surface) and it is indicated just what was responsible for the Apollo 12 effect.

Regardless of how fascinating the science is (and it is!), what I particularly liked was Mr. Mukhamedzhanov’s observation of how specialists react to unexpected data. Basically, they:
1) Blame the sensor / disbelieve the data.
2) Accept the data and create a new theory.
3) Rely on an older, previously neglected theory to explain the data.

When faced with an unexpected outcome, is this a good or bad way to react? My first reaction was to chuckle at the “disconcerting reaction.” But the more I think about it, this reaction just might make sense.

And scientists aren't the only ones who face unexpected data. Project leaders get that all the time. How should we react? Blame the instrument? Create a new approach? Regroup?

Thoughts?

Predictions!

In 1893, a group of esteemed thinkers produced a collection of predictions about what life would be like 100 years into the future (1993). You can read the results of their prognostications in a book titled Today Then. As you might expect, these prognosticators had a lot to say about the importance of railroads in the future... and not much to say about this new thing called an automobile. I offer this as just one example of how long-term predictions are most useful as an exercise in humor.

On that note, for those who are interested in future-stuff and making predictions, you might want to check out a little article I wrote titled There Are No Facts About The Future, available on everyone's favorite defense technology magazine.

Unfinished...

If I had to finish everything I started, I'd never start anything. For me, the freedom to stop creates the freedom to start.

Creative exploration and discovery necessarily involve trying some things that ultimately don't work out. The dead-ends and false-starts aren't waste. They are an important part of the process of learning and producing new things. For that matter, they're not really false starts. They are true-starts, in which I'm really doing something (and learning from it, etc). The fact that the link between a stopped project and a completed project isn't obvious to a casual observer doesn't mean the link isn't there.

For every article I actually publish, I probably start three or four. My computer is full of half-finished, half-formed articles, the fruitful detritus of my writing efforts. Because I don't force myself to finish and publish every article I start, I'm free to start writing all sorts of things, to explore ideas even if I don't know up front whether they'll work out. The freedom to delete is the freedom to create.

Without that perspective, I'd end up over-editing myself, only starting new things when I knew what the end would be. Hey, I'm all for beginning with the end in mind, but absolute conformity to that approach would make for a pretty tight leash. Sometimes you've got to just begin, even if you can't see the end from here.

Inevitabilities & Options

The Rogue Project Leader approach to work makes several assertions that stand contrary to the typical approach. The main assertions have to do with the non-inevitability of delays and overruns. The Rogue approach asserts that it's possible to deliver ahead of schedule, under budget, and still be completely awesome. Finally, Rogues don't equate success with perfection.

From a technology development perspective, Rogue says that more time and more money don't make the system better. Rogue asserts that constraints foster creativity, and that restraint is a virtue, both organizationally and technically. It's about allowing the schedule & budget to constrain the design, rather than allowing the design to drive the schedule and budget.

There's a strong streak of imperfectionism running through the Rogue Project Leader approach. That is, there is an explicit preference for delivering something tangible now, however imperfect or incomplete, instead of promising a hypothetical perfection to be delivered at a later date.

All too often, the engineering world starts with a preference for perfection and a tolerance for delay. Macho sloganeering leads otherwise sensible engineers to assume a "failure is not an option" posture. The end result is excessive risk aversion, increases in complexity that actually reduce reliability, cost over runs and schedule delays... all mistakes made in the name of ensuring we don't make any mistakes.

Rogues make mistakes too, of course. Rogue projects can (and do) fail, but Rogue failures are not surprising to the Rogue Project Leader, and they're not the end of the story. Rogue failures also cost less and teach more than the epic fails caused by pursuing perfection over long timelines.

Rogue Projects Are Fast

I like projects that move along quickly.

That is, when I’m part of a team developing a new system, I like it better when the timeline between initiation and delivery is measured in months rather than years or decades. And when I use the word “like,” I am expressing a preference that is simultaneously personal (based on my taste & style) and professional (based on research & data). I like it because it appeals to me, not only in a visceral sense but also because it makes intellectual & experiential sense and leads to desirable outcomes. I don't see any conflict between my personal and professional preferences –I just want to make it clear this is more than a personal preference.

Among other benefits, speed means you belong to the project and the project belongs to you. If it’s got a long timeline, you’re inevitably in the muddled middle of someone else’s vision, someone else’s headache. On a long, slow project, you are unlikely to see either the start or the finish. If you do happen to see one end, the other end is even more distant. The belongingness of a fast project has a positive impact on quality and satisfaction.

Yes, it’s possible to feel ownership in the middle of a long project that was begun by someone else and will be finished by someone else… but it’s unlikely. It's not the default position.

There are many other benefits to short timelines. Speed reduces instability, reduces costs, encourages simplification, and helps ensure operational relevance. But the fact that speed fosters ownership and commitment is a particularly interesting benefit... and it's a benefit I really like.

Cyber Metaphors

For those who haven't heard yet, the latest issue of Defense AT&L is posted.

Yay!

In this Very Special Episode, I return to the topic of metaphors and the central role they play in human understanding and thought. The article is titled It's Not A Big Truck, and if you've ever asked yourself "What IS this 'internet' thing everyone is talking about?" then this article is for you. Also, if you ever use the internet.

Note: I wanted to point out that a metaphor is like a simile, but I couldn't work that line into the article. So you have to read it here instead. Hokay?

Let's Get Small!

I like small teams, groups and organizations.

I'm quite convinced that organizational growth is not always desirable. That is to say, for the kind of work I like to do, I don't find organizational bigness all that attractive, both as a matter of personal preference and professional opinion. Yes, being big provides certain economies of scale, but in any economy there are two sides to the balance sheet. Economies of scale convey benefits AND costs. Similarly, being small conveys some benefits and some costs.

The technical term for this preference for smallness is subsidiarity (which says that matters ought to be handled by the smallest, lowest or least centralized competent authority.)

So, Rogue Project Leadership is a subsidiarity-based approach. It rests on the idea that the costs and benefits of being small are better than the costs and benefits of being large, within the context of the kind of work that Rogue Project Leaders do. Other people with other values and priorities may find that being big satisfies their needs and interests better than being small. I'm just pointing out that being big is not a universal, inevitable objective.

As yesterday's post mentioned, RPL is all about people, and being small makes it easier to know, respond to, understand and care for everyone on the team. As a general rule, small teams have more direct, organic and human communication paths. They're more personal.

Small can also improve the quality of production, by enabling a craftsman approach instead of a mechanical assembly line. It's been my experience that I care about something more (and have a greater sense of ownership) if I'm involved with it end-to-end. Throwing it over the wall to the next guy has a distancing affect. We see this benefit in things like microbrews and home made bread... or small tech companies.

This approach doesn't exactly scale, at least not in the sense that some people mean when they use the word "scale." It's not supposed to. It's about handling things at the smallest, most local level. So one of the costs of being small is that your reach is limited. You probably can't penetrate certain markets. The demand may always be higher than what you can supply (which is a mixed blessing, I suppose). But keep in mind it's not about choosing between one small Rogue team and one big non-Rogue team. It's about choosing between 1000 Rogue teams and one big enterprise... and this approach is unlikely to create something that's "too big to (be allowed to) fail."

People

I am firmly of the opinion that work is all about people, and all value comes from unleashing the creative talent of each person.

It doesn't matter whether you're the leader or the follower, the customer or the provider. Work is about how we relate to each other as human beings. It's not about money. It's not about efficiency. It's not about promotions and power. It's about encouraging and equipping people to do stuff that matters. This doesn't mean efficiency is bad. It just means efficiency isn't the most important thing. Taking care of people is the most important thing.

Accordingly, any approach to work that relegates "the human dimension" to a subordinate position (or refers to it as "the human dimension") is already off course. How we treat people, how we view people, must be absolutely central in the definition of an approach to work. All other topics are subordinate, and should return to the central idea of people as the source of meaning and value in work.

So, Rogue Project Leadership begins with building a small team of talented people... and recognizing them as such. They are not "human resources," they are people. They are uniquely talented. And the Rogue Project Leader's main job is to take care of these people and unleash their unique talent.

So things like listening, mentoring and encouraging are central activities of a leader. As the great Joe Wotton often said, "it's easier to direct energy than create it." Accordingly, the Rogue Leader strives to direct people's energy towards a common goal, and takes great pains to not extinguish or diminish people's energy and enthusiasm.

Rogue Project Leaders don't simply allow people to explore and play. They encourage it, because it is simultaneously good for the people and for the organization. There's no contradiction or tension here - doing the right thing for the people is not only good for the organization, it is why the organization exists in the first place. If the only way for the organization to persist is to treat people badly, then that organization doesn't need to exist any more (or it needs to reevaluate its goals, means and methods).

Foundations

Happy 2010 everybody! I hope your holidays were grand.

I'd like to kick things off this year with a few reflections on the foundational principles & preferences that undergird the things you'll read here. I spent some time last month waving danger flags & pointing out some bad ideas & practices. Now I'm going to focus on the things I think are good ideas.

My favorite way to do work is with a small team of talented people, focused on developing and providing an innovative solution to an important problem. They should have a small budget, a short schedule, and a tight relationship with the customer.

Let me be clear - I used the phrase "my favorite" very deliberately. I LIKE this approach. Strictly as a matter of taste and style, I find this approach attractive and exciting. It has an emotional resonance with me, apart from any objectively demonstrated value.

I also think this approach works, particularly for the kinds of problems / challenges / situations I encounter. I've found it to be an effective way to write software, to design systems, and to run a program management team.

Does it work for manufacturing, medicine, education or the law? Maybe. I'm tempted to suggest it does. I know the craftsman approach is good for making cheese, bread and beer. Could it apply to other enterprises? I don't know. I've never worked in those fields, so any answer I can give would not only be purely theoretical, it would also be based on precious little actual data. And while I love a good theory, I have enough engineering training in me to believe that data & experience matters.

Over the next few days, we'll take a closer look at different aspects of this approach.

Weird Wednesday: Richard Wetherill

What's wrong with the world? According to the late Richard Wetherill, there's just too much wrongness. What we need instead is more adherence to Nature's Law of Absolute Right.

I discovered Mr. Wetherill's work in an advertisement in Popular Science. Its invitation to visit "our colorful website" is what hooked me, because doggone it I'm just tired of all those non-colorful websites out there.

What I found was a generous offering of free eBooks & essays, arguing that "no person can long withstand the continued onslaught of carefully presented truth. It will finally compel recognition of error." As much as I like being slaughted on and compelled, I regret that I can't quite endorse his stuff.

No doubt there's some kernel of truth in Mr. W's writings. But there's also a rationalistic, modernist, pseudo-religious & pseudo-scientific streak that ends up sounding downright cultish in its insistence that here is the revealed truth, here is the undeniable law expressed, the solution to all that is wrong in human affairs.

Not much room for doubt. Not much room for mystery. And a striking absence of humor. I'm not saying the guy is completely wrong... just that he's a good topic for a Weird Wednesday post.