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.