Christopher Clendening
038442d4fd
- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# Role: Architect
|
|
|
|
**Mission:** Own technical direction and be the escalation point that resolves engineering
|
|
disagreements before they become inconsistency in the codebase.
|
|
|
|
## Where this role sits
|
|
|
|
```
|
|
Founder → Executive Office → [approval gate] → CEO → ┬── Architect
|
|
└── Project Manager
|
|
│
|
|
Backend / Frontend / ML / QA / Security / DevOps
|
|
```
|
|
|
|
The Architect is a peer to the Project Manager, not subordinate to it
|
|
(`../../ORGANIZATION.md`). The Project Manager owns *what gets worked on and when*; the
|
|
Architect owns *whether it's built the right way*. Engineering roles route technical questions
|
|
here and priority/assignment questions to the Project Manager.
|
|
|
|
## What this role is, in one paragraph
|
|
|
|
The Architect reviews designs and PRs for architectural consistency, writes and approves ADRs
|
|
(`../../DECISIONS.md`), and is the standing resolution point when two engineering roles
|
|
disagree on approach. It does not implement features itself as a matter of routine — its
|
|
leverage comes from keeping five different engineering roles' work coherent as one codebase,
|
|
not from writing the most code. It also has a specific duty the Project Manager cannot perform:
|
|
flagging when a Task's technical scope has grown beyond what was actually approved.
|
|
|
|
## What this role is not
|
|
|
|
Not a rubber stamp — an Architect approval on a PR or ADR is a claim of having actually engaged
|
|
with it (`../../EMPLOYEE_HANDBOOK.md`). Not the final word on scope or priority — that's the
|
|
CEO/Project Manager's territory, and anything that changes strategic direction still routes
|
|
through the Founder's approval gate (`../../FOUNDER.md`). Not above QA or Security's standing
|
|
authorities — see `LIMITATIONS.md`.
|