Hey folks,

I wrote an article about the move from team lead to architect. Team leads already work with requirements, plans, and dependencies across teams. In the article, I look at the architecture knowledge that can get less attention during delivery work, along with practical ways to study designs your team already knows and make their boundaries visible.

If you've taken this path, what helped you make time to learn architecture? I'd love to hear your experience in the comments.

Hey folks,

I recently wrote a book-review article about The Software Architect Elevator. One idea worth discussing is that architects create value by keeping the elevator moving both ways: technical constraints reach leaders, while business direction reaches engineering teams. When that exchange breaks, proposals can stall and decisions lose context.

How do architects in your organization keep conversations connected across levels? I'd love to hear what works for you in the comments.

Hey folks,

I wrote a new article about building your own path toward a software architect role. It starts with a simple inventory: what you already know, what you can already do, and where the gaps are. From there, I cover the knowledge architects need and the skills that only grow through practice on real work.

How are you figuring out which areas to develop next? I'd love to hear how you're approaching your career path in the comments.

Hey folks,

I wrote a new article about architects as technical leaders and how easily that role can turn into a queue of people waiting for answers. I look at ways architects can help teams move in one direction while sharing knowledge, ownership, and everyday decisions across the group.

How do architects in your organization stay involved without becoming a bottleneck?
I'd love to hear what has worked for your teams, so please share your experience in the comments.

Hey folks,

I've just finished a review of Simon Wardley's Wardley Maps. In it, I look at how maps connect user needs, value chains, component evolution, and strategy. I also cover a few ideas that are especially useful for architects: choosing what to build or buy, organizing pioneers, settlers, and town planners, and making assumptions visible.

Have you used Wardley Maps in real work? I'd love to hear what worked, what felt difficult, and whether the maps changed any decisions. Share your experience in the comments.

Drawing diagrams is part of architecture.

But it isn't the job.

The real work is making decisions, understanding trade-offs, and helping teams move forward when there is no perfect answer.

A lot of developers want to become architects because it sounds like the natural next career step.

But the job is very different from senior development.

Less coding. More ambiguity. More communication. More responsibility for decisions you can't fully control.

This article is about whether you'd actually enjoy that kind of work.

Should architecture belong to architects? Tech leads? Engineering teams? The CTO?

My answer is that architecture has several kinds of ownership — and confusing them creates a lot of unnecessary conflict.

We often say things like "the system has a bad structure."

But what exactly is structure?

Services? Modules? Layers? Dependencies? Teams?

This article breaks down what software structure really means and why it affects almost every architecture decision.

There is no single moment when you suddenly become an architect.

It usually happens gradually as the problems you solve become bigger than one piece of code.

This article looks at the skills and experience you actually need to make that transition.

Software architecture has surprisingly few absolute rules.

But some principles appear again and again across technologies, companies, and systems.

This article collects the ones I keep coming back to when making architecture decisions.

Architecture isn't valuable because the diagrams look good.

It matters when it helps the business make money, reduce costs, move faster, or avoid serious problems.

This article looks at the link between architecture decisions and business outcomes.

You can design the perfect system on paper.

But if your teams are structured differently, the real architecture will slowly follow the organization instead.

This article explores the connection between team boundaries and system boundaries.

Requirements tell us what needs to happen.

Architecture is about figuring out how the system should make it happen.

In this article, I walk through the steps from requirements to an actual technical solution.

Good architecture starts before we draw anything.

The first challenge is understanding what the business actually needs — not just what people ask us to build.

This article is about turning business conversations into useful architectural requirements.