Write Less More

A few weeks ago I decided that I wanted to write here more often, but I found it extremely difficult to come up with anything to write about. It’s not that I don’t have anything to say or share, but that none of it seemed worth saying or worth sharing.

After thinking about it for a while I realized that most of the writing I’ve done over the last few years has been focused on marketing the products I was working on. When I wrote something it was with the goal of making it to the front page of a site like HackerNews. The title had to be optimized for maximum SEO impact, the content had to have charts and numbers and insights that people would find valuable and worth sharing. As a result of this must-make-it-to-the-front-page mentality, the bar for what should be a blog post became set very high. If it wasn’t likely to get several thousand new visitors, it just wasn’t worth writing.

I’m going to try something new. Instead of a few big posts here and there I’m going to try to write shorter posts more frequently. At least in the beginning, nothing should take more than 15 or 20 minutes max to write. One word titles are fine, quotes are fine, pictures are fine. Anything goes. By writing more often I hope to become a better writer, share a bit of what I’m learning, connect with new and old friends, and perhaps benefit from some of your perspectives on whatever I’m writing about.

I’ll finish up by quoting a short story that I first saw in a post on Derek Sivers’s blog called Does quantity + learning = quality? which neatly summarizes why I think shorter posts more frequently is a good approach:

The ceramics teacher announced he was dividing his class into two groups. All those on the left side of the studio would be graded solely on the quantity of work they produced, all those on the right graded solely on its quality.

His procedure was simple: on the final day of class he would weigh the work of the “quantity” group: 50 pounds of pots rated an A, 40 pounds a B, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an A.

Well, come grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity!

It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Logistics

From Max Brooks’s World War Z:

Ask anyone how the Allies won the Second World War. Those with very little knowledge might answer that it was our numbers or generalship. Those without any knowledge might point to techno-marvels like radar or the atom bomb. Anyone with the most rudimentary understanding of that conflict will give you three real reasons: first, the ability to manufacture more materiel: more bullets, beans, and bandages than the enemy; second, the natural resources available to manufacture that materiel; and third, the logistical means to not only transport those resources to the factories, but also to transport the finish products our to the front lines. The Allies had the resources, industry, and logistics of an entire planet. The Axis, on the other hand, hand to depend on what scan assets they could scrape up within their borders.

When we think about war we often imagine the combat taking place on the front lines but just as important is the infrastructure that gets the soldiers there and supports them after they arrive.

When folks learn that I was in the Air Force many ask if I was a pilot because that’s what people tend to think Air Force personnel do. However, only about 3% of Air Force personnel are pilots; almost everyone else supports the pilots in one way or another.

I got to experience this first hand when I worked at the 87th Mission Support Group at Joint Base McGuire Dix Lakehurst in New Jersey. The Mission Support Group consists of six squadrons, each with a important role that supports the base as a whole: the Communications Squadron enables personnel to communicate with each other, the Security Forces Squadron keeps the base secure, the Mission Support Squadron handles personnel administration, the Logistics Readiness Squadron keeps the vehicles running and the planes fueled, the Contracting Squadron ensures contracts are awarded on time and without issue, and the Civil Engineering Squadron oversees the facilities. Without any one of these or a dozen other units on base the pilots would not be able to fly and the planes would not be where there they need to be.

Similarly, to have a successful software business it’s not enough to simply crank out code. You need to have fast servers, excellent marketing, helpful support, solid documentation, a clean, intuitive design, and a whole lot else. Like the squadrons in the Mission Support Group, these are not what you normally think of but they are critical nonetheless.

It may be worth thinking about what the key support elements of your business or life are that enable you to do what you do. Are you giving them the attention they deserve? Is there anything that you could be doing better?

Photo courtesy of Flickr.

Beware of The Good Idea Fairy

5goodideafairyWhen I was in the Air Force I had one assignment where I worked closely with a lieutenant colonel who was a self-proclaimed “good idea fairy”.

Every time we had a meeting he would interrupt to tell us about some idea he had just thought of that might be able to help with what we were working on.

The conversations would go something like this:

Us: The bus was half an hour late to pick up the technicians today because it had a flat tire and the driver had to go pick up another vehicle.

Him: Every technician should have his own vehicle so that we never have to deal with this again.

Each time he suggested a half thought-out idea, we would have to take time to consider it and the consequences of implementing it.

Us: Does every technician really need his own vehicle?

Us: Do the technicians have a government drivers license so that they can drive the vehicle?

Us: Does transportation have enough vehicles to lend out to one or more of the technicians?

Us: If we give the technicians a vehicle, other teams may want a vehicle of their own as well. Do we really want to go down this route?

And so on and so on. It’s not that his solution was terrible, but that a little bit of extra consideration would have led him to realize that there were a lot of practical problems with it. Instead, we were constantly being side-tracked by discussions about whether or not his ideas had merit. Most of the time, because they were not well thought-out, they didn’t.

He took pride in being a “good idea fairy” and every now and then he did have good solution, but most of the time his poorly considered solutions caused us to waste more time than they saved.

When you are holding a meeting, you want to encourage participation from the attendees and if you are constantly shooting down someone’s ideas, it might discourage others from speaking up in the future. Because of his rank and position and because we didn’t want to discourage people from speaking up, I don’t think anyone ever spoke to him about it, but I’ve always thought back on that when an idea pops into my head in the middle of a discussion.

The question then is how do you encourage creative solutions but also cut down on the number of Good Idea Fairy ideas? I don’t know — maybe you can’t. Maybe in order to discover gems you have to sift through a lot of dirt. Maybe that’s just part of the collaborative problem solving process.

What do you think? Is there a way to cut down on the number of Good Idea Fairy ideas while still encouraging people to speak up when they have a potential solution to a problem?