Run a monthly kill list for a ten-person team

A kill list turns a meeting into a decision

At ten people, the company can feel like a list of open tabs. Every project has a champion, every meeting has a follow-up, and nobody owns the question of what should stop. A monthly kill-list review answers that question: ask what creates the most value, what should be stopped or relegated, and what can be automated, then record why each one died.

Unmanaged work shows up as context switching, duplicated reports, and meetings that protect old commitments. At this size, a project can survive because two people still mention it. The review makes the stop visible.

The practice has a name. Mike Allen, Jim VandeHei, and Roy Schwartz co-founded Axios in 2016 and wrote Simplify, which presents a three-step practice of confront, delete, and amplify. VandeHei is moving from a quarterly practice to a monthly attempt at a recurring audit. A quarterly practice lets a stale project hide for a season.

Five moves make the review usable

• Schedule the review before the month starts. Put it in the team calendar as a standing decision meeting, not a status check. Give it a shared document and a person responsible for the final list. Keep the meeting short, because a short meeting is easier to keep honest. The invite is recurring, with a clear agenda.
• Collect the work that actually runs the company. Pull in projects, recurring meetings, reports, support queues, and any task that consumes more than a few hours a week. Ask each person to bring the work they own, not the work they admire. Keep the page short enough to read in the room, with every item named in plain language.
• Rank each item against the audit's three questions: which tasks are essential, which can be stopped, and which can be automated. Put a simple score next to each item: customer value, revenue impact, risk, and effort. The team argues from customer impact, not habit. A shortlist of keep, cut, and automate items is the target.
• Choose the kill list and assign an owner. For each deletion or relegation, record the date, the person accountable, and the reason it was killed. Make the log row one line: what died, who owns the stop, and why. The usual mistake is to protect work because it is familiar. If the reason is that the team has always done it, the item is not essential.
• Amplify what remains. Give the surviving work a clear owner, a deadline, and a visible place in the team's plan. Name the outcome that will show the stop was worth it. The next month's calendar should show fewer commitments and more time on the work that actually moves the company.

A written log makes the kill list real

Decision ownership is the part that survives the meeting. A kill list without a named owner becomes a rumor. Put the person's name next to the deletion, and make that person responsible for telling the team the work is gone. The owner is the person who can say the item is closed, not the person who started it.

Keep the log simple. Each entry should show the date, the item, the owner, and the reason. Keep the reason short enough to defend in a future meeting: customer value dropped, the work duplicated another process, or the team no longer had the capacity. Put the log where the team already works, and make it readable by a new hire without an explanation.

Review the log at the next monthly audit. If a killed item reappears, treat it as a new decision, not a return. The review shows the old reason, the new context, and the person who now owns the choice. A stopped item stays stopped when the next audit can point to the date, the owner, and the reason.