Google & AWS Veteran: What Top Tier Software Architects Do Differently

Key Insights

1. 1

   Great architects amplify, they don't act as oracles

   Gregor argued that an architect shouldn't try to be the smartest person in the room but should make everyone else smarter. He described bad architects as easy to spot — they spew buzzwords and hoard decision power — while good ones are the people around whom "everything magically goes well and nobody knows exactly why."

2. 2

   Architecture is fundamentally risk management

   He framed the architect's value proposition as lowering risk, which has real monetary value. But he stressed software risk is broader than execution risk ("did we build what we said?") — it includes whether users like it, whether it makes revenue, and whether it grows market share.

3. 3

   Aim for simple, but respect inherent complexity

   Gregor called simplicity one of a design's biggest strengths, citing "as simple as possible, but no simpler." He noted distributed systems carry inherent complexity (retries, timeouts, idempotency, back-pressure) you can't cheat away — so the job is to make that complexity intuitive to handle, not to pretend it isn't there. Excess complexity raises cognitive load and breeds untouchable legacy.

4. 4

   Frame the solution space before debating

   He described expanding the solution space rather than handing out answers, using his "circle vs. triangle" image of two people describing the same cylinder. For microservices, he splits modularity into design-time and runtime, yielding four quadrants — which is where the modular monolith lives. He calls this "mapping the map": agree on the framing first, then debate which quadrant fits.

5. 5

   Think visually — pen, paper, and a two-brain ping-pong

   Gregor favors analog sketching over formal notation to tease out nuance, noting a diagram can't be as fuzzy as words ("two boxes, either there's a line or there isn't"). He described roughly 20 expressive dimensions available with two pens, and a "ping-pong" between structured left-brain logic and creative right-brain pattern-spotting.

6. 6

   Chase the multiplier, not the sum of skills

   He argued the goal isn't to be a good techie plus a good communicator, but to find the intersection — a technical storyteller. He calls this the "architect elevator": carrying a catchy story or visual into the executive "penthouse" and being able to back it up technically when someone pokes at it.

7. 7

   Be the Phantom Sketch Artist

   Using the metaphor of a police sketch artist, Gregor noted that knowing something and being able to express it are different skills. The architect often knows less than the team about their own system but can help them articulate it — and hearing "that's wrong" is a great signal, because it opens a constructive dialog.

8. 8

   Revalidate your heuristics — old assumptions are dangerous

   He warned that decisions which were right 5–10 years ago can quietly become wrong, making experienced architects "well-meaning but dangerous." His example: the reflex that "everything must scale out," when Moore's Law has outpaced most businesses and many apps could run on a single server with terabytes of RAM.

9. 9

   Stay current through people, not in isolation

   Gregor said you can't keep hands-on with every technology, so you rely on a trusted network. He recounted getting a two-day "full download" on generative AI from a friend rather than wading through hype, and called social media a poor source. An architect working in a vacuum, he said, is impossible.

10. 10

    Spend political capital wisely — the jester

    He likened architects to a court jester: little direct power but high influence, trusted because they have no hidden agenda. You earn capital by delivering and being transparent, then spend it deliberately on the one thing worth challenging — not in skirmishes everywhere — and you accept that not everything will be perfect.

11. 11

    Architecture is "suitable," not good or bad

    Gregor rejected a global ranking of architectures, insisting the question is whether a design suits its job and trade-offs. Even the "big ball of mud" has real virtues — quick, cheap, low skill required. A good review examines the thought process and whether trade-offs matched business needs, not whether the result matches a favorite pattern.

12. 12

    In the AI era, solid reasoning is the edge

    He observed executives rarely catch technical errors but easily smell gaps in reasoning — "like dogs who can smell" a jump in logic. With AI making it easy to paste plausible-sounding output, he argued the differentiator is sound reasoning: use the tool as a starting point you add value on top of. "Be on top of the tool," not its substitute.

Chapter Breakdown