The Architect Who Codes 80 Percent
At a 55-person product company, Mira is called 'the architect' but also tech lead of team A. She spends about 32 of her 40 hours per week coding. The architecture board meets quarterly and mostly approves documents after the fact. The backlog contains 60 items labelled 'architecture'. The project manager commits delivery dates to sales without consulting her. Two teams have built separate authentication modules, and the performance requirement 'page load under two seconds' exists only in a sales slide. Onboarding a new developer takes five weeks because knowledge is in Mira's head. The CTO says she is 'too hands-on' and 'not strategic', while team A says she is the only one who understands the code. She has no budget or line-management authority. The company plans to double to 110 people in 18 months, and the CTO wants a role description, not a resignation.
1. Separate Mira's tasks into architect, tech lead and project manager responsibilities. Which should she stop, keep or delegate, and why?
Read the worked answer
The core distinction is accountability, not seniority.
- Architect responsibilities she should keep: cross-team structures and interfaces; quality attributes and scenarios; architecture decisions and their rationale; technology strategy and risks; stakeholder communication; reviewing whether projects fit the architecture. These require an organisation-wide view and cannot be delegated to one team lead.
- Tech lead responsibilities she should delegate: team A's detailed design, code reviews, task breakdown, mentoring and day-to-day technical decisions. Keeping these creates a conflict of interest and a bottleneck. She can stay technically credible through reviews, spikes and prototypes, not by owning 80% of feature code.
- Project manager responsibilities she should stop: committing delivery dates to sales, tracking effort and managing staffing. She can supply estimates and dependency risks, but the project manager owns schedule and budget.
- Architecture backlog: triage the 60 items into decisions, guidelines, investigations and team-level design. Team-level items go back to teams; only cross-cutting or high-cost decisions stay with her.
The reasoning: 32 coding hours leave little capacity for cross-team work, yet the duplicate authentication modules and hidden performance requirement are exactly the failures that architecture work should prevent. A role that cannot say no to coding cannot say yes to architecture.
2. Design a lightweight decision-making and escalation model for growth from 55 to 110 people. Include triggers, roles and artifacts.
Read the worked answer
Use explicit decision rights and a small set of triggers.
Architecturally significant triggers: a new external dependency or partner protocol; a change in data ownership or consistency guarantees; a new cross-team interface; a decision that affects an agreed quality scenario; a technology with high lock-in or operational cost; a deviation from a principle.
Roles: teams decide local design within guardrails. The architect decides or facilitates cross-cutting decisions and records them. The project manager owns schedule and budget. The CTO is the escalation point for unresolved conflicts over money, staffing or risk acceptance.
Artifacts: a one-page decision record per significant decision (context, options, decision, consequences); a short principles and guardrails page; a quality-scenario catalogue; an interface catalogue.
Process: propose in writing, consult affected teams and operations, decide within an agreed timebox, inform stakeholders, review at a monthly architecture forum. The forum is not an approval queue for every change; it resolves cross-team trade-offs and checks whether decisions still hold.
Escalation: if teams cannot agree within the timebox, the architect decides or escalates with options and consequences. This avoids both design by committee and silent local divergence, which produced two authentication modules.
3. How can Mira remain technically credible without coding 80% of her time?
Read the worked answer
Credibility comes from making sound judgements visible, not from being the fastest coder. Practical mechanisms:
- Timeboxed spikes and walking skeletons for uncertain architecture decisions, with a clear discard or productionise outcome. This keeps her hands on real constraints without owning features.
- Architecture reviews and code reviews focused on cross-cutting concerns: error handling, observability, API contracts, data ownership and testability, rather than style.
- Pairing with tech leads on the hardest interfaces and incident reviews, so she sees where the architecture fails.
- Metrics: track p95 latency, change lead time, defect escape rate and onboarding time. Technical arguments become evidence-based.
- Teach the triggers: when teams can identify significant decisions themselves, they need her less for routine work.
The trade-off is deliberate: less feature output from Mira, more cross-team capacity and fewer duplicated or conflicting solutions. If the CTO wants both, the role must be resourced with tech leads who own team-level design.