9 Comments

I'm a big fan of these takeaways:

> Assess risks: list as many potential risks as we can and use a proper margin of safety to handle them.

> Run pre-mortem sessions: imagine our project has failed and learn from this hypothetical situation.

I also use ChatGPT to help me with this. The 4o model is a lot better than past ones. I tell it to act like a Principal Engineer and come up with as many risks and things that can go wrong as possible. Even if it doesn't know about the internals of your system, what it comes up with is helpful as a jumping off point.

Thanks for this article and the shout-out, Michał!

Expand full comment

Well-deserved shout-out, it is a great article, Jordan!

Expand full comment

Great approach to risk assessment and running pre-mortem sessions! Using ChatGPT sounds like a creative way to generate potential risks. Keep up the good work!

Expand full comment

There are lessons learned from the Software Engineering books of "ye old days", the one that jumps to mind here is never give a point estimate. Always give a range. When the stakeholder/customer gets a range they don't fixate as much on the low or high, rather they ask "Why?" Then you have their attention to discuss risks, assumptions and known unknowns.

Expand full comment

That is a great perspective. Thank you for sharing, Don Gilman!

I had an experience with clients being too attached to optimistic (lower range) estimations, but it was a good starting point for discussion.

Expand full comment

Facing the biggest unknowns early on was the biggest lesson I learned the hard way. I have a different approach now: when I feel the need to procrastinate an aspect of the project for fear of discovering something, I force myself to attack it first.

Never thought about pre-mortems. Going to look into it further

Expand full comment

This is a great strategy to focus on uncovering unknowns.

Thanks for sharing your perspective, Simone!

Expand full comment

Pre-mortems are heavily underappreciated. I haven't seen teams running them often enough. My team is guilty of the same :) In our most recent post-mortem, one of the learnings was to start having pre-mortems for large releases. Dedicating just an hour of the team's time can prevent days of problem-fighting further down the line.

Thank you for the shoutout, Michal! I appreciate it.

Expand full comment

It might be easier for our brains to learn from what happened in the past than to think about many possible futures. (that's why we favour post-mortems, rather than pre-mortems)

Well done, Samuel. It's a great article.

Expand full comment