I used to think being an Architect meant floating above the code and drawing pretty boxes. That dies on contact with reality. Real architecture is close to the users, the backlog, and the people doing the work. It is about choosing boring solutions when the shiny toy will slow the team down next quarter.
Here is how I run the Architect lane in practice.
What I own
- Outcomes in a specific domain. Think API contracts, data modeling, frontend platform, or cloud standards.
- Direction, quality, and approach for that domain. Not every decision, but the ones that shape the next year.
- The feedback loop between user pain, product goals, and technical constraints.
My north stars
- Local decisions, global consistency. Teams move fast, but they should never feel alone. I keep a short list of patterns and anti patterns that everyone can reference.
- Friction reveals truth. If teams keep tripping over the same integration, the architecture is wrong, not the teams.
- Change that sticks. A one pager with clear trade offs and a migration path beats a 30 page deck no one reads.
Day to day
- Review high impact proposals and simplify them. If a diagram needs a legend, it is probably too clever.
- Write tiny, high value docs. Decision records, reference implementations, starter repos.
- Pair with engineers on the tricky 10 percent so the next project is faster by 50 percent.
- Host office hours. Listen first. Standards follow the pain.
Patterns I push
- Small interfaces and stable contracts.
- Backward compatible releases with a sunset date.
- Guardrails in code, not just in Confluence. Linters, scaffolds, templates.
- Focus on failure modes and rollbacks before the happy path.
Red flags to kill fast
- Big rewrite energy with vague benefits.
- Architecture reviews that feel like court.
- A platform that saves the platform team time but costs everyone else twice as much.
- Decision drift. If three teams solved the same problem three different ways, we chose confusion.
A simple playbook
- Map the domain. What exists, who depends on it, where the data flows.
- Write a one pager: context, options, trade offs, decision, next steps.
- Build a reference repo that proves the decision in code.
- Set deprecation dates and offer a migration checklist.
- Measure adoption and defect rates. Adjust the pattern, not the people.
Wrap up: The Architect archetype is not about control. It is about clarity, defaults, and safe paths that help teams deliver. When it works, the org gets faster without everyone working late.