Practical reflection techniques building on deliberate reflection for enterprise architects and technology leaders

In Deliberate Reflection in Technology Leadership, I explored why intentional pauses matter in a profession that rewards speed. This post takes that idea further, into the physical (or digital) practice of structured journaling as a tool for navigating complex problems.

Not journaling as therapy or journaling as productivity theatre, but journaling as a cognitive instrument. A way to extend your working memory, surface hidden assumptions and convert scattered experience into transferable insight.

Why Architects Need Notebooks

Enterprise Architects operate at the intersection of ambiguity and consequence. We make decisions with incomplete information, across multiple domains, under time pressure, with effects that compound over years. The cognitive demands are immense.

Here’s the problem: working memory is brutally limited. John Sweller’s Cognitive Load Theory, developed in the late 1980s, established that human working memory can hold only a handful of elements simultaneously. When we try to juggle complex architectural trade-offs purely in our heads, we inevitably drop threads, miss connections and default to familiar patterns rather than discovering novel solutions.

“Cognitive capacity in working memory is limited, so that if a learning task requires too much capacity, learning will be hampered.”
—Source: Cognitive Load Theory

Picking up a pen and writing externalises thought (also typing in an electronic notebook counts). It moves elements from constrained working memory onto an unlimited external surface where they can be rearranged, connected, challenged and revisited. The notebook becomes an extension of cognition, not a record of thinking, but a medium for thinking.

Leonardo da Vinci understood this instinctively. His 13,000 pages of notebooks weren’t documentation, they were his thinking process and designs made visible.

“The Renaissance genius made thousands of notes, doodles, and drawings throughout his life that reveal the unique thought process behind many of his ideas and inventions.” Source: National Geographic

A single page of Leonardo’s notebooks might contain an anatomical sketch, a mathematical diagram, a mechanism design and a shopping list, all without clear boundaries. This wasn’t disorder, it was a mind working across domains simultaneously, using the page as a space for unexpected connections to emerge. (Discovering Davinci)

For Enterprise Architects, the notebook serves the same purpose, a space where the technical, organisational, financial and the human can coexist on a single surface. Revealing patterns invisible when each domain is considered in isolation.

The Science of Reflective Practice

The theoretical foundation for structured journaling in professional practice comes from Donald Schön’s seminal work, The Reflective Practitioner: How Professionals Think in Action (1983). Schön examined five professions (engineering, architecture, management, psychotherapy and town planning) and found that the best practitioners engage in what he called reflection-in-action and reflection-on-action.

“Reflective practice is the capacity to reflect on action so as to engage in a process of continuous learning.” Source: Faculty Leadership, eCampus Ontario

• Reflection-in-action is thinking while doing. The architect who notices something unexpected during a design review and adjusts their approach in real time.
• Reflection-on-action is thinking after doing. The structured review that converts experience into learning.

Schön’s key insight was that competent professionals possess vast tacit knowledge, they “know more than they can put into words“. The notebook is the tool that makes tacit knowledge explicit, available for examination and refinement.

David Kolb’s Experiential Learning Cycle (1984) provides the mechanism. Learning, Kolb argued, is a continuous cycle through four stages:

1. Concrete Experience: Something happens
2. Reflective Observation: You think about what happened
3. Abstract Conceptualisation: You form principles or models
4. Active Experimentation: You test those models in practice

The notebook is where stages two and three happen. Without it, most professionals cycle between experience and experimentation (doing and doing more) without the reflective pause that converts activity into genuine learning.

Five Notebook Techniques for Complex Problem Solving

Drawing from reflective practice research, engineering notebook traditions and my own experience in Enterprise Architecture, here are five structured techniques that transform a blank page into a problem-solving instrument.

1. The Problem Decomposition Page

Complex problems resist direct attack. They need to be broken apart before they can be understood. This technique provides a structured format for decomposition.

Format:

DATE: [date]
PROBLEM STATEMENT: [one sentence]
WHAT I KNOW
• [fact]
• [fact]
• [constraint]
WHAT I DON'T KNOW
• [uncertainty]
• [assumption to validate]
• [missing information]
WHAT I THINK I KNOW (BUT MIGHT BE WRONG)
• [belief to challenge]
• [inherited assumption]
• [pattern match from different context]
SUB-PROBLEMS
1. [decomposed element]
2. [decomposed element]
3. [decomposed element]
NEXT ACTION: [single next step]

This technique draws directly from Richard Feynman’s notebook practice. As Get Alfred describes:

“Feynman kept notebooks throughout his career, not for storage but for testing. When he encountered a concept he could not explain clearly, he treated that inability as information: it meant the concept was not actually understood.” Source: Get Alfred

The critical section is “What I Think I Know (But Might Be Wrong)”, the space where inherited assumptions, pattern matches from different contexts, and organisational folklore get surfaced and challenged. In enterprise architecture, these unexamined beliefs are often the source of the most expensive mistakes.

In 2002, U.S. Secretary of Defense Donald Rumsfeld offered what became one of the most quoted frameworks for thinking about uncertainty.

“There are known knowns, things we know we know. There are known unknowns, things we know we don’t know. But there are also unknown unknowns , the ones we don’t know we don’t know.” Source: U.S. Secretary of Defense Donald Rumsfeld

Widely ridiculed at the time, the taxonomy has since been adopted across risk management, strategic planning and enterprise architecture as a deceptively simple model for categorising what we understand, what we acknowledge we don’t, and ( most dangerously) what we haven’t even thought to question.

2. The Decision Journal

Every significant architectural decision deserves a journal entry — written before the decision is finalised, not after. This creates a record of your reasoning that can be reviewed when consequences materialise.

Format:

DATE: [date]
DECISION: [what you're deciding]
CONTEXT: [why this decision is needed now]
OPTIONS CONSIDERED:
1. [option] [key trade-off]
2. [option] [key trade-off]
3. [option] [key trade-off]
MY REASONING:
[Why I'm leaning toward option X. What mental models
am I applying? What analogies am I drawing from?]
WHAT COULD MAKE ME WRONG:
[Pre-mortem: If this decision fails in 18 months,
what's the most likely reason?]
CONFIDENCE LEVEL: [High / Medium / Low]
REVERSIBILITY: [Easy / Moderate / Difficult]
REVIEW DATE: [when to revisit this entry]

The power of the decision journal lies in the review. When you return to an entry six months later, you can see whether your reasoning was sound, whether you identified the right risks, and (crucially) whether your confidence level was calibrated. Over time, this builds genuine self knowledge about where your judgment is reliable and where it tends to fail.

This connects directly to the practice of Architecture Decision Records (ADRs), which provide a structured way to capture the context, reasoning, and consequences of architectural decisions.

The decision journal is the personal complement to the organisational ADR by capturing not just what was decided, but how you thought about it.

3. The Gibbs Reflection Entry

When something goes wrong (or unexpectedly right) a structured reflection prevents the experience from being lost. Graham Gibbs published his Reflective Cycle in 1988 and it remains one of the most practical frameworks for learning from experience.

The six stages:

DATE: [date]
EVENT: [brief title]
1. DESCRIPTION: What happened?
   [Facts only. No interpretation yet.]
2. FEELINGS: What was I thinking and feeling?
   [Emotional state, stress level, confidence]
3. EVALUATION: What went well? What didn't?
   [Balanced assessment]
4. ANALYSIS: Why did things happen this way?
   [Root causes, contributing factors, context]
5. CONCLUSION: What have I learned?
   [Principles, patterns, insights]
6. ACTION PLAN: What will I do differently?
   [Specific, actionable changes]

“It’s particularly useful for helping people learn from situations that they experience regularly, especially when these don’t go well.”
Source: MindTools, Gibbs’ Reflective Cycle

For architects, this technique is invaluable after architecture review boards, stakeholder presentations, failed deployments or governance decisions that produced unexpected outcomes. The discipline of separating description from evaluation from analysis prevents the common trap of jumping straight to conclusions without understanding causes.

4. The After-Action Review (AAR) Page

Borrowed from the United States Army, the After-Action Review. Developed in the 1970s, it has since been adopted by organisations worldwide for performance assessment and learning.

The AAR asks four deceptively simple questions:

DATE: [date]
EVENT/PROJECT: [what was completed]
1. WHAT DID WE INTEND TO HAPPEN?
   [Original objectives, success criteria, plan]
2. WHAT ACTUALLY HAPPENED?
   [Factual account. No blame, no justification]
3. WHY WAS THERE A DIFFERENCE?
   [Root cause analysis of gaps between 1 and 2]
4. WHAT WILL WE DO DIFFERENTLY NEXT TIME?
   [Specific improvements to carry forward]

“An AAR is distinct from a de-brief in that it begins with a clear comparison of intended versus actual results achieved.”
Source: Wikipedia, After-Action Review

The genius of the AAR is its insistence on starting with intent. Most post-mortems begin with “what went wrong?”, which presupposes failure and triggers defensiveness.

The AAR begins with “what did we plan?”, which creates a neutral space for examining variance in either direction.

For the architect’s notebook, use a personal AAR after every significant engagement: a strategy presentation, a design authority session, a vendor evaluation, a transformation milestone. The cumulative effect over months is a personal knowledge base of what works, what doesn’t, and why.

5. The Connections Page

This is the most creative technique and the one closest to Leonardo’s practice. It’s deliberately unstructured, designed to surface unexpected connections between disparate problems, domains or ideas.

Format:

DATE: [date]
SEED: [a problem, observation or question]
WHAT DOES THIS REMIND ME OF?
• [analogy from different domain]
• [similar pattern elsewhere]
• [historical precedent]
WHAT IF...?
• [inversion: what if the opposite were true?]
• [scale: what if this were 10x bigger/smaller?]
• [time: what if we had 10 years / 10 days?]
UNEXPECTED LINKS:
• [connection to another current problem]
• [connection to something I read recently]
• [connection to a conversation this week]
SKETCH/DIAGRAM:
[free-form visual, boxes, arrows, clusters]

Leonardo’s method was to “observe closely; draw what you see (not what you think you see); write down questions; look for connections to other things”. He called this saper vedere , “knowing how to see.”

The Connections Page works because complex problems rarely yield to direct analysis alone. They yield to analogical reasoning, seeing that a supply chain problem has the same structure as a network routing problem, or that an organisational resistance pattern mirrors a thermodynamic equilibrium. The page gives these connections a place to land.

Building the Habit: Practical Implementation

Knowing the techniques is insufficient. The challenge is building a sustainable practice. Here’s what I’ve found works:

Timing

• Morning (10 minutes): Review yesterday’s entries. Set intention for today’s key decision or problem.
• Transition moments (5 minutes): After meetings, reviews, or significant conversations, capture while fresh.
• Weekly (30 minutes): Review the week’s entries. Look for patterns. Write a Connections Page.

“Journaling allows you to observe and analyze your thinking in a way that no other feedback tool can match. By putting your thoughts on paper, you can see how you approach a situation, frame the context, process the information, and make decisions.” Source: Inc. Magazine

Medium

The debate between analogue and digital is personal. What matters is friction, the right amount.

• Analogue advantages: Forces slower thinking. No notifications. Spatial freedom for diagrams. Tactile engagement that many executives prefer because “the tactile process slows the mind, reduces distractions, and invites deeper focus.” Source: REF Global
• Digital advantages: Searchable. Linkable. Portable. Integrates with ADRs and team documentation. Allows tagging and cross-referencing across entries.

My recommendation: use analogue for the thinking (Problem Decomposition, Connections Pages) and digital for the recording (Decision Journals, AARs) that you’ll want to search and reference later.

Minimum Viable Practice

If five techniques feel overwhelming, start with one: the Decision Journal. It requires the least time, produces the most immediate value, and builds the reflective muscle that makes the other techniques natural over time.

Write one entry before your next significant decision. Set a calendar reminder to review it in three months. That single loop (decide, record reasoning, review outcome) will teach you more about your own judgment than years of unreflected experience.

Connecting to Enterprise Architecture Practice

The architect’s notebook isn’t separate from professional practice , it is professional practice, made visible. Here’s how it integrates:

• Architecture Decision Records: Your Decision Journal entries become the raw material for formal ADRs. The personal reflection captures nuance and uncertainty that organisational documentation often sanitises away.
• Governance and Assurance: As I explored in How Architecture Supports Regulatory Confidence Without Slowing Delivery, effective governance requires visibility of reasoning, not just outcomes. The notebook provides that reasoning trail.
• Risk Assessment: The STORMWATCH method I developed for risk assessment benefits enormously from notebook based reflection. Writing through each risk dimension forces deeper analysis than a checklist approach.
• Optionality: In Designing for Optionality in Enterprise Architecture, I argued for preserving future choices. The Connections Page is where you discover options you didn’t know existed, by seeing patterns across problems that reveal alternative paths.
• Mental Models : In Mental Models Every Enterprise Architect Should Know, I catalogued the cognitive frameworks architects use. The notebook is where you practice applying those models, where inversion, second-order thinking and systems mapping move from theory to instinct.

The Compound Effect of Structured Reflection

A single notebook entry has modest value. A year of entries has transformative value. The compound effect works through three mechanisms:

• Pattern Recognition: After many Decision Journal entries, you begin to see your own cognitive biases in action. You notice which types of decisions you’re consistently overconfident about. You see which risks you habitually underweight. This meta awareness is the foundation of expert judgment.
• Institutional Memory: Your notebook becomes a personal knowledge base. When you face a problem similar to one you solved eighteen months ago, the entry is there, not just the solution, but the reasoning, the alternatives considered and the lessons learned.
• Deliberate Development: As Kolb’s cycle predicts, the combination of experience and structured reflection produces learning that experience alone cannot. Each entry is a micro-cycle of the experiential learning process (concrete experience, reflective observation, abstract conceptualisation) compressed into a single page.

Starting Today

The architect’s notebook is not a productivity system. It’s not a task manager or a project tracker. It’s a thinking tool, a space where complex problems get smaller, where tacit knowledge becomes explicit and where scattered experience crystallises into transferable wisdom.

You don’t need a special notebook. You don’t need a perfect system. You need a page, a pen (or a screen) and the discipline to pause (even briefly) between experiencing and acting.

As Schön observed, the best professionals know more than they can articulate. The notebook is how you close that gap, how you surface what you know, challenge what you assume, and build the reflective practice that separates competent architects from exceptional ones.

Start with your next decision. Write down what you’re choosing, why, and what could make you wrong. Date it. Set a reminder to review it. And watch how the simple act of writing transforms the quality of your thinking.

References & Further Reading

• The Reflective Practitioner: How Professionals Think in Action. Routledge. – Schön, D. (1983)
• Experiential Learning: Experience as the Source of Learning and Development – Kolb, D. (1984)
• Cognitive Load Theory, Educational Research, and Instructional Design – Educational Technology Research and Development
• Learning by Doing: A Guide to Teaching and Learning Methods. – Gibbs, G. (1988)
• The window into Leonardo da Vinci’s creativity? His sketchbooks – National Geographic
• The Notebooks & Method, Leonardo’s Inventions – DiscoveringDaVinci.com
• Observation Journal, Education Activities – DiscoveringDaVinci.com
• The Feynman Technique: Why If You Can’t Explain It Simply, You Don’t Understand It – Get Alfred. (2026)
• After-Action Review – Wikipedia
• Architecture Decision Records: A Practical Guide – Paulund. (2026)
• Journaling Is a Core Practice for Leadership Development- Inc. Magazine.
• Executive Journaling: The Underestimated Habit of High-Performing Leaders.- REF Global. (2025)
• Using a Structured Approach to Reflective Journaling in Engineering Leadership Development – ASEE. (2021)