Ya’ll, I have to tell you about the MOST unbelievably effective practice I’ve started.
Tear downs.
Now, my language-sensitive readers might have a bit of a problem with the wording here. Tear-down sounds so negative! So do some of the other names for the process, like post-mortem, or debriefing.
But the main point is to analyze your completed projects, regardless of the actual outcome.
In particular, I’ve taken to analysing projects that aren’t completable in a week, as part of my weekly review.
Doing this is a crucial way for me to assess what needs to be done yet, and whether the project is still worth my continued effort.
This is the template I use:
Name of the Project:
Completed?
- If yes, recurring?
- If yes, do optimization procedure
- If no, archived? Summarize for documentation binder with links to supporting material
- If no,
- What’s been accomplished to date? Is there a deadline?
- Where is it going?
- What will be the benefit?
- How does this tie into the overall system?
- Notes/Thoughts
Analysis:
- What’s smart about this? What’s dumb?
- Where’s the bottleneck? The inefficiencies?
- Where’s the particularly elegant or clever solution?
- What have other people overlooked about this problem? What am I overlooking?
- What’s the underlying system? (How would you teach this to others?)
Now, each of these questions is nothing special in and of itself, but as a whole it leads to cohesive, strategic, executive thinking. It takes you out of the doing mode and prompts you to figure out how to do things better.
It’s incredibly effective and is well worth the time I spend on it.
Why?
Because if you spend your days simply doing things, you’re essentially just doing the bare minimum. Even if you tell yourself that’s all you can do, there’s an immense amount of leverage to be gained from the practice of analysis:
- Taking the time to note what worked and what didn’t in a systematic manner means that you’re going to be that much faster working out similar problems, and that over time, you’re going to refine that knowledge and become extremely adept. This is similar to the concept of deliberate practice.
- Some problems only need to be fixed once in a long while, and the incidents are so few and far between that you pretty much have to reteach yourself every time. Like replacing the toner in the printer. Documentation is your friend! This is similar to documenting bug fixes in tech support.
- Sometimes you’re doing something that sounded like a good idea at the time, and you didn’t think through whether it was really necessary or not. This will solve that problem before you put too much work in.
- You need a win. It’s awesome to be able to pat yourself on the back for a job well done, particularly if it was an elegant solution. You should take note of these occasions if you have a job with a review process, hope to ask fora raise one day, or have occasion to market yourself. So, basically everybody.
I know these bloodless articles are never enough to really persuade a person to do what seems like a lot of extra work for marginal benefit. So instead, a challenge: try it for just two weeks.
See if a ritual teardown doesn’t actually give you a tremendous feeling of accomplishment, control and a template for doing things better next time.
[ssbp]
