In the previous post in this series I discussed sunk costs, and how they mount as we work without feedback on large projects. And we talked about how sunk costs will often amplify any doubts and anxieties we have about our work.
Perhaps the probability of having doubts is a function of time since last feedback, and the degree of anxiety is a function of the subjective size of the sunk costs.
Or something like that.
Anyway, in this post, I want to discuss another reason why things will be more difficult for us if we work too long on a project without feedback.
Big Projects and
On any large project we should expect unexpected complications. That point was covered in more detail here. We know that when we merge parts of any plan together to form an overall solution, there’s often more structure in the parts we’re using than we can see. Usually, the parts we use are themselves composed of parts composed of parts, etc. And these parts (and sub-parts) will conflict with each other in ways we can’t anticipate.
So that’s rule number one:
RULE #1: You should expect unexpected complications.
And here’s another rule:
RULE #2: Unexpected complications cost us more if we discover them late.
If you’re baking a cake and the oven stops working halfway through the cooking time, this will cost you more than if you’d discovered the oven problem before you put the cake in.
If you write a book, and give the finished manuscript to an editor, and the editor comes back and says, “This is good, but it would be so much better if the lead character were a lawyer instead of a doctor, ” and you realize you agree with your editor — that’s a problem.
Had you sent a sketch of the overall plot with a first chapter, and received that opinion after 2 weeks, it would have been no problem.
Whenever you create something with a high degree of complexity, it’s like growing a tree.
If you create the trunk, and the first three branches, and realize right away that two of the branches will conflict with each other, you can plan a resolution right away without much trouble.
If instead you develop each main branch, letting it grow and branch and grow and branch — and THEN you discover the conflict, you have your work cut out for you. You can’t just adjust one part to another without worrying about how all the other branches and twigs will be affected.
Sometimes you can re-factor things and make it work. And sometimes you will have to start over and re-grow the tree from the start, having wasted much of the time spent growing the first version.
How to Discover Unexpected Complications Sooner
So, for a given complication, it’s almost always best to discover it as early as you can.
But is this really in your control?
You can only see that which you can see, right? Unexpected complications are called “unexpected” complications, because they’re unexpected, right?
Well, that’s true. But so is the following rule:
RULE #3: Others can anticipate complications you cannot.
In general, a group of people will anticipate more complications a single person. And the smarter the individuals, and more diverse the group — and especially the more diverse the group — the better.
Whenever I create software, I use it in ways that match my personality and my life. I craft the software so it works for me first, and I very quickly have a version that meets my own standards. Whenever I show early versions of the software to others, however, they typically have different ways of doing things, and will uncover glitches or awkward features I would have never been bothered by, because I would never have tried to use the software the way they did.
So it’s good for me to get outside perspectives on my work. And if I can get this feedback early, it can save a lot of work.
It’s also useful in this case to get a wide variety of feedback. If I get feedback from just one person, it will be better than having just my own perspective. But, if I can get several people to provide feedback, each with their own personality and way of approaching the world, I will learn a lot more.
As far as discovering unexpected complications goes, to the degree we can expose our creative projects to a diverse set of critical eyes early and often, we are better off. (Though, you will also create some social anxiety as you have to weigh people’s suggestions and decide which ones to act on, and which ones you won’t act on — so it’s not necessarily better in every respect).
It would be natural at this point to conclude, then, that the ideal would be to have the whole world watching your every move and giving feedback along the way. However, as with everything, there are trade-offs here.
Here are some issues we need to address going forward:
- What’s the ideal set of people to give you feedback?
- What should you present for review?
- How often should you present a version for review?
In the next post, we’ll take a look at how Agile and SCRUM practitioners answer these questions with team programming projects.
Then we’ll consider how to approach these questions for creative individuals.
P.S. In the comments section, feel free to ask questions, or share ways in which you might already go about getting feedback along the way when working on big projects.
P.P.S. I’m not the only one in the blogosphere musing about the problems creative individuals face with big projects. This post by David Seah is worth a read.