Over the last few years, for almost all tasks and communications, I used the SCR framework (Situation-Complication-Resolution):
- Situation: A factual description of the current situation.
- Complication: The reason why the situation requires action. What’s the problem (or opportunity)?
- Resolution: What do we need to do to resolve this complication (or seize the opportunity)? Its strengths are universality, simplicity, and built-in context. It’s easy to roll out and monitor execution.
We need a small digression here. Any platform team has 3 sources of tasks (and even more types): tasks from product teams, platform support/development tasks, and incidents. And they differ a lot:
- incidents: urgent tasks that usually don’t have a solution at the initial stage
- platform operations tasks: short and assume ready-made solutions in the form of runbooks and automation in the form of scripts
- platform development tasks: often require R&D to build possible solutions, last long, and work well through describing the problem being solved or the desired outcome
- product team tasks: set by people who don’t know how their tasks will be solved, plus verifiability is important to avoid misunderstandings
And from the properties of platform team tasks come the cons of SCR:
- you can’t validate the result with it
- for not all tasks can you fill in “resolution” at creation time
- you often have to fill it in from the middle, because the “situation” has to be described depending on what’s written in “complication” to give all the necessary context but not write too much. And sometimes there is no point in describing “situation” at all, because everyone understands everything. The last two downsides are minor, but there’s really a lack of something like DoD.
So while I’m resting, I decided to make another pass and see what else has been invented over the last few years. And it’s kind of sad. All these PAS, STAR, What-So What-Now What and other 5W1H fit our tasks no better than SCR and GOS (Goal-Obstacle-Solution), which I used earlier.
We and o3-mini-high made our own framework — G.O.D.S: Goal, Overview, Definition of Done, Solution. I should, of course, make a nice website. But I don’t think I’ll be able to popularize it. I’m not McKinsey, after all, who developed SCR. But I’ll try using it in future projects.