Broccoli for Architects
Who this is for: the technical counterpart to a Program Manager — someone with oversight across several teams for architectural rather than delivery reasons.
Your role in Broccoli: Architect. Your capability set is identical to Program Manager; what differs is the label and the intent behind the grant. Where a Program Manager asks is it on track?, you're asking is it being built coherently?
Step 1 — Get granted
You own no data. Each manager whose team you cover adds you from their team access settings. Until then, you'll see an empty Portfolio — that's a missing grant, not a fault. Grants are explicit and additive; no role sees everything by default.
Step 2 — Read across teams
Your navigation: Portfolio, Roadmap, JIRA Live, Whiteboard, Profile.
Portfolio is every granted team's roadmap on one timeline. For architecture review, look for:
- Items touching the same subsystem across two or more teams.
- At-risk items with technical rather than scope causes.
- Sequencing — is a dependency scheduled after the thing that depends on it?
- Items with no ticket, which usually means the work isn't specified enough to review.
Step 3 — Adjust sequencing, not scope
You can edit exactly four fields on any item in a granted team's roadmap: status, priority, start month, end month. You cannot rename, add, delete, or change descriptions, owners or points.
This is the right boundary: those four fields are what you need to fix a sequencing problem — pull a platform dependency earlier, raise the priority of a blocking piece. What they don't let you do is quietly redefine another team's work. Every change is recorded in the roadmap's history.
Step 4 — Use the Knowledge Graph
Concepts, skills and work items as nodes; references and dependencies as edges, built from roadmap and ticket data across teams. The closest thing Broccoli has to a coupling map — useful for spotting which teams are touching the same component, or where a capability lives in exactly one person's head.
It's produced by a periodic batch job, not live — it reflects the last sync.
Step 5 — Publish decisions
Whiteboards are canvases for system diagrams and migration plans, shareable with specific people — private to you until shared. For durable decisions, ask the relevant team's manager to record them in their team Wiki or Docs.
You also get a full Roadmap page of your own — a standing technical roadmap (platform migrations, deprecations, hardening work) is often the most effective way to make architectural work visible next to feature work.
Sharing with a Director or Executive is automatically downgraded to view-only. Team Access accounts cannot receive shares.
What you cannot do
| You cannot | Why |
|---|---|
| Add, delete or rename items on a team's roadmap | Scope belongs to the owning team — you get the four sequencing fields |
| See 1:1 notes, goals or a manager's journal | No cross-team role can read another manager's people data |
| See a team that hasn't granted you access | Grants are explicit |
| Re-share a roadmap that was shared with you | Sharing is reserved for the true owner |
Architect vs Program Manager vs Product Manager
Same shape, different questions:
| Architect | Program Manager | Product Manager | |
|---|---|---|---|
| Question | Is it coherent? | Is it on track? | Is it the right work? |
| Cross-team rollup | Yes | Yes | No |
| Roadmap editing | Four sequencing fields | Four sequencing fields | Full authoring |
| Knowledge Graph | Yes | — | — |
If you also need to author a team's roadmap outright, ask for a Product Manager grant alongside your Architect grant — the two stack.