Skip to main content

The Architect Role: Technical, Strategic, Communicator

What This Concept Is​

"Architect" is not a seniority badge; it is a set of responsibilities. In any real project, the person or people doing architectural work operate in three modes, often within the same afternoon:

  • Technical. Deeply understand how the software, the runtime, the network, and the database actually behave. Read the code. Prototype when the answer is not obvious. Keep hands close enough to production to notice when a pattern is lying.
  • Strategic. Choose the direction the system should move over months and quarters. Align technical bets with business goals, team capacity, and budget. Say no to the shiny thing when it does not pay.
  • Communicator. Translate between stakeholders: engineers, product, operations, security, legal, leadership. Write down what was decided and why, so the decision survives people leaving.

The three modes are not layers of seniority. They are different kinds of judgement the role constantly switches between.

Why It Matters Here​

Most "architect" failures are mode mismatches. A brilliant technical architect who cannot communicate produces decisions no team adopts. A strategic architect with no technical grip picks directions that do not survive contact with the runtime. A pure communicator can describe any system but cannot tell you which of two options is actually wrong.

Recognizing the three modes also matters for people who are not titled architects. Every senior engineer operates in all three modes when a decision gets large enough. The module teaches the muscle, not the business card.

Concrete Example​

Same week, same architect, three scenes from a streaming video platform:

Technical mode (Tuesday morning). Latency on the video-start API has regressed. The architect reads the flame graph with the team, finds that a "harmless" JSON deserialization now accounts for 18% of the request, and pairs on a fix. This is not a title move; it is technical depth applied to a specific problem.

Strategic mode (Tuesday afternoon). Product wants personalized video thumbnails. Operations wants to cut infra spend 20%. Security wants all video manifests to be signed. All three land on the same roadmap review. The architect proposes the sequencing: thumbnails go last because they amplify every cost the other two are trying to contain. No code is written; a quarter's direction is.

Communicator mode (Wednesday). Three teams disagree on whether the new VideoSession entity belongs in the playback service or the catalog service. The architect runs a 30-minute session: draws the proposed boundary, reads back each team's objection in their own words, produces a one-page writeup with the chosen boundary and the two reasons for it. The meeting ends faster than expected because the translation worked.

The same person. Three modes. None optional.

Common Confusion / Misconception​

"Architects don't code." A dangerous simplification. The most useful architects still code, read code, or at least review PRs that matter. An architect who has not touched the system in a year confuses their last project's constraints with the current one's.

"Architects should code full-time." Also wrong. An architect whose schedule is saturated by tickets cannot think strategically. The balance matters.

"Strategic means non-technical." Strategic decisions are still grounded in technical reality. Betting the company on a technology is strategic; doing so without a prototype is negligence.

"Communication is the soft-skills part." Communication is a technical skill: compressing a decision into one paragraph that survives re-reading by a stakeholder who hates meetings is harder than most refactoring.

How To Use It​

When you are doing architecture work, name the mode you are in. This cuts two common failures:

  • entering a technical meeting in strategic mode and losing credibility with engineers
  • entering a stakeholder review in technical mode and producing a document no executive will read

A practical routine:

  1. Weekly: schedule explicit technical time (read code, review the runtime, pair on a hard bug).
  2. Weekly: schedule explicit strategic time (one roadmap or sequencing decision, written up).
  3. Weekly: produce one communication artifact (an ADR, a one-pager, a diagram a non-engineer could read).

Missing a week is fine. Missing one mode for a month signals a problem.

Check Yourself​

  1. Describe the last decision you took at work. Which of the three modes dominated? Which was missing?
  2. Name a "pure technical" architect whose work failed for lack of communication, or vice versa. What was the specific failure mode?
  3. Why can the "architect does not code" policy be true in some organizations without being true as a general rule?

Mini Drill or Application​

Keep a log for two weeks. For each substantive decision or meeting you participated in, tag it T (technical), S (strategic), or C (communicator). At the end, count. Ratios that should alarm you:

  • 90% T, 0% S, 10% C: you are doing senior-engineer work under an architect title.
  • 0% T, 90% S, 10% C: you are drifting out of the runtime; your decisions are getting less trustworthy.
  • 100% C: you are the meeting, not the architect.

Aim for a rough 40/30/30 split over a normal month. Adjust to the phase of the project.

Read This Only If Stuck​