# 24. Continuous growth How to develop architectural thinking through systematic reading, incident reviews, writing, mentoring, design reviews, and work against real constraints. - **Author:** Fedor Chishchin - **Level:** advanced - **Reading time:** ~25 minute read - **Published:** 2026-05-23 - **Source:** https://fedorthinks.com/learn/software-architect-24-growth --- ## 1. The core idea Architectural skill comes from repeatable practice: read systems, make decisions, check the consequences, and refine the model of thinking. ### Learn from real systems > A chess player doesn't get stronger by memorizing the names of openings. They get stronger by going through games and mistakes. Books and articles matter, but the architect grows faster by examining real decisions: why the system fell over, why the migration dragged on, why the team picked this API, why this module became hard to change. A useful habit is a decision journal: what was decided, what the assumptions were, what the risks were, the expected outcome, and when to check on it. After a few months it becomes raw material for calibrating your thinking. ### Writing makes thinking verifiable > While the thought is only in your head, it feels clear. On paper, the missing joints show up immediately. The architect should write regularly: ADRs, design notes, migration plans, incident reviews, technical strategy. Writing forces you to name context, constraints, alternatives, and consequences explicitly. Good writing doesn't have to be long. It has to let another engineer pick up the reasoning and keep going. ## 2. Example and anti-example An architect's growth is measured by the quality of the team's decisions, not by the number of technologies they can name. ### Example: an incident review without blame > After an accident, aviation looks at the system: procedures, instruments, training, fatigue, communication. Not just the last person at the panel. The team runs a blameless postmortem: timeline, impact, detection, contributing factors, what went well, action items. The architect looks for systemic improvements: a missing timeout, a weak runbook, an absent alert, a dangerous dependency chain. That way the incident becomes material for the architecture and operations to grow. ### Anti-example: collecting technologies instead of judgment > A collection of expensive tools doesn't make you a good craftsman if you don't understand the material. The engineer studies everything new: the next framework, database, broker, cloud service. But never trains trade-off thinking, communication, ownership, reliability, or data modeling. The vocabulary grows; the quality of decisions doesn't. Technologies matter, but an architect is valued for judgment: when to apply, when not to, and what cost the decision creates. #### Self-check - Which of my assumptions over the past six months turned out to be wrong? - Which decisions did I revise after the data came in? - What did I write so the team could become more self-sufficient? - Which skill is currently the strongest limit on my architectural level? Back to the express course: [Software Architect: mindset, language, and practice](./software-architect).