Developer to Architect is Now Live on LeanPub

Two years ago I started writing a book I wished had existed when I made the transition from senior developer to architect. I had read the classics — Fowler on patterns, Evans on domain-driven design, Bass on software architecture in practice — but none of them answered the question I was actually sitting with: how do I stop thinking like a developer and start thinking like an architect?

Today, Developer to Architect is live on LeanPub. This post is an honest account of what the book is, what is in it, and who I think it is for.

Why another architecture book?

Most architecture books are written by architects for architects. They assume you already think at the right level of abstraction. They go deep on patterns, quality attributes, and formal notation, but they skip the part about how to make the shift in the first place.

The transition from developer to architect is not a skill upgrade. It is a role change that requires a fundamentally different way of working: you move from solving bounded, well-defined problems to navigating ambiguous, organisation-wide trade-offs. You go from being the person who writes the code to being the person whose decisions shape what everyone else writes.

That shift is hard, and it rarely gets treated seriously. Most engineers stumble through it. This book is an attempt to map the territory.

What the book covers

The book is structured in six parts, each addressing a different dimension of the architect's role.

Part I: Foundations of Architecture

What architecture actually is, why it matters, and the mental models that separate architectural thinking from engineering thinking. Includes an overview of architectural styles, methodologies, and the frameworks (C4, TOGAF, Arc42) you will encounter in practice.

Part II: Systems Design in Depth

The technical substance of the role. Distributed systems, API design and messaging patterns, data architecture, cloud and platform engineering, security, observability, and AI as an architectural input. This is the longest part of the book because the technical depth is what gives architects credibility.

Part III: The Craft of Design

How to make and communicate architectural decisions well. Decision records, trade-off analysis, quality attribute prioritisation, diagramming that communicates rather than impresses. The chapter on balancing quality attributes includes an interactive scoring tool on this site.

Part IV: Architecture Across the Organisation

Governance, reference architecture, stakeholder management, trade-offs under pressure, and the politics of architecture. The work of an architect is mostly organisational, and this part does not pretend otherwise.

Part V: The Transition Itself

Closing the skill gap, navigating the transition inside your current company, and surviving the first ninety days in a new architect role. Includes a self-assessment tool so you can see where you are before deciding where to focus.

Part VI: Growth and Continuing Development

Architecture maturity models, continuing education, community, and what comes after the transition. The final chapter looks ahead to the broader landscape of technical leadership.

---

The ten downloadable resources

Every chapter that introduces a framework or process includes a companion resource on this site. These are not marketing collateral — they are actual working tools:

• 90-Day Plan Template — structured onboarding plan for new architects
• Architecture Decision Record (ADR) Template — complete ADR with context, decision, consequences, and alternatives
• Architecture Proposal Template — structured proposal format for significant changes
• Architecture Review Checklist — comprehensive review framework covering all quality dimensions
• Quality Attributes Worksheet — per-attribute documentation for requirements, scenarios, and measures
• Quality Attribute Prioritizer — interactive scoring matrix to rank attributes against business priorities
• Reference Architecture Template — standard reference architecture format for your organisation
• RFC Template — request for comments format for proposing changes collaboratively
• SLO Definition Worksheet — structured worksheet for defining Service Level Objectives
• Skills Self-Assessment — rate yourself across the full architect skill spectrum

All resources are free. You do not need to buy the book to use them.

Who the book is for

The intended reader is a senior developer who is starting to take on architectural responsibilities, whether by title or by practice. If you are the person in the room who gets asked "what is the right approach here?" and you are not entirely sure how to answer that question at the system level, this book is for you.

It is also for engineers who have recently moved into an architect role and are finding that the job is quite different from what they expected. The transition chapter and the self-assessment tool are particularly useful here.

It is not written for experienced architects looking for advanced patterns or academic rigour. There are better books for that. This one is about the crossing.

A note on the writing

Every chapter is grounded in real decisions from real systems. The examples use composite scenarios drawn from actual projects — nothing is hypothetical for the sake of illustration.

I have been a developer, a technical lead, and an architect across several organisations and industries. The stories and trade-offs in this book are ones I have either lived through directly or worked through alongside teams I was part of. I have tried to be honest about what is hard and what the common mistakes are, not just what good looks like in the abstract.

The book is published on LeanPub, which means you get the latest version whenever I update it. There is also a paperback on Amazon for those who prefer physical copies.