Reflections on my most recent postmortem
Looking forward by looking back
Dorm Room Fund wrapped up its recruiting and selection process this week.
I’m absolutely ecstatic about my new teammates and colleagues!
The process itself was very fun for me, and I learned a lot from it.
To preserve the lessons I learned this year for both the fund’s leadership and next year’s student leadership team, I just finished writing a postmortem report with my team’s other Managing Partner.
It’s technically a project retrospective in that it points out both positive and negative characteristics of the recruiting and selection process we ran, but “postmortem” was the term I used in engineering (where a “retrospective” was a meeting about a how a sprint [a discrete time period where the engineering team worked on specific tasks] went) so I’m sticking with it.
The second element of Stephen Covey’s The 7 Habits of Highly Effective People is to “begin with the end in mind.” That’s easy to understand on as grand a project as life as he initially presents it, but somewhat more difficult to make a habit at a more…atomic level.
Perhaps more critically, actually benefitting from the concept over time requires regularly tracking performance to goals, and identifying what to change going forward. That’s one of the things that I aimed to capture.
I’ve heard from both founders and very early-stage employees that there’s a general concern in many startups over documentation. It takes precious time to create, and even more time to consume. In a professional universe where the modus operandi is “move fast and break things”, sometimes combined with “do things that don’t scale”, that often doesn’t seem like a valuable use of time.
But I agree with Covey it is incredibly useful.
I’ve also heard that some (though not all) VCs that describe themselves as “operating like startups” share this problem — which is fascinating to me. It is intriguing because it suggests that some of these investors either may not apply the same rigor they want founders to apply with respect to their business, or they apply it and come to different conclusions.
It’s a surprising failure mode for decision analysis ex post facto because VCs do this sort of thing a priori all the time. Crafting investment memos to document the rationale for committing to a startup is as consensus behavior as I’ve ever heard about among the investors I’ve spoken with. It’s nearly universal!
My impression is that documenting failures and their root causes is not nearly as common a practice.
To learn from the past, it’s important to establish a record of what happened. While a retrospective meeting might help establish clarity between team members about a particular sequence of events:
agreement on the sequence may be impacted by institutional politics, and as such may not reflect what actually happened
consensus and lessons learned may not remain in the minds of the team as its composition changes
the memories of what happened will not endure over time unless recorded somewhere
A written report can’t fix the first issue, but it could be quite helpful in addressing the second two possibilities.
I believe that this is important to do specifically as an early-career VC not only to become better at identifying startups with the potential to become fund returners early, but also to give better advice and suggestions to people who ask for it.
This isn’t unique to engineering or investing. There’s similar processes to blamelessly review and learn from events in medicine, aviation, and IT as well.
Our document’s structure
Introduction
Top of Funnel Data
Plots breaking down the top of the selection funnel by various categories
Team Sentiments
Anonymous commenting was an option
Did we achieve our goals?
Goals from team leadership — 2 items
Goals from higher fund leadership — 7 items
Process Improvement Suggestions
Start — 15 items
Stop — 6 items
Continue — 3 items
Conclusion
My goals in this structure were, first, to mix qualitative and quantitative data in our document. I also wanted us to contextualize our visions for what might be improved upon next year in the places where we felt we didn’t perform outstandingly this year.
I would have liked to include a timeline of important events in the document. This wound up getting cut for two reasons:
Lack of time — we’ve got to prioritize onboarding our new colleagues and training them.
More importantly, nothing went particularly wrong. There’s lots of ways we could do better, but this is a postmortem report of a project that DRF did quite well at and recently wrapped up — not a discussion of some sort of critical incident or anomaly.
Particularly as a result of the second point, establishing a timeline or narrative sequence isn’t nearly as essential to running this process better in the future.
Some errors are unavoidable. My goals in writing and reading postmortem reports are to:
minimize the number of mistakes I make
learn from each mistake
make a mistake only once
help others avoid the mistakes I make