In knowledge work, there is value in reducing uncertainty.

Certainty is comfort. Certainty is ease. Certainty is the product.

I’m pretty sure it was Steve McConnell in Rapid Development (which Amazon remembers me purchasing 17 years ago) who introduced me to the concept of the Cone of uncertainty.  In the book, he explains how as requirements are gathered, code is built, and testing is performed that we progressively improve our ability to estimate since unknowns are being removed.  I think this concept has a broader application to any type of knowledge work, be it software development, consulting, financial valuation, or other types of “figuring things out”.  Here’s a sketch to illustrate my mental model:

It is useful to keep in mind that you can never remove all of the uncertainty – you can only get as close to Truth as is practical with an acceptable amount of uncertainty remaining.

Look at the Cone of Uncertainty as a model, not as actual measurement, and consider the path from initiation (Complete Unknown) to delivery – such as working software which has been tested, documented, formatted, commented, etc.  Let’s slice the cone into 9 steps and pull out the total uncertainty (i.e. add the left and right distances from Truth centerline) to represent what someone needs to overcome to move to the next step:

At step 1 (Creation/Initiation) there is a huge reduction in the amount of uncertainty. Accordingly, there is huge value.  People who create companies, people who create products, and salespeople are all good examples of working in that area.  The ability to go from a nearly complete unknown to something that has structure is incredibly valuable – and can offer corresponding financial rewards.

The next few steps chip away at uncertainty until we get to the first working version.  It’s not just that it takes skills to gather requirements, determine an appropriate architecture, and design a system – it’s that at every step along that path there is a non-trivial amount of uncertainty which must be dealt with.  The people working in those domains need to understand that uncertainty and press forward to reduce it.  It’s uncomfortable to be unsure.  The feeling of sticking your neck out and running the risk of being wrong can be crippling to some – think of everyone who says that they could never be a salesperson or start a company.  Those who overcome that feeling and work through it, however, are some of the highest paid people in any industry.

Note also that between step 5 (First working version) and step 9 (which is, essentially, a very specific form of documentation) there is very little reduction in uncertainty. This makes sense if you think about it – you could hand software from step 8 to anyone with basic development skills to have step 9 completed. While this is still an important step, there is substantially less value in it compared to building the first version since it is commodity work.  This is also one of the reasons why developers are so hesitant to comment their code, write documentation, etc. – it doesn’t have the same level of satisfaction that comes from building something and going from concept to functioning code.

This idea has been on my mind for a few weeks now since I work with team members in a wide spectrum of capabilities and price points.  I started wondering, “Why do we pay Igor the designer more than Ivan the tester?” and “Why is this guy paid like a team lead while that guy is paid like an intern?” In each case it wasn’t the individual’s skill level, but the amount of uncertainty they managed to both deal with and reduce for us.  A designer who can take fuzzy direction like, “Make it look modern and attractive” and create a great user interface is worth more to us than a tester who takes a piece of software and reports back “Here are the things I tried and here are the results”.  This is particularly interesting to me since testing is hard and requires more skill to do well than most people realize.

I’ve focused a lot on how this applies to software, but I’m pretty sure you can apply it to any knowledge-work based position.  This leads to a couple of important conclusions.  The first is that you need to accept, acknowledge, and overcome uncertainty.  Part of your job is to explain, contain, and remove that uncertainty.  This is usually accomplished by writing something which explains what you found, what you decided, and why.  Someone with more (or different) experience may disagree with you, but if you’ve provided what you know and what you think it will be easy for others to improve or correct what you’ve done.  Lastly, if you’re looking for a way to become more valuable then work your way up the cone to deal with increasing levels of uncertainty.  The ultimate is to create a completely new product or company and go from the terrifying unknown to millions of people understanding you.