Outlining

I find it difficult to “teach” staff-level software engineering work (system design, technical planning, etc.) as there are no hard and fast rules. On the contrary, it’s about knowing when to break the rules, which requires experience and getting comfortable with ambiguity. These kind of skills are best acquired by working on real projects, with real constraints, and expert guidance. However, those projects are (rightfully) limited; it’s hard to get enough exposure for people in an organization to level up consistently. To fill this gap, I’ve recently started a workshop format for practicing system design and technical planning called outlining. It features a powerful overlap of deliberate practice and real work, and goes like this: Pick (or invent!) a realistic, unplanned project in our context. Find a small group of interested people (3-10 people). Pick a time box (1-2 hours). Meet and work on a rough outline for the given project (tasks, questions, risks, and so on). Bullet points…