# Developer to Architect: A T-shaped Learning Path

Most developers become architects by accident. A migration lands on your desk, nobody else will decide, and one day the title catches up with the work. It gets there eventually — but it is slow, and it leaves gaps nobody names until they cost something.

This learning path makes the route explicit. It has three moving parts: **the shape** you are aiming for, **the score** you give yourself today, and **the ladder** you climb. Work through them in that order.

The skill map behind it is maintained in the open at [ankurkumarz/t-shaped-architect](https://github.com/ankurkumarz/t-shaped-architect) — the technology lists below are drawn from it, and pull requests are welcome.

## The shape: one bar deep, ten boxes wide

A [T-shaped skill set](https://en.wikipedia.org/wiki/T-shaped_skills) has a vertical bar — the depth you own — and a horizontal bar — the breadth you can reason across. Architecture needs both. Depth without breadth produces a very good engineer who recommends the only stack they know. Breadth without depth produces slide decks nobody can build.

![The T-shaped architect: ten breadth areas across the top bar over a vertical stem representing depth in one or two specialisations](https://vedcraft.com/images/2026/08/t-shaped-architect-skills.svg)

The horizontal bar is deliberately shallow. You need enough of each area to ask the right question, spot the risk, and choose between two options — not enough to build it single-handed. That is the whole trick, and it is why the list stops at three to seven technologies per area rather than trying to be a catalogue.

## Step 1: score yourself, honestly

Before you learn anything new, rate every box. Four levels, and the definitions matter more than the labels:

![Four knowledge levels — expert, experimental, know-how and want-to-try — shown as a filled-square meter](https://vedcraft.com/images/2026/08/architect-knowledge-levels.svg)

| Level | What it actually means |
|---|---|
| **Expert** | 3+ years hands-on and in-depth. You are the person the team escalates to. |
| **Experimental** | 1+ year hands-on. You have shipped something with it and know where it hurts. |
| **Know-how** | You understand the model and have reached for it when needed. |
| **Want to try** | On your list for the next twelve months. Nothing more. |

Two rules make this useful rather than flattering:

- **Two or three boxes at Expert, the rest at Know-how.** That is the shape. Five Experts and five blanks is a specialist; ten Know-hows and no Expert is a generalist. Neither gets the architect's job done.
- **Write the evidence next to the score.** "Expert, Kubernetes" is a claim. "Expert, Kubernetes — ran the cluster migration, wrote the operator, on-call for two years" is a fact. If you cannot write the second sentence, you are one level lower than you think.

## Step 2: fill the horizontal bar

Ten areas, and a sensible place to start in each. Aim for Know-how everywhere and let your specialisation pull two of them up to Expert.

| Area | Get to Know-how on | Start here |
|---|---|---|
| **User Experience** | How a modern front end is built and delivered | React or Angular, one CSS framework, Core Web Vitals |
| **APIs & Microservices** | Service boundaries, contracts, versioning, gateways | Spring Boot or FastAPI, OpenAPI, Kong or Apigee |
| **Data & Databases** | When relational stops fitting, and what replaces it | PostgreSQL, MongoDB, Redis, one graph store |
| **Events & Streaming** | Delivery guarantees, ordering, replay, back-pressure | Kafka, then Pulsar or NATS for contrast |
| **Public Cloud** | One provider properly, the other two by analogy | A well-architected framework, then compute, storage, IAM |
| **DevOps & Kubernetes** | How your code actually reaches production | Kubernetes, Terraform, GitHub Actions, Argo CD |
| **Observability** | The four signals and what each one answers | Prometheus, OpenTelemetry, Grafana, one APM |
| **Performance** | Tactics before tools — where latency is spent | SEI performance tactics, JMeter or k6 |
| **Security** | Threat modelling and the shift-left toolchain | OWASP Top 10, SAST/DAST/SCA in the pipeline |
| **Architecture & Design** | Styles, patterns, views, and how to write them down | The twelve-factor app, DDD, cloud design patterns, C4 |

Two shortcuts worth taking. First, learn the **frameworks before the products** — [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected), [Azure Well-Architected](https://learn.microsoft.com/en-us/azure/well-architected/) and the [Google Cloud Architecture Framework](https://cloud.google.com/architecture/framework) each teach the same five or six concerns, and once you have them the specific services are lookup. Second, learn the **tactics before the tooling**: the performance and security chapters of *Software Architecture in Practice* will outlast every product in the right-hand column.

If the vocabulary itself is the barrier, start with [modern technical buzzwords you should know as a software architect](https://vedcraft.com/architecture/modern-technical-buzzwords-you-should-know-as-a-software-architect/) and the [system design mind map for building distributed systems](https://vedcraft.com/architecture/system-design-mind-map-for-building-distributed-systems/).

## Step 3: climb the ladder

The scope widens at every rung. Nothing is dropped.

![Developer to enterprise architect shown as a five-step staircase, each step adding responsibilities to the one before it](https://vedcraft.com/images/2026/08/architect-role-ladder.svg)

| Rung | What is new | The habit that gets you to the next one |
|---|---|---|
| **Developer** | Code, tests, refactoring, patterns, perf and security fixes | Read the code you did not write |
| **Technical Lead** | Reviews, component design, anti-patterns | Explain a decision without using the word "obviously" |
| **Technical Architect** | Architectural patterns, views and UML, deployment topology | Write the design down before you build it |
| **Solution Architect** | Technology selection, impact analysis, ROI, build vs. buy | Cost two options and recommend one in writing |
| **Enterprise Architect** | TOGAF and Zachman, roadmaps, future state, stakeholders | Say no to a good idea with the reason attached |

The right-hand column is the actual work. Titles arrive late; the habits arrive first, and they are visible from the outside.

## Step 4: practise the craft, not just the stack

Technology knowledge is the part that shows on a CV and the smaller half of the job. Four things compound faster:

- **Write architecture decision records.** One page: context, options, decision, consequences. A year of ADRs is the most convincing portfolio an architect can have.
- **Draw at more than one altitude.** Context, container, component — the [C4 model](https://vedcraft.com/tech-trends/tech-tips/use-c4model-for-visualizing-software-architecture-in-a-modern-way/) makes this a habit rather than an art. Add the [industry standards for documenting and evaluating architecture](https://vedcraft.com/tech-trends/tech-tips/use-industry-standards-and-guidelines-for-documenting-and-evaluating-software-architecture/) when the audience widens.
- **Separate the logical from the physical.** Two different diagrams, two different conversations — see [5 tips for effective logical architecture](https://vedcraft.com/architecture/5-tips-for-effective-logical-architecture/).
- **Stay hands-on.** Not full-time, but enough to keep the estimates honest. [Linux commands every architect should know](https://vedcraft.com/learning-paths/linux-commands-every-architect-should-know/) is a fair floor.

## A twelve-month plan

If you want the whole path as a calendar:

| Quarter | Focus | Deliverable |
|---|---|---|
| **Q1** | Score every box; pick your two Expert areas | A filled-in skill matrix with evidence per row |
| **Q2** | Close the three weakest Know-how gaps | A small running system in each — not a tutorial |
| **Q3** | Design something end to end | C4 diagrams, an ADR set, a costed option comparison |
| **Q4** | Take it to stakeholders | A reviewed design, a roadmap, and a decision you owned |

None of it requires a title change to start. That is the point of the path: every rung on the ladder is something you can begin doing on Monday in the job you already have.

## Where to go next

- [ankurkumarz/t-shaped-architect](https://github.com/ankurkumarz/t-shaped-architect) — the full, maintained skill map
- [Grow as an Architect from a Developer](https://vedcraft.com/become-architect-from-developer/) — the role-and-responsibility view of the same journey
- [How to be a successful software architect with the power of 3 Ps](https://vedcraft.com/learning-paths/successful-software-architect/)
- [5 books every software architect should read](https://vedcraft.com/architecture/5-books-every-software-architect-should-read/)
- [Java/Python Developer to AI Engineer](https://vedcraft.com/learning-paths/java-python-developer-to-ai-engineer-learning-path/) — if AI is one of your two vertical bars
- [Data Engineer to AI Data Engineer](https://vedcraft.com/learning-paths/data-engineer-to-ai-data-engineer-learning-path/) — if data is
- [DevOps Engineer to LLMOps/AIOps Platform Engineer](https://vedcraft.com/learning-paths/devops-engineer-to-llmops-aiops-platform-engineer/) — if the platform is