Broccoli for Managers
Who this is for: the person who runs a team — the engineering manager who owns the roster, the roadmap, the 1:1s and the quarterly plan.
Your role in Broccoli: Manager. You are the only role that owns data outright. Every other role either borrows your scope or is granted access to it. Nothing you create is visible to another manager unless you share it.
Step 1 — First login
You'll be asked to change your password before you can do anything else. Then you land on Home, which has three tabs:
- Overview — dashboard and a team health snapshot.
- Team — your roster.
- My Workspace — your private journal.
It starts empty. Broccoli doesn't guess at your team — the next three steps fill it in, in the order that makes the rest of the product work.
Step 2 — Build your roster
For each person, the fields that actually drive features later:
| Field | Why it matters |
|---|---|
| Identity, and how leadership rollups attribute work | |
| GitHub username | Without it, this person's commits and PRs never appear in any metric |
| 1:1 cadence and last 1:1 | Drives the "who is overdue for a 1:1" prompts |
| Role, level, sub-team | Grouping and filtering across every view |
| Skills, strengths, growth areas | Feeds career development and the knowledge graph |
Skip GitHub usernames and your delivery metrics will look wrong for reasons that are hard to diagnose later.
Team Graph renders the roster as an interactive org chart once it has a few people in it.
Adding someone to the roster does not give them a login. Roster entries and accounts are separate on purpose — see Step 7.
Step 3 — Set up your quarter
Pick the current fiscal quarter. Each quarter holds org goals, team goals, a capacity plan, and manager notes. Do this before the roadmap, not after — it's the frame the roadmap hangs off.
Step 4 — Build your roadmap
A Gantt-style timeline: fiscal quarters across the top, categories down the left, items dragged across months. Each item carries a status, a priority (P0–P3), story points, an owner, and — the step that matters most — a ticket link.
Work in Planning mode, then publish. The mode toggle persists, so you can restructure a quarter without your director watching it happen live.
Link items to real tickets. Put the JIRA key on each roadmap item and status flows in automatically, story points and acceptance criteria become visible, the item appears in Team Health coverage, and pull requests mentioning the key are matched to it.
JIRA data is cached for 30 minutes — if JIRA is unreachable you'll see the last good data rather than an empty board.
Step 5 — Watch delivery
Four read-only views, each answering a different question:
| Page | Answers |
|---|---|
| JIRA Live | What is in the sprint right now, and who has it? |
| GitHub Metrics | Commits, PRs opened and merged, review load, weekly throughput |
| Team Health | Is our planning hygiene good — are items ticketed, pointed, parented to an epic, assigned? |
| Developer Insights | Per-person activity, including self-reported AI tool usage |
Check Team Health before a review — a low score usually means the plan is under-specified, not that the team is slow. GitHub metrics refresh every 15 minutes; a person missing from the leaderboard almost always means a missing GitHub username, not zero activity.
Step 6 — Run your 1:1s
Open a person from the roster for their full profile: skills, strengths, growth areas, communication preferences, career development notes, goals, collaborations, and private notes. Notes are one entry per person per date; goals carry status, priority, milestones and target dates, and are distinct from roadmap items.
My Workspace is your own journal — reflections, plans, brainstorms, performance drafts — separate from anything attached to a person.
All of this is private to your scope. Directors see your roadmap through Portfolio; they don't see your notes, your goals or your journal.
Step 7 — Give other people access
You control every grant into your team:
| Grant | What they get |
|---|---|
| Team Access (viewer) | Read-only view of your roadmap and delivery data |
| Director / Executive | Your roadmap appears in their portfolio rollup, read-only |
| Program Manager | Portfolio rollup, plus status/priority/date edits — nothing else |
| Architect | Same as Program Manager, different label |
| Product Manager | Full read/write on your roadmaps — no access to your people data |
| AI Agent | A long-lived read-only API credential scoped to your team |
You can also share one specific roadmap with one account, as view or edit, without granting anything else. An editor cannot re-share it or move it into their own team, and view access still allows commenting.
Step 8 — Write things down
- Wiki — team knowledge, tagged as concept / guide / decision.
- Docs — markdown documentation in folders, can embed a whiteboard inline.
- Whiteboards — canvases for architecture sketches and planning, shareable individually.
Wiki and Docs are scoped to your team; whiteboards are scoped to you personally.
The mental model, in one paragraph
Your roster defines who is on the team. Your quarter defines what the team owes. Your roadmap breaks that into items, and linking those items to real tickets is what makes everything downstream live — status, health, PR matching, leadership rollups. Your notes and goals are the private half and never leave your scope. Everything anyone else sees, they see because you granted it.
Next: For Leadership · For Product & Program Managers · For Developers