The one lesson I’ve learned over two decades and a bit of project work: good briefings = good outcomes, bad briefings = bad outcomes/failure. It’s not the only factor, but a massively important one. As no one wants bad outcomes (take it), it’s surprising how many briefings fall short. Esp. as it can be avoided w/out much mental bandwidth. In this post, I’ve put together “my” template - hoping that it’s useful.

First question I did ask myself is: “Why are details not enough?” Everyone living (or rather suffering) through a ticket-based workstyle can probably relate: sth is missing and that sth is context. There are a thousand little micro-decisions in every dev effort - and devs can get them right or wrong. I’d argue the odds for right improve quite dramatically with more context - i.e. a good briefing. A little more than 200 years ago, Clausewitz stressed aspects like objective, will and friction in On War (highly recommended read btw). And as “there was nothing new under the sun” (J. Mattis, Call Sign Chaos - another highly recommended read), every project today can benefit.

Yet at the same time, winging it rarely cuts it. And it takes up a lot of mental bandwith.

So: here’s my stab at a template to create briefings

  • quickly (it’s not about writing a PhD thesis!)
  • in high quality (i.e. presentable)
  • with little mental bandwith needed
  • that are useful for everyone in the team along the way

You can be the the judge of whether I succeeded of course - I tried to condense some good reading into my take:

  • Major Account Sales Strategy by Neil Rackham - a great guide on finding objectives and helping in achieving them
  • the Rational Unified Process - a template set (with many variations) that just helps in asking the right questions. You can find old(er) versions online by searching for “RUP templates”; there is also a Summary on StackExchange.
  • Code Complete and the Software Project Survivial Guide by Steve McConnell
  • agile practices that work
  • the concept of Customer Journey (or Employee Journey or any journey, really)
  • The Silo Effect by Gillian Tett (Editor at the FT) on the importance of connecting the dots
  • Amazon’s policy on written briefings - see e.g. in this video
  • and many, many more (a reading list would be a separate topic, really)

The template

Anyhow: here’s my take as in a template to fill by asking important questions:

Get a lay of the land

Describe the current Situation

Describe what’s not OK with it

Describe the consequence of not acting

First possible solution

Quick summary of the solution

Steps the user / customer goes through (journey; bullets / chevron diagram)

Concrete walkthrough (no generic terms, name customers and products)

Implementation details

Second possible solution

Quick summary of the solution

Steps the user / customer goes through (journey; bullets / chevron diagram)

Concrete walkthrough (no generic terms, name customers and products)

Implementation details

Next steps

Decision - which alternative do we chose

Affected use cases

Affected components in our system

Affected systems outside our control

Next steps from here

(that’s it)

Some notes on usage

The most important part is the first part (Getting a lay of the land) - and that should not take longer than 10 minutes. If you only have 10 minutes, that’s the one. Still, spending some more time (an hour tops) on laying out the solution proved powerful to me. All-in-all, even with little time involved, you might get a lot more clarity for everyone. Plus: it’s time you don’t have to spend explaining over and over again.

Wrap-up

As ever: I hope this helps you a little and you found this useful. Sure lmk what you think!