Talk: How To Become a Great Software Architect (Beyond Coding) Guest: Gregor Hohpe (ex-Google & AWS, author of The Software Architect Elevator) · Host: Patrick Akil
- Not a title — it's a mindset; product/technical people can have it.
- The job is to make everyone else smarter (amplifier), not to be the smartest or the oracle who hands out answers.
- Value = surfacing blind spots, showing other angles, making implicit tradeoffs explicit so the team decides better.
- Bad architects: buzzword-spewers and decision-hoarders. Good ones are nearly invisible.
- Architects are really risk managers; the risks an org prioritizes shape how its architects behave.
- Simplicity is a top strength, but some complexity is inherent (distributed systems = retries, timeouts, idempotency, back pressure). You can't cheat physics.
- Rule: as simple as possible, but no simpler. Don't hide inherent complexity — make it intuitive to handle.
- Modern software isn't simpler than a monolith-on-one-server; it just has more properties.
- The architect's job is to conquer/abstract complexity. Excess complexity → cognitive load → mistakes → software people fear to touch → legacy.
- Fights happen because people argue paths without sharing a map.
- Fix: agree on a common framing of the solution space first; debate within it second.
- Example: "microservices" = modularity, which splits into design-time × runtime = four quadrants (this is where the modular monolith lives), not a binary.
- Prefer pen/paper/whiteboards and one-off sketches over UML (UML documents; sketches reveal).
- Words let you stay fuzzy; a diagram forces clarity (line or no line).
- Sketches are models with semantics (3 boxes = "multiple," not three).
- ~20 expressible dimensions with two pens (size, shape, shading, order, nesting, position).
- Skill is muscle memory, not artistic talent — learn by pairing with someone, not from a book.
- Work the "left/right brain ping-pong": structured logic ↔ creative reframing.
- Architect = sketch artist: has the skill to articulate; the team has the knowledge.
- Drawing it back and being told "that's wrong" is the goal — it starts the dialogue that lands on "exactly like that."
- Stop maintaining one giant always-current map. Be a scout: start with an objective, bring back a simple, purpose-driven map of just what matters for the next move.
- Too many architects seek answers before they have a question. Start with the question.
- Requires real technical depth; you can't arm-wave it.
- Biggest trap: sound reasoning built on outdated constraints (e.g., "must scale out" when Moore's law lets most apps run in-memory on one server).
- Revalidate your heuristics — everyone relies on them.
- You can't be hands-on with everything → build a trusted network; learn from people in the trenches. Social media is noise.
- Can't architect in isolation: you need feedback loops to learn which designs actually worked.
- Be someone people give honest feedback to, not someone they placate and ignore.
- Works fine as an IC.
- Three valid paths: top engineer, technical manager, architect.
- Don't monopolize knowledge (the oracle persona) — share freely (books, blogs).
- Either you free up cycles for new problems, or you quietly enjoy the lull.
- Court Jester: trusted to tell the truth because they have no hidden agenda; architects have low power but high influence on the same basis.
- Political capital: earn it (deliver, keep promises, be transparent/fair), then spend it deliberately.
- Spend on the one issue that moves the needle (e.g., the doomed tens-of-millions project), not on skirmishes everywhere.
- No one's line of credit is infinite. And accept things won't be perfect — or you won't sleep.
- Only suitable vs. unsuitable for context. A Big Ball of Mud can be the right call under a hard deadline.
- Don't be the smarty-pants; probe future needs (scale, lifespan, next requirements) and guide via dialogue, not "good pattern / bad pattern."
- They won't critique your Helm chart — they smell whether your story holds together.
- They hunt logic gaps: alternatives considered, metrics, what success looks like, upfront cost, can we defer, can we start simple.
- Engineers stumble when their reasoning isn't straight.
- Paste raw LLM output and you can only lose: if it's great, you're redundant; if it's bad, it's bad for you.
- Tool output is a starting point; you add the value. Tells (long lists, fluff, overconfidence) collapse under one or two questions.
- Use AI as an amplifier, not a substitute. Be on top of the tool, not the tool.
- Don't stumble on the finish line: when complexity suddenly looks obvious, that's success, not failure.
- Never let "that's too simple / obvious" undervalue it — if it were obvious, they'd have done it themselves.