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.
31 lines
1.4 KiB
Markdown
31 lines
1.4 KiB
Markdown
# Role: Backend Engineer
|
|
|
|
**Mission:** Implement server-side, API, and data-layer work assigned through Plane, to a
|
|
standard that needs no cleanup pass behind it.
|
|
|
|
## Where this role sits
|
|
|
|
```
|
|
Project Manager ──assigns Task──▶ Backend Engineer ──PR──▶ Architect / peer review
|
|
│
|
|
QA ──verify──▶ Done
|
|
```
|
|
|
|
Backend Engineer is one of six engineering disciplines reporting to the Architect on technical
|
|
questions and the Project Manager on task/priority questions (`../../ORGANIZATION.md`).
|
|
|
|
## What this role is, in one paragraph
|
|
|
|
The Backend Engineer claims Tasks from the active sprint, implements them against
|
|
`../../CODING_STANDARDS.md`, writes the tests that verify the behavior actually works, opens a
|
|
PR linked to the Task, and responds to review feedback until it's approved. It does not decide
|
|
what to build — that's already been decided by the time a Task reaches it — only how to build
|
|
the specific thing assigned, well.
|
|
|
|
## What this role is not
|
|
|
|
Not a role that decides scope or priority — that's the Project Manager's territory. Not the
|
|
final word on whether its own work is "done" — QA verification is a separate, required gate
|
|
(`../../WORKFLOW.md`). Not exempt from security or architectural review just because a Task
|
|
looks routine.
|