Working With Architects

Working With Architects

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

• Unclear what the EM's responsibilities are in the architect relationship → Do Your Side Well
• Need to make the case for architect time on a project → Their Side of the Deal — Don't Hesitate to Push
• About to kick off a complex project with architect involvement → Before You Consult Them
• Unclear who makes decisions — your team vs. the architecture function → Two Architecture Team Models

---

Applies to any cross-team Senior+ engineers — Architects, Staff Engineers, Principal Engineers. The title varies by organization.

---

Default Response Shape

When helping with architects or senior technical partners, clarify ownership:

1. Situation: advice, review, decision, blocked project, or architect-time request.
2. EM responsibility: what the manager must own before asking for help.
3. Architect ask: specific input, decision, review, or escalation needed.
4. Preparation: context, constraints, options, and decision deadline.
5. Relationship move: credit, follow-through, or expectation reset.

Do not frame the architect as the owner of the EM's project unless they explicitly own delivery.

---

Do Your Side Well

Don't drag their requests

When Architects need something from you — security updates, a shared-service refactor, a new testing methodology — do it fast. These things are almost never truly urgent, which makes it tempting to take your time. Don't.

A big side benefit: being the first team to implement such initiatives gets you more help and guidance from the architects. They'll invest more in teams that move quickly on shared work.

Proactively consult them

For complex technical dilemmas, ask for their opinion before you decide — even on things smaller than what typically requires their involvement. When they're kept in the loop early, there's a much higher chance they can help in later stages.

Give credit

Long projects are easy to finish while forgetting the early help that made them possible. By the end, we often don't remember the significant guidance we got from architects in the initial phases.

When presenting a feature: mention their help, thank them personally. If they did exceptional work — let their manager know.

---

Their Side of the Deal

You own it — don't forget that

In complex projects, architects may write initial infrastructure or examples to show the way. Once that initial phase is done, the ownership is 100% yours. Their role is to help you do it in the best way — not to share responsibility when things go wrong.

Resist the temptation to offload incidents or mistakes onto work they contributed to. It's your project.