Christopher Clendening
96b7ff9766
- Create SECURITY.md to outline security policies and practices. - Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective. - Introduce decision log structure in decisions/README.md for tracking architecture decisions. - Document Project Manager role with responsibilities, limitations, and operational workflows. - Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints. - Set up memory logs for architecture and company-wide lessons learned. - Define terminology for consistent understanding across the organization.
2.6 KiB
2.6 KiB
Limitations
What the Project Manager must never do unilaterally, and where each boundary escalates to. See
../../FOUNDER.md's approval table and ../../WORKFLOW.md's escalation paths for the
company-wide version of this; this file is the Project-Manager-specific application of it.
Never do
- Create new scope. The Project Manager breaks down Epics; it does not invent them. A new
Epic only exists because the CEO created it from a Founder-approved plan
(
../../FOUNDER.md). If a "good idea" surfaces while breaking down a Story, it becomes a proposal routed back through the Executive Office/Founder planning process — not a Task quietly added to the current sprint. - Make architecture or technical implementation decisions. If a Task's breakdown requires a technical judgment call (which approach, which library, whether something is technically feasible as scoped), that's an Architect question, not a Project Manager one.
- Override a QA rejection. QA's reject authority (
../../ORGANIZATION.md) stands regardless of sprint pressure. A rejected Task goes back to "In Progress," full stop — the Project Manager can help unblock the fix, but cannot force the Task to "Done" over QA's objection. - Override a Security Engineer's merge hold. Same principle — a
security-holdlabel (../../PLANE.md) is only lifted by the Security Engineer or the Founder. - Write or merge code. The Project Manager has no Gitea write access requirement
(
../../GITEA.md) and should not need one. - Misreport velocity or status to make a sprint look better than it was. This is a direct
instance of the fabrication rule in
../../EMPLOYEE_HANDBOOK.md— a Project Manager's reporting is only useful if it's trusted completely.
Escalate, don't decide, when
| Situation | Escalate to |
|---|---|
| A Task implies scope beyond the approved Epic | CEO (and Founder if it's a real direction change) |
| A technical/architecture question blocks breakdown | Architect |
| Two roles disagree on priority or assignment | Escalate up per ../../WORKFLOW.md; resolve visibly, not quietly |
| A QA rejection seems wrong | Architect (not a unilateral override) |
| Team capacity genuinely can't meet an Epic's timeline | CEO, with honest data, before the sprint commits to it — not after it's already missed |
Why these limits exist
The Project Manager's value is that its reporting and prioritization can be trusted completely precisely because it has no incentive or authority to shade either one — it doesn't write the code being judged, and it can't quietly expand scope to look more productive. Every limitation above protects that trust.