Chris Wu


We've all been part of projects that didn't go well. Despite our best efforts project often go wrong: poor decisions, bad relationship management or just bad timing. To this day, I don't understand how companies still don't have rigorous standards for retrospecting on both successful and unsuccessful projects. I say standards here because the process itself is irrelevant so long as the root cause it reached. I don't think I can express how hard this can be for an organization better than Hess.

When pressed on the issue most people don't deny that retrospection is important but present excuses or tactics that delay or outright stop the process. As we know, delaying anything decreases a human's ability to recall facts.

So what are these issues?

It's in the past

This argument touches on the basic discomfort people have with reflecting on painful events. It posits, usually implicitly, that looking back on painful events doesn't serve any purpose since what has been done can't be undone.

The issue with this is that it's patently false. Examining issues in projects and process are great opportunity to see what assumptions and decisions were incorrect. This leads to a chance to prevent those errors a second time.

Further, retrospection doesn't always mean that the conclusion will be negative. It is conceivable that given the assumptions known at the time, all parties made the correct decisions - it does happen!

Everyone did the best they could

This argument is dangerous because it starts by setting the context for discussion as "the competence of those involved". As such it's good to clarify at the start that we're not critiquing the intent or competence of the actors but the actions within the context.

Like the helicopter parent, an overly protective environment that robs people of learning opportunities under the guise of ego preservation is very dangerous. Managers who allows this are essentially saying their employees, and possibly themselves, are unwilling to look bad and would rather look ignorant instead.

The Blame Game

Don't think this

Blame carries such a negative connotation that the above is all people think about when they hear it. We should change the discussion to one of responsibility and to remind people that, ultimately, someone has to be responsible for every action and decision.

I'm also in the camp of people that believe that the culture of "we're all responsible for X" is terrible and fraught with peril. When everyone owns a thing, no one owns it. Witness any group email you've ever received where there are tasks to be done and no clear mandates.

Blame isn't about firing people or making them bear the full brunt of a failure. Rather it's about letting the responsible party know why they were responsible and how they dropped the ball. In the future, if things are done right, they know "ah, this is my responsibility".

Dog and Pony Retros

I've seen this a couple of times too. Though I don't blame Agile methodologies for this, but Agile process has so many tools to deal with retrospecting on things that people just use the tool without understanding them.

Here we have meetings where, ostensibly, we're trying to get to the root cause but for a number of reasons it doesn't happen:

  • Haven't gathered the right data.
  • Don't have the right people in the room: If even one key person is missing then you won't know what information or context is missing.
  • The power gap is too high: If junior project members are intimidated, this squelches conversation.

The Dog and Pony then concludes (figuratively) with "ok, we've been in this room for hours and look at all these post-its. Closure achieved."

So we take the high road, go through the discomfort of honest and brutal feedback, and reach the root cause. Now what? What are the actual gains we're looking for when we retrospect and challenge outselves.

Everyone Learns

If we've effectively found the cause of our problem, now we can start looking for a solution. Avoiding bad stuff is often one of the most productive actions. We have a tendency to try and pick the best choice from a group of alternatives but often every single non-bad choice contains good elements (see Ruth Chang's TED talk for more).

On the other hand, bad choices usually have a very clear bad quality to them. Identifying this bad quality is arguably more helpful than validating a good, but possibly sub-bar, decision.

No Bad Myths

This is an observation I've made over my career which isn't apparently until a fair amount of time has passed on a bad project and that's the project myth.

The birth of the myth goes something like this: The team is composed of various people from various departments - sales, engineering, management, what have you. Projects go south and it's often everyone's fault a little bit: a missed deadling because of bad code, an unrealistic promise made during a deal or perhaps just poor requirements gathering.

Without a deep painful look into the why of the failure, the team just ignores it. However, each member still has their biases and blames some other party for the failure. Without the ability to have a frank and open conversation with all parties, everyone creates their own version of the truth.

"Sales set us up with a bad relationship."

"Engineering's estimates were off."

These cautionary myths breed distrust and destroys company culture. They are doubly dangerous because they are so far removed from the event - often coming to light only months later in discussion - that people have forgotten their true origin.

I can't say that I've been part of any company that gets it right every time but I have experienced some really good retrospective activities. I think every company should decide what works for them but I think that good reviews have common elements:

  • prioritize the root cause and its solution above all else
  • get all parties to agree on facts before discussion
  • are clear about responsibility and blame
  • address power imbalances among the team members so that quieter members aren't steamrolled

At times in the past, I think I took the default mode of thinking "why bother after the fact?" as well. But if true ability to succeed comes from grit, then the only way to build that is to understand our failures and improve on them.