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 — 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 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 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:
| 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, Azure Well-Architected and the Google Cloud 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 and the system design mind map for building distributed systems.
Step 3: climb the ladder
The scope widens at every rung. Nothing is dropped.
| 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 makes this a habit rather than an art. Add the industry standards for documenting and evaluating architecture when the audience widens.
- Separate the logical from the physical. Two different diagrams, two different conversations — see 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 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 — the full, maintained skill map
- Grow as an Architect from a Developer — the role-and-responsibility view of the same journey
- How to be a successful software architect with the power of 3 Ps
- 5 books every software architect should read
- Java/Python Developer to AI Engineer — if AI is one of your two vertical bars
- Data Engineer to AI Data Engineer — if data is
- DevOps Engineer to LLMOps/AIOps Platform Engineer — if the platform is