Practical tools for Technical Program Managers: templates, trackers, and scripts built from real program work.
The goal is to spend less time on the mechanical parts of program management and more time on the judgment parts.
Everything here is ready to use or adapt. Nothing requires a specific corporate system. If it needs a dependency, it is documented.
| Tool | What It Is |
|---|---|
| RAID Log Template | A clean, ready-to-use Excel RAID log with tabs for Risks, Assumptions, Issues, and Dependencies. Color-coded, auto-calculating, zero setup required. Pair it with the RAID Log Guide in tpm-templates for how to run it effectively. |
| Program Kickoff Checklist | Pre-kickoff checklist, recommended agenda with timing, section-by-section facilitation guide, and post-kickoff follow-up checklist. |
| Meeting Notes + Action Item Tracker | Template for capturing decisions, actions, open questions, and risks in a meeting. Includes a running tracker for recurring meetings. |
| Tool | What It Is |
|---|---|
| Slack Crawler | Claude Code skill I built and open-sourced here. Reads all channels in a named Slack sidebar section and produces a structured two-week intelligence brief, with hot callouts for the last 24 hours and three days at the top. Runs on demand. Optionally writes the brief to a Slack canvas. |
| Slack Canvas Status Synthesis | Two-script workflow that reads a Slack canvas to extract a reusable status template, then uses that template to generate a draft status report from your Slack channels and canvases. Draft output only. Review before posting. |
| Tool | Status | Notes |
|---|---|---|
| Program Kickoff Checklist | Ready | Good for getting scope, stakeholders, risks, dependencies, and operating rhythm aligned before kickoff. |
| Meeting Notes + Action Item Tracker | Ready | Useful for recurring execution hygiene and follow-through. |
| RAID Log Template | Ready | Solid base tracker. Pair it with the RAID Log Guide in tpm-templates. |
| Slack Crawler | Working | Strong signal-gathering workflow. Requires Claude Code and Slack MCP setup. |
| Slack Canvas Status Synthesis | Working | Strong draft-generation workflow. Requires review before publishing. |
| Program Health Dashboard | Planned | Not yet available. |
The two Slack tools are designed to work together. Run them in sequence to go from raw channel noise to a polished draft status report.
/slack-crawler <section-name> --canvas new # first run, creates the canvas
/slack-crawler <section-name> --canvas F0XXXXXXX # subsequent runs, updates in place
The crawler reads all channels in a named sidebar section and produces a structured brief covering the last 14 days. It writes the brief to a canvas and keeps updating that same canvas each time you run it.
By the time you need to write a status report, you have a current, organized picture of what happened across all your channels, not your memory of it.
./canvas_generator_from_template.py
The synthesis tool reads your program channels and the canvas the crawler just updated, applies a template extracted from one of your existing status canvases, and produces a draft in your usual format.
It will not be perfect. It will get you most of the way there: the structure, the populated sections, the signal pulled from Slack, and the first draft of the report. You still own the final call.
The crawler does the ongoing intelligence work throughout the week. The synthesis tool does the assembly work when you need to report. Keeping them separate means you can run the crawler on whatever cadence makes sense for your program without tying it to your reporting schedule.
These tools break when they are treated as the source of truth.
A crawler can collect signal. It cannot know whether a Slack message is confirmed, political, stale, or already superseded.
A status synthesis tool can draft. It cannot decide whether the program is Green, Yellow, or Red. It cannot own the risk call. It cannot make the escalation decision.
Use the tools to reduce mechanical work. Do not use them to avoid judgment.
Before using any automation with real program data:
- Confirm the tool is approved for the data you are using.
- Do not paste secrets, credentials, private keys, customer-sensitive data, restricted incident details, unreleased roadmap commitments, or regulated personal data into unapproved tools.
- Sanitize inputs when possible.
- Review all generated drafts before sharing.
- Keep the system of record updated after the draft is finalized.
A polished draft is not the system of record.
These tools are designed to work alongside the templates in tpm-templates.
The RAID log here is the working file. The RAID Log Guide explains how to run it.
The status synthesis tool produces drafts in whatever format your existing status canvas already uses, which means it works with the reporting structure in program-reporting-frameworks.
They are separate repos because templates and tools serve different purposes, but they are designed to be used together.
If you have a tool, script, or template that saves TPMs real time, open a PR or file an issue describing it.
The bar:
- It has to work.
- It has to be generic enough to apply outside one company or team.
- It has to be documented well enough that someone can pick it up without asking you questions.
- It has to make the work clearer, safer, faster, or less fragile.
These tools exist because the mechanical parts of program management - gathering signal, drafting reports, tracking status - are solvable. The judgment parts are not. The goal is to spend less time on the former so you have more for the latter.
Maintained by Eric White | ChefPlex