Stackbook Logo
← Back to Architectural Thinking

Mentoring Rising Architects

How to grow the next generation of architects through deliberate practice, real ownership, structured feedback, and honest conversations about trade-offs.

4 min read

Architecture skill is mostly judgment, and judgment is learned from decisions and their consequences, not from books alone. That makes mentoring the primary way architects are made. Done well, it multiplies an organization's capacity to make good decisions; done poorly, it produces people who copy your opinions without understanding your reasoning. The goal is not clones, but engineers who can reason about trade-offs on their own.

Start With What the Role Actually Requires

Many strong engineers stumble when they first take an architect's seat, because the job changes. The technical bar stays high, but new skills dominate:

  • Framing ambiguous problems and clarifying what actually matters
  • Weighing quality attributes against each other under constraints
  • Influencing teams without direct authority
  • Communicating at several levels, from executives to implementers
  • Accepting that the work product is often a decision, a document, or a conversation, not code

A mentor should name these shifts explicitly. Otherwise, mentees keep optimizing for the skills that made them successful as engineers and wonder why they feel ineffective.

Teach Judgment, Not Answers

The temptation is to hand over solutions. Resist it. A mentee who is told "use an event bus here" learns a fact; one who is asked "what are the failure modes of each option, and which can this team operate?" learns a method.

Useful techniques:

  • Ask questions first. "What problem are we really solving? What would make you change your mind?"
  • Think aloud. Narrate your own reasoning on live decisions, including the doubts and the rejected options. Senior reasoning is invisible unless you make it visible.
  • Compare decisions. Walk through two real systems that made opposite choices, and examine why each fit its context.
  • Run pre-mortems. Imagine the design failed in a year and work out why. It trains the habit of seeing risk.
  • Review old decisions together. Past architecture decision records and incident reports are a rich, low-risk curriculum.

Give Real Ownership With a Safety Net

People learn architecture by owning something that matters. Assign a mentee a bounded design problem: a new integration, a data migration, a service extraction. Then calibrate your involvement:

  1. Scope together. Agree on goals, constraints, and what success looks like.
  2. Let them draft. Ask for a short design document and a recommendation before you share your view.
  3. Review at checkpoints. Challenge assumptions with questions rather than rewrites.
  4. Let them present. Having them defend the design to peers builds credibility and skill.
  5. Revisit after launch. Examine what held up and what did not, without blame.

Allow small mistakes to happen when the cost is bounded. A wrong choice that costs two weeks teaches more than ten warnings. Step in only when the risk is high, irreversible, or affects customers, and explain why when you do.

Feedback That Actually Helps

Vague praise and vague criticism are equally useless. Be specific, timely, and behavioral.

| Weak | Strong | |---|---| | "Good design." | "Listing the 'do nothing' option made the trade-offs credible." | | "Be more strategic." | "The proposal never states the expected load, so we can't judge the cache." | | "Communicate better." | "The executives needed the cost and risk first; lead with those next time." |

Hold regular one-to-ones, and ask what they want to learn, not only what you want to teach. Encourage them to maintain a decision journal: a short note of each significant decision, the reasoning, and what actually happened. Reviewing it quarterly accelerates learning.

Build Breadth and Networks

Architects need exposure beyond their own team. Introduce mentees to colleagues in security, data, operations, and product. Have them shadow incident reviews and on-call rotations, since production is the best teacher of failure modes. Encourage them to write and present internally; teaching consolidates understanding. Recommend a reading list deliberately, perhaps one classic text on distributed systems, one on domain-driven design, and a handful of postmortems.

Finally, create space for them to disagree with you. If a mentee never pushes back, they are deferring rather than thinking. Reward well-argued dissent, and admit publicly when they were right.

Key Takeaways

  • Architecture is learned through judgment, so mentor by asking questions and thinking aloud.
  • Name the shift from engineer to architect: influence, ambiguity, and communication.
  • Give bounded real ownership, with checkpoints and permission to make small mistakes.
  • Provide specific, behavioral feedback and encourage a decision journal.
  • Broaden exposure across functions and welcome respectful disagreement.