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 and diagrams only!
- Log the result; actual implementation or following up is not required.
It sounds simplistic, but so far these workshops have always been fun, intense, and uniquely rewarding. We discuss project requirements, architectural constraints, and dive into existing systems and code to understand how the given project could fit in:
- What data needs to be gathered and processed?
- What system components need to be changed, in what order?
- What trade-offs do we need to make based on known constraints?
- What difficulties, risks, and second-order effects can we anticipate?
- How might we find answers to open questions?
Working these kind of questions in the context of a real system we’re familiar with, but without the pressure to implement or report, provides a frame just right for learning and knowledge building. Groups are often a mix of experts and active listeners of any level; that way, anyone can get exposure, but the group can always make good progress.
Besides leveling up the team, I’m seeing some additional positive effects:
- Increased estimation quality
- Increased domain knowledge
- Deeper understanding of our own systems
- Reduced barrier to tackle difficult technical migrations
Best of all, features which were considered “impossible” before became tangible through outlining, and some have made it into production!
Here are some more practical tips and tricks for outlining sessions:
- Use the outline as a “working memory” for the group. Start with a blank page, then write down notes, thoughts and open questions as you go, even if you resolve them later. That way, you can park items mentally and revisit them later.
- Work the subject breadth-first, i.e. start on a high level and only go deeper as time allows.
- Do not remove incomplete items when closing the session, as they can provide valuable insights.
Happy outlining! ∎