Sketchplanations
Sketchplanations podcast photo of Rob Bell, Tom Pellereau and Jono Hey

Prefer to listen?
Try the podcast

Sketchplanations is ad-free
thanks to supporters like you.
See more on Patreon

Cake wreck

Cake wreck: a cake where instructions for the cake—"Happy birthday in purple, no nuts"—have been smartly written across the front. Intended as a metaphor for literal misinterpretation.

Cake Wrecks is the blog and book of when professional cakes go hilariously wrong, by Jen Yates. But a cake wreck is also a useful metaphor for how easy it can be to misinterpret instructions—often by simply taking something literally when it was expected to be interpreted. Examples from Jen's collection include a smart-looking cake with "Nothing" written across the front, a graduation cake with "I want sprinkles" next to a graduation cap, or a cake sporting a full "Happy birthday on a gluten-free cake." If you haven't seen them, you could do much worse than look some up now . It's easy to laugh at these examples, but it's also easy to find real examples in day-to-day work.

I learned about cake wrecks from Jeff Patton's excellent book User Story Mapping . He gives cake wrecks as an all too common example of communication in software development. For example, a user story or specification for a feature is written and passed on to developers who, in the absence of other communication and with perhaps cultural or status barriers, may carefully build exactly what is written rather than what the writer intended. Cake wrecks are funny and silly—except if it was for your special occasion—but mistakes in projects are expensive in time, money and relationships and are worth avoiding.

The recipe for avoiding a cake wreck is, in principle, simple:

  • Communicate more
  • Don't assume that what you see is what someone else will see
  • Share richly
  • Use stories and specifications as tools for talking about what's needed and not as equivalents of it
  • Create a safe space for everyone to question what they don't understand or don't agree with
  • Give everyone the 'why' behind a project and autonomy and flexibility to suggest other ways to meet the goal
  • Check in during a project and adjust as needed

Apron?

Published
Buy Me A Coffee