Retrospections Over Evaluation #

In any company at any size there is, or should be, a time for review. Even when there is only one employee, you. And I would suggest that this is a good practice even at a personal level.

More of often than not, reviewing the current state of affairs is a process that looks like a grading a paper in school. Someone takes the time to look at the current situation and grades it with either “Exceeded expectations”, “Met expectations”, “Failed to meet expectations”. And on they go to the next thing on their todo list.

While this method works in school, where the assignments are based on the same learning materials for everyone and the only variable is how much effort an individual puts into learning, it fails big time for any evaluating any kind of work that any degree of uncertainty. And the more uncertain the work, the more this evaluation based review fails because it only evaluates the end result. 

With increasing uncertainty in the work requirements you have to spend more time understanding the context in which the work got done. For this kind of work, the process through which it got done is far more important than the end result. Although low, there is a chance that someone got lucky and reached a good end result but is unable to reproduce similar results in similar conditions again. Grading this situation with “exceeds expectations” means that someone will get to move higher up where work is even more uncertain. Doing so without attempting to reduce the luck factor to the minimum is a bad idea.

Retrospections take into consideration a wider range of things that contribute to the ultimate success inviting a review of all events, if we got them right or not, assessing if we are on a good trajectory or not, helps us determine if the project is worth the effort and ultimately determine with we are able to reproduce our successes or if it was a one time lucky shot.

At an individual level, the discovery process, ideation, feedback integration. Being humble enough to iterate through ideas even when it means discarding their own ones. When faced with multiple choices, how much risk did they took, was it justified? Can they take difficult decisions like dropping the project if that is the right move? When faced with hard problems, do they try to solve them or just wait for guidance? How good are they at organizing their own work when priorities shift? 

At a team level, the way they communicate, not being single minded on personal objectives, the willingness to adapt to the team needs as the project evolves. 

At an organization level, you might find out that the way teams are structured is not compatible with the pace you want to have, there are conflicting interests on how goals are set which hinders collaboration between teams, the load that new work bears on some teams is downplayed.

These are just a few examples of all the things that are part of the process which are more important than the end result when evaluating uncertain work because that process is how the uncertainty is reduced to the minimum while also factoring luck out as much as possible.

In order to get all these above mentioned things right, you have to retrospect on what happened and how did it happen. This process takes time and willingness to dig deep and deeper to get an image as accurate as possible of what happened. It also takes energy to absorb, process and distill all that happened in the context of the project.

To circumvent all this hard work, many revert back to reviewing and grading the end result in the same fashion their teachers did in school. This is the reason why many projects get done as close to the periodical review inside the company. It is easy to forget the importance and hard work that went into a project from last quarter or to diminish its relevance when compared with a project that got done last week as the problems in the now are far more important than problems solved in the past. 

In an attempt to reduce the amount of work, metrics are introduced about every aspect of the job that can be easily measured. In the software world, people try to measure the tangible things like lines of code, comments on code reviews, how often you commit your code which are by-products of the intangible work that went into it like problem solving, analyzing trade-offs, picking the solution that’s right for the project but not for the ego. These are a few examples of what can be measured and at the same time gamified to look very good on paper and yet they don’t provide an accurate measurement of reality.

This avoidance of doing the hard work and the attempt to make the review process as objective as possible is why big companies have so many people in the wrong position. In attempting to make the process as impersonal and objective as possible, the reviewers lose all the context above mentioned and miss all the improvement opportunities that there are which causes the entire system to degrade over time and ultimately collapse under its own weight.

Taking the time to do proper retrospections in order to get a picture of the reality as accurate as possible is the only viable way to find out which are the real issues within the system and to apply the right corrective measures to sustain a healthy, functioning system over time. It is the only viable alternative if you care about long term sustainability anyway. 

Retrospecting, as often as possible, to learn the context in which the decisions were made is the best chance you can give someone to a fair review.