Category Archives: Productivity

The other day I was musing about fear and ambiguity (uncertainty) and a few days later I was browsing Jonathan Fields’ blog and saw that he had written a book on just this topic.  Lucky for me it wasn’t checked out at the library.

One of the single greatest determinants of high-level success as an innovator or creator in any realm is the ability to manage and at times even seek out sustained levels of uncertainty, bundled lovingly with risk of loss and exposure to criticism (p. 10).

The book begins with an in-depth exploration of the three psychic horsemen of creation: uncertainty, risk, and exposure to criticism.  We’ll uncover why they lead to so much suffering and why, in spite of the havoc they so often wreak, they must remain present.  We’ll also look at what happens when you try to snuff them out instead of embracing and even amplifying them (p. 12)

Overall it is good read, though I was left wanting more and feeling that perhaps the concept and packaging were oversold.  I was expecting something a little deeper and memorable.   I appreciated the section about mindfulness and meditation, something Fields refers to as AT (attention training).  Meditation really does make it easier to focus and focus often makes it easier to deal with uncertainty and move through it.

Image by Nicolas Lannuzel via flickr used under a Creative Commons license.

This is worth thinking about.

Unaddressed fear becomes toxic; it erodes our mind, body, and spirit. When we try to avoid our fear, we feed it. When we lean into it, we soften it. The fear-busting practices of yoga and meditation help us lean into our fear. They help us be present with it—which is when, ironically, it begins to feel more transient, more a part of the ebb and flow of daily emotional life.

This is from Facing Uncertainties and Transitioning Through Them by Bo Forbes at fearlessstories.com.  I’ve never tried yoga, however I have found mediation to be helpful.

This part really resonated with me:

How willing are we to go through the death of old structures in our lives? How ready are we to tolerate lack of definition? The more willing and ready we are, the more we can use fear as an impetus for growth. This, to me, is the true meaning of fearlessness.

Tolerating ambiguity can be difficult.  As I look around I see that most well grounded people are good at it.

Another skill is knowing when to tolerate and “sit with” the ambiguity and let the tension be the teacher.  Or when it is time to break ambiguity down and dig for clarity and definition until it is found.

Image by Alexander Stielau via flickr used under a Creative Commons license.

Starting leading your emails and blog posts off with the punch line.  Here’s why.

Most people write emails and blog posts that build a case, fact by fact and piece by piece, almost like a case presented to a jury.  There’s a false belief many of us hold that other people will read each block of compelling information we present and be persuaded by the conclusion at the end.

That’s where The U2 Method of High-Impact Writing comes in.  Leading with a bang is more important than ending with a bang.  It is more effective because it catches the reader’s attention from the start and pulls them in.

I cannot tell you how many times the last paragraph of a post has become the first.  In fact after a draft is complete one of the first questions I’ll ask myself is, “How can I start this post off with more force and clarity?”  I’ve lost count of how many times leading with the last paragraph or sentence accomplishes this.

If you want to write better emails or blog posts I highly recommend the three simple steps suggested in The U2 Method of High-Impact Writing.  And if you can’t remember all three just think of it like I do, “Make the punch line the start of  your post.”

Right Angle Screw Driver

Until recently I’d never heard of or seen this tool before.  Then a headlight went out on my car and I had to remove three screws in very difficult location.  I found a couple of forum posts describing how to remove the lightbulb along with a few mentions of using a right angle screwdriver.

I was even more shocked to find one for $5 at the local Harbor Freight–the store of disposable tools.  I’m okay with cheap tools as long as they get the job done.  This one definitely did.

I’ve been skimming Where Good Ideas Come From: The Natural History of Innovation by Steven Johnson.  It’s fairly dense reading so I’ve been skimming through to sections that catch my interest.

This section about innovative environments from page 148 was striking:

Innovative environments thrive on useful mistakes, and suffer when the demands of quality control overwhelm them.  Big organizations like to follow perfectionist regimes like Six Sigma and Total Quality Management, entire systems devoted to eliminating error from the conference room or the assembly line, but it’s no accident that one of the mantras of the Web startup world is fail faster.  It’s not that mistakes are the goal–they’re still mistakes after all, which is why you want to get through them quickly.  But those mistakes are an inevitable step on the path to true innovation.

This reminds me why I’m totally loving working on OpenShift–the rapid development model and the explicit desire to innovate.  This is contrasted by other projects I’m close to that are either waterfall or attempting to be a combination of agile and waterfall.  My initial impression is that tying to do both is actually worse than picking one or the other.

Recently I’ve begun to wonder if the waterfall method of development is more about managing fear and the illusion that “if you have a detailed plan you will have a corresponding level of success.”  This isn’t to say I didn’t once believe this.  I’ve been through enough projects now to realize that detailed plans are only good for the short term and that something unexpected usually happens requiring you to adjust.

Honestly–the last project you worked on, that one with the “One to Three Year Roadmap”–how much of it came true?  Chances are, the project got canceled, re-directed, or turned into something else after nine months.  All that time planning and predicting the future–was it really worth the time invested?

Detailed project plans and requirement documents are often obsoleted a month or two after they are created–because once you get into the implementation details or you actually release something, you learn something you didn’t know before.  And based on that information, the smartest thing to do is make adjustments. If you’ve planned with a high degree of complexity, making those adjustments is painful.

This is the benefit I’m seeing with agile development–take the weeks and months you would normally spend planning and writing fancy Product Requirement Documents (PRDs) and Marketing Requirement Documents (MRDs), having meetings, and getting feedback from the whole world, and use that time writing some high level requirements and user stories.

Then, start your first sprint, before you are ready, even if the first few sprints are a complete failure.  At least you will have gotten that part over with.  And then, most importantly, ship or release what you’ve created, after each sprint, to a larger audience so they can start using it and give you feedback.

I’m sure there is still a place for waterfall approaches–things like tactical operations or situations where you only have one chance to succeed.  Maybe there are places you can iterate on airplane design and yet the outcome of crashing a plane is much different than a sprint that “crashed and burned.”  Context is important.  Here I’m mostly thinking about online product offerings and web properties, though I think there are probably wider applications.

The book links above are affiliate links to Amazon.

A few weeks ago many users of the vendor Epsilon issued a pathetic apology for the potential leak of customer information.  In complete contrast Amazon Web Services (AWS) made a substantial  apology for the outage they experienced.

Not only did AWS apologize for what happened, they went into excruciating detail to explain what happened, AND they refunded all customers beyond the time of the outage–even those not affected.

For customers with an attached EBS volume or a running RDS database instance in the affected Availability Zone in the US East Region at the time of the disruption, regardless of whether their resources and application were impacted or not, we are going to provide a 10 day credit equal to 100% of their usage of EBS Volumes, EC2 Instances and RDS database instances that were running in the affected Availability Zone. These customers will not have to do anything in order to receive this credit, as it will be automatically applied to their next AWS bill. Customers can see whether they qualify for the service credit by logging into their AWS Account Activity page

They hit all the high notes on the things I’m looking for:

• Apologize
• Show me you mean it by giving me something
• Demonstrate how seriously you take the situation.

Great job Amazon!

Image by Peter Harding via flickr used under a Creative Commons license.