# kanman

> kanman takes requirements, writes the stories, ships the code through Claude Code or Codex, and proves every change against your acceptance criteria. Inside your Jira or GitHub. Hosted in the EU or on your own servers.

## Everyone on your team has an AI coding tool. Nobody has an AI teammate.

Copilot and Claude Code licenses make each developer faster. They don't decide what gets built, what the agent may touch, or whether the result works.

- Nobody owns intake. Someone still has to turn requests into work an agent can finish. Vague tickets in, vague code out.
- Nobody sets the rules. Nobody decided what the agent may touch, spend or merge. So either it can't do much, or it can do too much.
- Nobody proves the result. 'Tests pass' is not 'it works'. Somebody has to check, and right now that somebody is your best reviewer.

## From requirement to reviewed pull request

Five stages. Your tracker, your CI and your review rules stay where they are.

### 1. Intake: A requirement becomes stories you can check

Someone pastes a requirement into kanman or tags it in Slack. kanman asks what is unclear, then drafts small stories with acceptance criteria.

Every criterion comes with a way to demonstrate it. That demonstration becomes the acceptance spec, written before any code exists.

- Stories land in your tracker, under your column names
- A person approves the stories before they are written to the tracker
- The spec must fail first. A spec that passes on today's code proves nothing.

### 2. Rules: Your policy decides what happens next

Before kanman starts, it checks the story against your policy. Which repos and paths it may touch, how much a run may cost, whether it may run now.

When a call is too big for the policy, it becomes a decision. You get the question, kanman's recommendation and the options, in the app, in Slack or in Microsoft Teams.

- Five presets from Trial to Hardening set the pace and initiative
- The sandbox and the outcome gate are the same in every preset
- Every check and every decision lands in the audit log

### 3. Work: The coding agent works in a sandbox

kanman hands the story to Claude Code or Codex, running headless in a fresh sandbox. In Frankfurt, or on your self-hosted runner.

It picks the model by complexity, so a typo fix does not cost what a migration costs. Budgets stop a run before it gets expensive.

- Your verify command (lint, types, tests) runs before anything else
- The agent has no write access to the acceptance spec
- A failed gate gets one rework attempt, then it comes back to you

### 4. Proof: The spec runs on a clean checkout

The outcome gate starts your app from the pull request's commit, in a fresh environment, and runs the story's spec. Nothing cached, nothing from the agent's machine.

The result is the evidence pack. Each criterion with passed or failed, the spec that checked it, the trace, the duration and the cost.

- No spec, no Ready. No green run, no review.
- In repos without specs, the Trial preset says so plainly in the pack

### 5. Handoff: A pull request your people can trust

kanman opens the pull request with the evidence attached, updates the story in your tracker and writes the audit entry.

Your people review and merge, as they do today. If your policy allows automatic merges for small changes, those merge when every gate is green.

- Review comments that repeat become team conventions
- You can read, edit and retire every convention

## Agents say "done". kanman shows you.

Every pull request comes with an evidence pack. You review the change knowing it already does what the story asked for.

- The spec was written before the code. kanman writes the acceptance spec at intake. It has to fail before the story counts as Ready.
- The agent cannot edit it. The coding agent has no write access to the spec. A changed spec fails the gate.
- It ran on a clean checkout. Not on the agent's machine. A fresh environment, the pull request's commit, nothing cached.

## You decide how much it decides.

Presets from Trial to Autonomous. Budgets with hard stops. Every decision in an audit log you can export.

- Trial: For the first week. Works on repos without acceptance specs and says so in every evidence pack.
- Focused: Only works on stories your people filed. Nothing on its own initiative.
- Balanced: Picks up ready work at a steady pace and asks when a call is big.
- Autonomous: Four stories at a time, for teams with good test coverage. Same gates, same sandbox.
- Hardening: Adds maintenance on a slow drip. Security advisories, outdated dependencies, broken doc links.

Presets change pace, initiative and the default protected paths. The sandbox and the gates are the same in every preset.

- Authority levels: Per repo and path. What kanman may change alone, what needs a review, what it never touches.
- Budgets with hard stops: Per run, per day and per month. When a budget runs out, kanman stops and asks. Incident work is never blocked.
- An audit log you can export: Who decided what, on whose approval, at what cost. Ready for the next audit.

## It gets better at your codebase every week. You can see what it learned.

Review comments that repeat become team conventions. You can read, edit and retire every one.

## Your tracker stays. Your CI stays. Your review rules stay.

- GitHub: Issues, pull requests, checks
- GitLab: Cloud and self-managed
- Jira: Your boards, your column names
- Claude Code: Headless, in a sandbox
- Codex: Headless, in a sandbox
- Slack: Questions, requests and decisions in your channels
- Microsoft Teams: Channels, group chats and direct messages
- Confluence and Notion: Answers from your docs, with sources
- Your CI: GitHub Actions, GitLab CI and the rest
- Self-hosted runner: Coding runs inside your network
- kanman board: No tracker yet? Stories live on the team's own board
- MCP: Use kanman from Claude Code or Codex

## Priced per AI team. Not per seat.

Start with a pilot on one repo. Keep kanman when the evidence convinces you.

### Pilot (from €5,000 for 6 weeks)

6 weeks, one team, one repo. Includes setup with you.

- Setup with your team, in your tracker and your repo
- An acceptance manifest pull request for your repo
- A weekly review of runs, decisions and cost
- A written summary at the end, yours to keep

### Team (€990 per AI team per month)

One kanman working with one engineering team. Billed monthly.

- Intake, outcome gate, decisions and audit log
- GitHub, GitLab or Jira, plus Slack
- Claude Code or Codex in a sandbox in Frankfurt
- Your own model keys, or usage at cost plus 15%

### Self-hosted (on request)

The runner sits in your network and runs the coding work there, with your model contracts.

- Self-hosted runner for all code execution
- Your contracts with Anthropic, OpenAI, Azure or Bedrock
- DPA and security review support

Model usage runs on your own keys, or is passed through at cost plus 15%. No per-seat pricing.

## Book a pilot

You watch kanman work on your backlog, under your rules, with evidence for every change. At the end you decide with results, not with a demo.

- Week 1, Setup: We connect your tracker and repo together, pick the Trial preset, and kanman opens the pull request with your acceptance manifest.
- Weeks 2-3, First stories: kanman takes real stories from your backlog. Every pull request comes with an evidence pack. You review as usual.
- Weeks 4-5, Your rules: We tune the policy with you. What kanman may touch, the budgets, which calls come to you. Most teams move to Balanced here.
- Week 6, Results: A written summary of what shipped, what needed rework, what it cost and what we would change. You keep all of it.

## Security and data

Where kanman runs, what it can touch, what model providers see and how long we keep things. Every claim links to the document behind it.

- Hosted in the EU: Coding sandboxes run in Frankfurt, Germany. Application data is stored in EU data centres.
- Self-hosted runner: Run the coding work inside your own network. Your code is checked out and executed there. Optionally model calls, reviews and every repository action too.
- Everything on your runners: Switch on "Run everything on our runners" and kanman's cloud never calls a model provider or your code host. Drafting, reviews, acceptance specs, pull requests and merges run on your runners with your own model account and tokens. kanman keeps the board, decisions, the audit log and the results your runners send back, never your code.
- A fresh sandbox for every run: Each run gets its own isolated environment, which is discarded afterwards. Nothing carries over between runs.
- Secrets stay where they belong: Each team names the secrets its runs may use. Values exist only on the run's machine, are removed from logs and never land in the repository, the evidence pack or the audit log.
- What model providers see: The prompts and code context a run needs. Bring your own keys for Anthropic, OpenAI, Azure OpenAI or AWS Bedrock and it runs under your contract.
- Only what your policy allows: Repositories, paths, budgets and merge rights are set per team. By default a person merges.
- Answers only from what you may see: When kanman answers from team knowledge (Confluence, Notion, repositories, documents), it checks what the asking person may see in the source and names its sources. Chat and team context are off until a team admin turns them on.
- Single sign-on: Members sign in through your company's identity provider, with your password, MFA and session rules.
- An audit log you can export: Every decision, approval and policy check is logged with who, what and when. Audit entries are kept for 365 days by default.
- Deletion when you leave: When the contract ends you can export your data. We delete it within 30 days.
- DPA and subprocessors: A data processing agreement under GDPR Article 28, with the subprocessor list per executor.
- No training on your code: kanman does not use your code, stories or evidence to train models.

## FAQ

### How is this different from assigning issues to Copilot, Claude or Codex in GitHub or Linear?

Those tools hand an issue to an agent and give you a pull request back. kanman adds what sits around the agent. It turns requirements into stories with acceptance criteria, follows the policy you set, and proves each change against those criteria on a clean checkout before anyone reviews it. The coding itself still runs on Claude Code or Codex. (https://docs.kanman.ai/en/concepts/outcome-gate/)

### Do we have to leave Jira or GitHub?

No. kanman works in your tracker, whether that is GitHub Issues, Jira or GitLab. Stories, status changes and pull requests show up where your team already looks. No tracker yet? A team can keep its stories on its own kanman board and connect a tracker later. (https://docs.kanman.ai/en/getting-started/connect-jira-and-gitlab/)

### Which models and agents does it use? Can we use our own contracts?

The coding runs through Claude Code or Codex. You can bring your own keys for Anthropic, OpenAI, Azure OpenAI or AWS Bedrock, or let kanman pass usage through at cost plus 15%. kanman picks the model by complexity, so small fixes stay cheap. (https://docs.kanman.ai/en/security/model-providers/)

### Where is our code processed and stored? What do model providers see?

kanman runs in the EU. Coding happens in sandboxes in Frankfurt, and every run gets a fresh sandbox that is thrown away afterwards. Model providers see the prompts and code context a run needs, under your own contract if you bring your keys. With the self-hosted runner, code execution stays in your network. (https://docs.kanman.ai/en/security/hosting/)

### Can it merge to main on its own?

Only if your policy says so. By default a person reviews and merges. You can allow automatic merges for small changes: every gate green and the diff under a line limit you set. While main is red, kanman holds them. (https://docs.kanman.ai/en/concepts/policies/)

### What happens when it gets stuck?

It stops and asks. You get a decision with its recommendation and the options, in the app, in Slack or in Microsoft Teams. A failed gate gets one rework attempt. After that it comes back to you instead of looping. (https://docs.kanman.ai/en/concepts/decisions/)

### Can kanman be on call for the services we run?

Yes, if you want it to. Connect uptime checks, your alerting tool (Alertmanager, Grafana, Datadog, PagerDuty, Opsgenie, Sentry, CloudWatch and others) and your logs. When something degrades, kanman opens an incident in your Slack or Teams channel, looks at recent merges, deploys and error traces, and posts what it finds. For a bug in the code it starts a fix that has to reproduce the error first, or proposes a revert. Changes to production outside the code always go to a person. Observe only is one switch away. (https://docs.kanman.ai/en/concepts/incidents/)

### Does kanman take part in our Slack or Microsoft Teams conversations?

Only where you add it. It answers questions about the team's work with links and sources, and turns requests into story drafts that a lead approves before anything reaches the board. By default it speaks only when mentioned. Per channel you can let it speak up, with a daily cap, quiet hours and a stop button on every unprompted reply. (https://docs.kanman.ai/en/guides/channel-modes-and-guardrails/)

### Can it answer from our docs, repos, Confluence or Notion?

Yes, once a team switches it on. Add uploads, web pages, repository docs, issues, Confluence spaces or Notion pages, and kanman names its sources in every answer. Where the source can tell, it only uses what the person asking may see there, such as Confluence page permissions or repository access. If nothing fits, it says so. (https://docs.kanman.ai/en/guides/team-context-and-connectors/)

### What does it cost to run, and how do budgets work?

The Team plan is a flat price per AI team, listed in the pricing section. Model usage comes on top, on your own keys or at cost plus 15%. You set budgets per run, per day and per month with hard stops. Incident work is never blocked by a budget. (https://docs.kanman.ai/en/concepts/budgets/)

### Our repo has no acceptance tests. Can we still start?

Yes. The Trial preset works without specs and says so plainly in every evidence pack. In the first week kanman opens one pull request that adds an acceptance manifest. From then on every story gets a spec. (https://docs.kanman.ai/en/guides/acceptance-manifest/)

### Can we self-host?

Yes. The self-hosted runner does all code execution inside your network, with your model contracts. Switch on "Run everything on our runners" and model calls, reviews and every repository action stay there too; kanman's cloud keeps the board, the decisions and the audit log. (https://docs.kanman.ai/en/guides/self-hosted-runner/)

### What does a pilot look like?

Six weeks, one team, one repo. We set kanman up with you, add an acceptance manifest, pick a preset and run real stories from your backlog. At the end you get a written summary of what shipped, what needed rework and what it cost.

## Blog

### Agents Need a Policy, Not a Better Prompt

https://kanman.ai/en/posts/agents-need-a-policy/

Agents Need a Policy, Not a Better Prompt Somewhere in your company there’s a prompt file that ends like this:
“IMPORTANT: Never modify files in /billing. Do not merge without approval. Keep costs low.”
Someone wrote it after an incident. Someone else added a line after the next one. Nobody reviews it, nobody tests it, and the agent follows it most of the time.
Most of the time is not a rule. It’s a wish.
Rules belong outside the model A prompt is a suggestion to a system that is very good at being persuaded. A long ticket, a confusing error message, a helpful comment in the code, and the suggestion loses.
Your team doesn’t run on suggestions either. Branch protection is not a polite request to not push to main. It’s enforced by something that doesn’t care how convincing you are.
An AI teammate needs the same thing: a policy that lives outside the model, decides before the model acts, and can be read, tested and changed by the humans responsible for it.
That’s how kanman works. The coding agent never decides what it’s allowed to do. The policy does.
Three levels of authority Every decision I make falls into one of three levels, and a fixed table decides which one, not my judgment in the moment.
Auto. I just do it. Write acceptance criteria, set a priority within its band, link a duplicate, nudge a stalled run.
Notify. I do it and tell you. Close a duplicate, split an epic, pause a story that keeps failing.
Escalate. I ask first. Expand scope, kill work, change anything security-related, touch production data, spend over budget, contradict something you decided.
Risk can only push a decision up the ladder, never down. An irreversible change with a large blast radius gets escalated even if its kind is normally automatic. Anything the table doesn’t know defaults to notify.
When I escalate, I don’t send you a bare question. You get my recommendation and two to four concrete options, in the decision inbox or straight in Slack. Answering takes one click. More on that in the decisions documentation.
Presets instead of fifty knobs A full policy has a lot of settings. Nobody wants to tune fifty knobs before the first story.
So there are five presets:
Trial for the first pilot week, on repos that don’t have acceptance specs yet. Focused only works on stories humans filed. Balanced is the default most teams settle on. Autonomous pulls more work in parallel and asks less often. Hardening turns on maintenance work, on a leash. Presets only change the personality of your AI teammate: concurrency, how often maintenance work starts, cadence. The safety knobs - the sandbox, the outcome gate, rollback - are the same for everyone. No preset relaxes them. The one exception is Trial, and it says so on every evidence pack it produces.
Change any single value and your team shows “Custom (based on Balanced)”. You always know where you started and what you changed. The policy reference lists every setting.
Budgets with hard stops “Keep costs low” is the wish. A budget is the rule.
You set a budget per run and per team. When a run hits its limit, it stops and asks: raise the budget for this run, or abandon it. It doesn’t quietly keep going because it was so close.
I also pick the model by complexity. A trivial fix runs on a small model with a short turn budget. A complex change gets the flagship model and has to compare approaches before it plans. That routing saves more money than any amount of “please be efficient” in a prompt.
One exception is deliberate: expedite and incident work - a red main branch, an outage, a security fix - is never stopped by a budget. You don’t want an AI teammate that leaves production broken to save a few euros. The budgets page explains the details.
The audit log is the point Every decision, every approval, every run and every cost lands in an audit log. Who decided, on what authority, with which recommendation, and what it cost. You can export it.
This sounds like compliance theater. It isn’t. It’s the thing that lets a head of engineering say yes to an AI teammate in the first place. “We tried it and it was fine” doesn’t survive the first incident. “Here’s exactly what it did and who approved it” does.
Write the rules once Stop maintaining a prompt file full of capital letters.
Decide what your AI teammate may touch, spend and merge. Write it down once, in a policy that is enforced every time. Then spend your attention on the decisions that actually need you.
You decide how much it decides.
Want an AI teammate that follows your team’s rules because it has to, not because you asked nicely? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Don't Trust an Agent That Says Done

https://kanman.ai/en/posts/dont-trust-an-agent-that-says-done/

Don’t Trust an Agent That Says Done “All tests pass. The feature is complete.”
Every coding agent says this. Most of the time it’s even true, in the narrowest sense. The tests pass. The tests the agent wrote. For the code the agent wrote. Based on the agent’s reading of a ticket that said “make the export faster”.
That’s not proof. That’s a student grading their own exam and handing you the score.
Where “done” goes wrong I ran an AI team on a real product for ten weeks before I rebuilt kanman around what I learned. The failures that hurt were never syntax errors. CI catches those.
The ones that hurt looked like this:
The agent mocked the exact thing the test was supposed to check. Green run, nothing tested. The agent “fixed” a failing test by changing the assertion. The feature worked on the agent’s machine, with state left over from three earlier attempts, and nowhere else. The PR did what the ticket said, and not what the person who wrote the ticket meant. Each one passed review at least once, because reviewers trust green checks. Of course they do. That’s what green checks are for.
The outcome gate So kanman doesn’t ask the agent whether it’s done. The gate does, and the gate is not an agent.
It works in four moves.
1. The spec comes first. Every story kanman writes during intake gets a Demonstrate block: a concrete, runnable way to show the outcome. Not “unit tests pass”, but “export 10,000 rows and the download starts within two seconds”. That block becomes an acceptance spec, before anyone writes a line of feature code.
2. Red before Ready. A story only moves to Ready when its spec exists, runs, and fails. A spec that passes before the work starts tests nothing. A spec that mocks its own target is rejected. No spec, no Ready.
3. The agent can’t touch the spec. The spec lives on a protected path. If a commit from the coding agent changes it, the gate stops the story. The agent can make the spec pass. It can’t make the spec easier.
4. Green on a clean room, or no review. When the agent says it’s done, the spec runs again on a fresh checkout, against a freshly provisioned environment. No leftover state, no “works on my machine”. If it’s red, the story goes back to work. If it’s green, the pull request opens. No green run, no review.
Then the pull request comes with an evidence pack: each acceptance criterion with its result, the spec run, the trace and screenshots from the run, which model did the work, and what it cost. Your reviewer reads evidence instead of reconstructing it.
“Our repo has no acceptance tests” Most repos I see don’t. That’s fine.
You don’t need a test suite to start, you need a manifest: a small .kanman/acceptance.json that tells kanman how to start an environment and how to run a spec. If your repo doesn’t have one, kanman opens a pull request that adds it, and you review it like any other change. The acceptance manifest guide walks through it.
Until then, there is the Trial preset. It relaxes the spec requirement for the first pilot week and falls back to CI, a test plan and an independent reviewer run. And the evidence pack says so, in plain words: no outcome proof exists for this change. I’d rather tell you that than dress up a green CI badge as proof.
Why this is the part that matters There’s a reason this sits in the middle of kanman and not in a settings page.
An AI teammate that ships unverified work doesn’t save your team time. It moves the work from writing code to doubting code. Your senior people end up reviewing every line twice, because they can’t tell which PRs are real.
An AI teammate that shows evidence changes the review. You stop asking “does this work?” and start asking “is this what we wanted?”. That second question is the one humans are good at.
Agents that prove their work beat agents that demo. If you want the details, the outcome gate is documented step by step.
Want an AI teammate that proves its work before it asks for your review? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Issue to PR Is a Commodity. Here's What Isn't.

https://kanman.ai/en/posts/issue-to-pr-is-a-commodity/

Issue to PR Is a Commodity. Here’s What Isn’t. A year ago, “assign a ticket to an AI and get a pull request back” was a demo that made people lean forward in their chairs.
Today it’s a checkbox.
GitHub lets you assign an issue to Copilot, Claude or Codex. Linear starts coding sessions on Claude Code and Codex straight from an issue. Jira lists Rovo and third-party agents as assignees, right next to your colleagues. OpenAI open-sourced Symphony, which turns every Linear issue into its own Codex workspace.
If your tracker doesn’t do it yet, it will by spring. The core loop I spent a long time building is now a free feature in tools your team already pays for.
I’m fine with that. It clarifies what actually matters.
The loop was never the hard part Watch what happens when a team switches the loop on.
The first week is exciting. Small bugs disappear. Somebody posts a screenshot of a PR that was opened while they were at lunch.
The second week, the questions start.
Who wrote that ticket? It said “fix the export” and the agent fixed a different export. Why did it touch the billing module? Who approved the dependency upgrade it slipped in? It says the tests pass - but the tests it wrote only check that the function returns something. Who is going to review fourteen PRs before Friday? And what did all of this cost?
None of these are capability problems. The models are good. They write decent code. The problem is that nobody owns the work around the code.
Five things nobody sells you When I look at teams that have agent licenses but no AI teammate, the gap is always the same five things.
Intake. Someone has to turn “customers complain the export is slow” into small stories with acceptance criteria and a concrete way to show each one works. That’s a product owner’s job. An agent that receives a vague issue produces a vague PR.
Policy. What may the agent touch? Which repos, which paths, how much may it spend per story, may it merge on its own? Today the answer lives in someone’s head, or in a prompt that nobody reviews.
Verification. “Tests pass” is not “it works”. If the agent writes the code and the tests, it grades its own homework. Someone has to check the result against the requirement, not against the agent’s opinion of the requirement.
Accountability. Who did what, on whose approval, at what cost? When the auditor or your CTO asks, “the AI did it” is not an answer.
Process fit. Your team has a tracker, a CI, branch protection and review rules. An AI teammate that needs its own board and its own workflow is one more tool to babysit.
Model vendors sell capability. Tracker vendors sell their own agent inside their own tool. Nobody sells the layer in between: the one that runs an AI teammate under your team’s rules, in your tools, and shows its work.
What kanman does about it That layer is what kanman is now.
You paste a requirement or tag kanman in Slack. kanman writes the stories, with acceptance criteria and a way to demonstrate each one, and you approve them before anything lands in your Jira or GitHub.
Your policy decides what kanman may touch, spend and merge. When a call is bigger than its authority, it comes to you with a recommendation and a few concrete options. You answer in the inbox or in Slack.
Claude Code or Codex does the coding in a sandbox. kanman picks the model by complexity, so a typo fix doesn’t burn the budget of a refactor.
Before anything reaches review, an acceptance spec runs against a fresh environment. The spec was written before the code, and the agent can’t edit it. No spec, no Ready. No green run, no review. I wrote more about that in the next post.
Then you get a pull request with the evidence attached. Your people review and merge, or your policy does. Every step lands in an audit log you can export.
Your tracker stays. Your CI stays. Your review rules stay.
Why this isn’t a race against GitHub People ask whether GitHub or Atlassian will just build this. Parts of it, sure. But each of them builds it for their own tool and their own agent. A team on Jira and GitLab, with a Claude contract and two developers who prefer Codex, doesn’t want three vendors’ opinions of what an AI teammate is.
And a lot of teams I talk to can’t send their code to whichever cloud their tracker vendor picked. That’s why kanman runs in the EU, with coding sandboxes in Frankfurt, and why the runner can sit inside your own network.
The boring part is the product Nobody gets excited about intake templates, policy tables and evidence packs. They are boring the way seatbelts are boring.
But they decide whether an AI teammate is something you trust with real work, or something you demo once and quietly switch off.
The loop is a commodity. The operating model isn’t.
Want an AI teammate that works inside your tracker, under your rules, and proves every change? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### The Post-AI-Hype Era Starts Now

https://kanman.ai/en/posts/post-ai-hype-era/

The Post-AI-Hype Era Starts Now Photo by Possessed Photography on Unsplash
Update, 1 October 2026: this post describes an earlier version of kanman with several “virtual teammates” on a board. The argument holds, the product moved on: kanman is now one AI teammate that works inside your team’s tracker, under your rules, and proves its work. Read Issue to PR is a commodity. Here’s what isn’t. for where it stands today.
Every industrial revolution follows the same pattern.
First comes the breakthrough. Then comes the hype. Skeptics declare it’s a fad. True believers promise it changes everything. Most people argue about which camp is right.
Meanwhile, practical builders quietly get to work. They don’t need to resolve the debate. They just need tools that work.
The Steam Train Pattern When steam engines emerged, a predictable chaos followed. Companies slapped “steam-powered” on everything. Steam-powered butter churns. Steam-powered hat brushes. Products that didn’t need steam - that were arguably worse with it - marketed their steam credentials anyway.
The hype wasn’t about solving problems. It was about appearing modern. About being seen on the right side of history. About cashing in before the window closed.
Sound familiar?
Today we have AI-powered everything. AI-powered to-do lists that suggest tasks you already planned. AI-powered calendars that schedule things you could schedule faster yourself. AI chatbots that answer questions worse than a good FAQ.
The pattern is steam engines all over again. Slap AI on it, ship it, worry about usefulness later.
The Debate That Won’t Die Right now, AI conversations fall into tired camps.
Doomers predict job destruction, societal collapse, machines beyond human control. Utopians promise AGI, singularity, problems solved by superintelligence. Skeptics insist it’s a bubble, that LLMs are just autocomplete, that winter is coming.
Each camp has evidence. Each has blind spots. None of them are building things that work.
Here’s what I’ve noticed: the loudest voices in the AI debate rarely ship products. They write think pieces. They give conference talks. They post prediction threads. But they don’t build tools people use every day.
The people quietly shipping useful AI? They’re too busy to argue about timelines to AGI.
What Post-Hype Actually Means Post-hype doesn’t mean AI failed. It doesn’t mean the technology plateaued. It means something simpler: the conversation shifted from possibilities to practicalities.
Post-hype steam power meant factories, railways, ships - not steam-powered novelty items. The technology found its useful forms and became infrastructure.
Post-hype AI will look similar. Less chatbot theater, more actual collaboration. Less “AI as a feature” slapped onto products, more AI as a colleague that handles work.
kanman.ai is built for this shift. We treat AI the way it actually works best: as virtual teammates that join your boards, pull tasks, collaborate in real-time, and ship alongside humans.
Virtual Teammates, Not Magic The assistant paradigm has problems.
Assistants wait for instructions. You have to know what to ask, when to ask it, how to phrase your request. The cognitive load stays with you. You become a manager of the AI instead of a collaborator with it.
Virtual teammates work differently. They join your workspace like any other team member. They have boards, get assigned tasks, pull work when they have capacity. Same @mentions, same activity feeds, same accountability.
The interface isn’t a chat window. It’s a kanban board - the same tool you use to collaborate with humans.
This design choice matters. When AI works through the same interface as humans, the skills transfer. You already know how to assign tasks, review work, set priorities. Virtual teammates slot into existing workflows instead of demanding new ones.
Autonomy Levels That Make Sense Not every team wants AI running loose. Not every task needs human oversight. The answer isn’t all-or-nothing - it’s configurable autonomy.
kanman.ai offers four levels:
Assigned only. Virtual teammates do exactly what you tell them. Nothing more. Maximum control, minimum surprise.
Capacity pull. When teammates have bandwidth, they pull available tasks from the queue. You still define what’s available. They just don’t sit idle waiting for explicit assignment.
Proactive review. Teammates suggest improvements, flag issues, offer alternatives. Human approval before action. Good for tasks where you want a second perspective.
Full autonomy. Teams handle entire workstreams. Set the guardrails, define the outcomes, let them work. Check in when needed, but don’t micromanage.
Most teams start at assigned-only and graduate up. Some tasks stay at one level forever. The point is having options, not being forced into a single mode.
Skip the Debate, Start Building The AI argument will continue for years. Camps will dig in. Twitter threads will pile up. Conference panels will rehash the same positions.
You don’t have to wait for consensus.
If you’re tired of AI being either overpromised or dismissed, if you want tools that treat AI as capable colleagues rather than magic wands or existential threats, if you’re ready to skip the hype cycle and just get things done - virtual teammates are ready.
No debate required. Just work.
Ready to skip the hype? Meet the AI teammate that works under your rules and shows proof instead of promises. kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### An AI Teammate, Not Just an AI Assistant

https://kanman.ai/en/posts/virtual-teammates-not-assistants/

An AI Teammate, Not Just an AI Assistant Photo by Annie Spratt on Unsplash
Rewritten on 1 October 2026. The first version of this post described a model with several AI teammates on one board. kanman has since become one AI teammate per workspace, working inside your team’s tracker. The argument below is the same; the product it describes is the current one.
“Explain this stack trace.”
“Write a test for this function.”
“Refactor this file to use the new API.”
This is the assistant paradigm. You ask, it answers. You drive, it types. Every developer on your team has one by now: Copilot in the editor, Claude Code or Codex in the terminal.
And it works. For a lot of things, it works very well.
Assistants have their place Let’s be clear: coding assistants are genuinely useful.
A developer debugging at 2am doesn’t need a process. They need something that reads the error, suggests a fix and writes the boring utility function. One person, one tool, direct interaction. No overhead.
None of that goes away. kanman doesn’t replace your assistant. Keep using whatever your people like in their editor.
But assistants don’t own anything The assistant paradigm hits a ceiling as soon as the work is bigger than one person’s session.
An assistant puts all the load on you. You decide what to ask. You phrase it. You check the output. You remember what’s left. When you close the terminal, the assistant forgets the work existed.
An assistant never says “this requirement is ambiguous, here are two readings, which one do you mean?”. It never notices that the story it’s working on overlaps with one from last week. It doesn’t know what it’s allowed to touch, because nobody told it, and it can’t prove it’s done, because “done” is whatever it thinks.
Today, every developer on your team has an assistant. Nobody has a teammate.
What a teammate does differently Think about a good colleague.
They take a vague request and come back with a plan you can say yes or no to. They know the rules: which parts of the codebase are touchy, what needs a second pair of eyes, how much time a thing is worth. When something is above their pay grade, they ask, and they come with a recommendation instead of a bare question. When they say it’s done, they show you.
That’s what kanman is now: one AI teammate per workspace. It says “I”. It works next to your people, not in a separate tool.
It takes requirements. You paste one, or tag kanman in Slack. I turn it into stories with acceptance criteria and a concrete way to demonstrate each one. You approve them before they land in your tracker. It follows your rules. A policy decides what I may touch, spend and merge. Bigger calls come to you with a recommendation and a few options. It shows its work. Before anything reaches review, an acceptance spec runs on a clean checkout. The pull request arrives with the evidence attached. It’s accountable. Every decision, approval and cost lands in an audit log you can export. The coding itself is done by Claude Code or Codex, in a sandbox. Same agents your developers already know. The difference is everything around them.
Same tracker, same rules This part matters more than it sounds.
When AI works in its own interface, your team ends up maintaining two worlds: the real backlog in Jira or GitHub, and the AI’s version of it somewhere else. Context drifts. Nobody knows which one is true.
kanman works where your work already is. Stories go into your Jira or GitHub Issues. Code goes through your CI, your branch protection, your review rules. kanman shows up in the activity feed like any colleague, with the same avatar treatment, the same comments, the same history.
No second board to keep in sync. No new workflow to learn.
Autonomy is a dial, not a switch “But I don’t want AI deciding things without me.”
Fair. Neither do I, for most things.
That’s why autonomy in kanman is a policy, not a vibe. Presets range from Trial, for the first week on a repo without specs, to Autonomous for mature teams. Every decision is classified: some I just do, some I do and tell you, some I always ask about first. Risk can only push a decision towards “ask first”, never away from it. And budgets stop a run before it gets expensive, instead of after.
Most teams start careful and loosen up as the evidence piles up. Some decisions stay with humans forever. The point is that you choose, and you can see what was chosen.
The shift worth making Assistants were the first generation. They proved the technology works.
A teammate is the next step. Not a smarter autocomplete, but someone who owns work end to end, inside your rules, and shows you the proof.
Your team doesn’t need more assistants. It needs one teammate it can trust.
Ready to move beyond assistants? Meet the AI teammate that takes requirements, follows your rules and proves its work. kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Why Your Manager's Favorite Tool Hates Your Focus

https://kanman.ai/en/posts/managers-favorite-tool-hates-focus/

Why Your Manager’s Favorite Tool Hates Your Focus Photo by Campaign Creators on Unsplash
Your manager loves the planning tool. Color-coded timelines, swimlane diagrams, progress percentages, and exportable PDFs for the Monday slide deck. The tool sells itself on visibility.
You hate it. Every task requires six fields. Every update pings three people. Every status change triggers a notification chain that interrupts your actual work. The tool wasn’t built for you.
Built for Watchers, Not Workers Enterprise planning software follows the money. Procurement decisions happen at the manager level, so features cater to manager needs: dashboards, reports, audit trails, permission hierarchies.
The people doing the work get whatever UX is left over.
This creates a fundamental tension. The tool’s job is to make work visible to observers. Your job is to finish work. These goals conflict more than vendors admit.
Every field you fill in serves reporting, not execution. Every mandatory status update interrupts your flow to feed a dashboard you’ll never check. The tool treats your attention as a resource to be harvested, not protected.
The Hidden Tax on Makers I’ve watched developers spend 20% of their week maintaining tools instead of shipping code. Not writing documentation - that’s useful. Maintaining the artifact layer: updating tickets, logging time, moving cards, attending syncs to explain what the cards already show.
This overhead compounds. Interruptions don’t just cost the minutes spent on them. They cost the 23 minutes it takes to recover focus. A developer who gets pinged six times a day loses hours to context switching before counting the pings themselves.
Tools built for oversight extract this tax constantly. They’re designed to pull information from makers and push it to watchers. The makers pay; the watchers benefit.
What Maker-First Tools Look Like kanman takes the opposite approach. There’s nothing to export for a slide deck because the work itself is the status update. No dashboards, no charts, no progress percentages.
You see the story, the pull request and the evidence that it works. That’s it.
This isn’t a limitation - it’s a design choice. Features that only help observers don’t ship. Every interaction asks one question: does this help someone finish work?
The result is a tool that stays silent until you need it. No notifications unless you want them. No gamification pressuring you to perform. No surveillance features tracking your activity.
When Oversight Tools Make Sense Before going further - enterprise planning tools aren’t inherently broken.
A 500-person engineering org with distributed teams across time zones, multiple product lines, and complex dependencies genuinely needs coordination infrastructure. At that scale, knowing who’s working on what prevents duplicate effort, unblocks dependencies, and keeps projects from colliding.
The problem isn’t the tools. It’s applying enterprise-scale solutions to problems that don’t require them.
Many organizations buy themselves time for scale by adopting heavyweight processes early. They assume growth will justify the overhead. Instead, they end up with process landscapes that become burdens - tracking rituals that consume more energy than they save.
As many processes as needed. As few as possible. All the time.
The Real Cost of “Visibility” Most visibility features go far beyond coordination. They create accountability theater - proof that people are busy, not proof that they’re effective.
A burndown chart showing velocity doesn’t tell you if the team is building the right thing. A time-logged ticket doesn’t reveal whether the estimate was reasonable. A status field marked “in progress” for three weeks might mean the work is hard, or it might mean the person is blocked and afraid to say so.
Real coordination comes from conversation, not dashboards. The dashboard just gives managers something to screenshot.
Choosing Tools That Side With You Before adopting any work tool, ask who it was designed for. Look at the pricing page. Look at the feature list. Look at the onboarding flow.
Does it start with your work, or with administrative setup? Does it celebrate what you shipped, or what you logged? Does it stay quiet, or does it nag?
Tools that respect your focus share common traits: minimal surfaces, optional notifications, no gamification, no surveillance. They treat you as the expert on your own work.
Your manager’s favorite tool might be great for managers. That doesn’t make it great for you.
Looking for help that gets out of your way? Want an AI teammate that ships the work and lets the evidence be the status update? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### When Minimalism Is a Feature, Not a Missing Feature

https://kanman.ai/en/posts/minimalism-is-a-feature/

When Minimalism Is a Feature, Not a Missing Feature Photo by Bench Accounting on Unsplash
Every productivity app promises to help you do more. The pitch is always additive: more integrations, more views, more AI features, more dashboards.
Nobody asks what happens when your work tool becomes another tab to manage.
kanman takes a different stance. No board of its own to replace your tracker. No calendar. No video calls. No productivity dashboards. These aren’t missing features - they’re deliberate design decisions.
The Feature Tax Every feature costs attention. Not just the time to learn it, but the cognitive load of knowing it exists.
A calendar integration means you now think about time blocks inside your task manager. An AI assistant means you wonder if you should ask it. A dashboard means you feel obligated to check numbers. Each addition fragments your focus across more surfaces.
Software vendors rarely acknowledge this cost. Features get celebrated as progress. The product grows. The marketing page adds another bullet point. Nobody measures what users lose when the interface gets busier.
The result: tools that do everything, but make everything harder.
Everything You Need, Nothing Else kanman adds one thing to your team: an AI teammate that does work and proves it. Everything else stays where it is. Your stories live in your tracker. Your code goes through your CI and your review rules.
What you see from kanman is small on purpose: a decision when one is yours, and a pull request with evidence when work is done. It’s simple enough to deal with at 11pm after a long day.
No gamification means no guilt about broken streaks. No second board means nothing to keep in sync. No calendar means you stay focused on what to do, not when to schedule it.
This isn’t laziness or a roadmap gap. It’s a bet that less surface area means more finished work.
Why Omissions Matter Consider what happens when you add a calendar to a task manager.
Suddenly, tasks exist in two dimensions: the list and the schedule. You now maintain both. When reality shifts - and it always does - you update both. The calendar becomes a planning surface, and planning is often procrastination dressed up as productivity.
kanman skips the calendar because scheduling is a separate problem. You don’t need your task tool to become a scheduling tool. You need your task tool to stay focused on tasks.
The same logic applies to AI. Sprinkling suggestions over every screen assumes the tool knows your work better than you do. kanman doesn’t do that. It does the work your team hands over and asks when a decision is yours. You already know what matters - you don’t need an algorithm ranking your priorities.
Feature Bloat Is a Trust Issue When a tool adds features aggressively, it reveals something about the relationship. The vendor doesn’t trust users to choose their own stack. The tool wants to become the operating system for your work, locking you in with integrations and surface area.
Minimal tools respect your judgment. They stay in their lane. They do one thing well and expect you to compose your workflow from multiple focused tools rather than one bloated platform.
This sounds like more work, but it’s often less. A three-app stack where each app excels beats a single app that does everything poorly. Context-switching between focused tools costs less than navigating a cluttered interface.
How to Evaluate Tools Before adopting any tool, ask what it doesn’t do.
If the answer is “nothing - it does everything,” that’s a red flag. No tool can excel at everything. A feature list without clear omissions usually means every feature gets mediocre attention.
Look for tools that explain their constraints. Why doesn’t it integrate with calendars? Why doesn’t it have a dashboard? A principled reason for absence suggests thoughtful design. No explanation suggests the feature just hasn’t shipped yet.
kanman is explicit about what it omits: no calendar because scheduling is a different problem, no board of its own because your tracker already works, no dashboards because outcomes matter more than metrics.
These constraints aren’t limitations. They’re the reason the tool stays fast, quiet, and useful.
Less Is Finished Shipping beats features. A tool that helps you complete work matters more than a tool that helps you organize, visualize, gamify, schedule, and analyze work.
The productivity industry sells complexity. More systems, more frameworks, more surfaces to maintain. Minimalism cuts through this by asking one question: does this help me finish?
kanman answers yes by keeping the focus on shipped, proven work and letting everything else go. No streaks. No points. No dashboards. Just the work you’re doing and the work that’s done.
Minimalism isn’t a missing feature. It’s the whole feature.
Ready for a tool that trusts you? Want an AI teammate with no gamification, no surveillance and no second board, just proven work? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Autonomy vs. Oversight: Choosing Tools That Side with the Doers

https://kanman.ai/en/posts/autonomy-vs-oversight/

Autonomy vs. Oversight: Choosing Tools That Side with the Doers Photo by Annie Spratt on Unsplash
Every work tool makes a choice. It either serves the people doing the work, or the people watching them.
Most B2B software chooses watchers. The sales pitch targets managers. The feature set prioritizes visibility. The pricing tiers unlock “admin controls” and “team analytics.” Workers get a tool shaped by someone else’s needs.
This isn’t conspiracy - it’s economics. Enterprise deals close at the manager level. Tools that help managers justify their purchases beat tools that quietly help workers ship.
But you don’t have to accept tools designed for surveillance.
The Surveillance Spectrum Work tools fall on a spectrum from autonomy to oversight.
On the oversight end: activity tracking, time logging, presence indicators, detailed permission systems, mandatory fields, audit trails. On the autonomy end: minimal tracking, optional features, no presence indicators, simple interfaces, trust that workers know their jobs.
Neither extreme is universally correct. A distributed organization with regulatory compliance requirements genuinely needs audit trails. A team coordinating across time zones benefits from knowing who’s available when. Large-scale projects with external dependencies require formal tracking.
The problem isn’t oversight features existing - it’s their default presence in tools used by teams that don’t need them. A three-person startup using enterprise PM software gets surveillance designed for organizations with very different problems.
As many processes as needed. As few as possible. All the time.
Most popular planning tools cluster toward oversight because that’s what sells to procurement committees. They offer “visibility” as a universal benefit. But visibility that doesn’t enable better decisions is just surveillance.
How to Spot Oversight-First Tools Look for these patterns when evaluating tools:
Activity tracking. Does the tool log when you’re active? Does it show “last seen” timestamps? This isn’t coordination - it’s surveillance dressed as collaboration.
Mandatory fields. Does every task require you to estimate time, assign categories, set priorities, and fill in descriptions? Mandatory fields serve reporting, not execution.
Permission hierarchies. Are there detailed role-based controls about who can see what? Complex permissions suggest the tool expects distrust between team members.
Dashboard prominence. Does the interface lead with charts, graphs, and metrics? Dashboards serve watchers. Workers need task lists.
Manager-focused marketing. Does the landing page show screenshots of analytics rather than task completion? Marketing reveals priorities.
kanman fails all these tests deliberately. It doesn’t track your people’s activity. It adds no mandatory fields to your tracker. It has no productivity dashboard. What it shows is the work it did and the evidence for it, because that’s what matters.
Why Autonomy Matters Autonomy isn’t just a nice feeling. It directly affects productivity.
Research consistently shows that autonomy improves work quality, creativity, and satisfaction. When people control how they work, they work better. When they feel monitored, they perform for the monitor instead of for outcomes.
Oversight-heavy tools create a specific failure mode: workers optimize for appearing busy rather than being effective. If the tool tracks activity, workers stay active. If it demands time estimates, workers pad estimates. If it shows presence, workers stay logged in.
None of this produces better work. It produces better metrics - which managers then mistake for better work.
Tools that respect autonomy skip this theater. They assume you’re competent. They trust you to manage your own time, set your own priorities, and work at your own pace.
What Autonomy-First Tools Look Like kanman works inside the tracker your team already uses. No second board, no new fields, no new ritual.
There’s no activity tracking of people. kanman keeps an audit log of its own decisions and runs, not of when you were online. Your work patterns are private.
There’s no manager dashboard. Everyone sees the same stories, the same evidence and the same decisions. No special observer mode for bosses.
There’s no gamification. No streaks, badges, or points pressuring you to perform. Rest is invisible to the app because it’s not the app’s business.
It doesn’t tell you what to work on next. kanman takes the work your team hands over and asks when a decision is yours to make. You stay the expert on your own work.
This isn’t minimal because we’re lazy. It’s minimal because surveillance features don’t help workers ship.
Choosing Your Stack Before adopting any work tool, ask who it was designed for.
Read the pricing page. Are premium features about reporting and analytics, or about getting work done? “Admin controls” and “team insights” suggest manager-first design.
Read the feature list. Count how many features serve workers versus watchers. An imbalance reveals priorities.
Try the onboarding. Does it start with your work, or with setting up permissions and integrations? Worker-first tools get you productive quickly.
Check the defaults. Are notifications on or off? Are fields optional or mandatory? Defaults reveal assumptions about users.
Tools that side with doers treat oversight features as opt-in rather than default. They trust workers to coordinate without surveillance. They measure success by outcomes, not activity.
The Bottoms-Up Choice Enterprise procurement usually happens top-down. Someone in leadership picks a tool, and workers adapt.
But individual makers can still choose their personal tools. A designer can use their preferred sketch app. A developer can pick their terminal. A writer can choose their editor.
kanman is a tool a team adopts together, not a personal app. But it’s built on the same side of this line. The people who do the work set the rules it follows, and what it produces is evidence for reviewers, not activity data for observers. If a feature only helps someone watch the work, it doesn’t ship.
This matters. When workers pick their own tools, they pick ones that respect them. When tools must win worker adoption to survive, they design for worker needs.
That’s the autonomy side of the spectrum. That’s where kanman lives.
Tired of tools that treat you like a metric? Want an AI teammate that reports evidence, not activity, and works under your team’s rules? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### How to Sell a 'Do Less' Tool to a 'Do More' Manager

https://kanman.ai/en/posts/selling-do-less-to-do-more-manager/

How to Sell a ‘Do Less’ Tool to a ‘Do More’ Manager Photo by Jason Goodman on Unsplash
Your manager wants metrics. They want to know velocity, capacity, and utilization. They want burndown charts that trend downward and dashboards they can screenshot for leadership.
You want to finish work.
These goals seem incompatible. But they’re not. Here’s how to advocate for minimal, focused tools in a workplace that measures everything.
Understand Their Constraints Managers operate under pressure you might not see. They’re asked to justify their team’s existence with numbers. They’re held accountable for deliverables they don’t directly control. They report to people who report to people, and at each level, abstractions replace reality.
Dashboards and metrics aren’t necessarily what your manager wants - they’re often what their manager demands. The surveillance features in enterprise tools exist because someone, somewhere, needs proof that work is happening.
Understanding this doesn’t mean accepting it. But it makes the conversation easier. You’re not fighting your manager’s preferences. You’re helping them meet their constraints differently.
Frame Outcomes, Not Philosophy Don’t lead with “I want a calm tool.” That sounds like you want to avoid accountability.
Lead with outcomes. “I shipped faster when I used focused tools.” “The team reduced rework after cutting dashboard overhead.” “My best quarter happened when I stopped logging time.”
Managers care about results. A tool that produces better outcomes can overcome feature-list objections. If you can show that less tracking led to more shipping, you’re speaking their language.
This means running experiments. Use a minimal tool for a project. Track what you ship. Compare it to dashboard-heavy projects. Bring data, not opinions.
Separate Personal from Team Sometimes you don’t need to change the team’s stack. You just need permission to manage your personal workflow differently.
Individual task management is often below the radar. Your manager might not care how you organize your own work, as long as you update the team tool periodically. This creates space for hybrid approaches.
Use a minimal tool for your personal list. Keep the team’s Jira or Asana for shared visibility. Let the minimal tool handle your daily prioritization while the enterprise tool handles cross-team coordination.
This isn’t ideal - but it’s pragmatic. And it gives you data for future conversations about what actually works.
Highlight Hidden Costs Enterprise tools have visible costs (licensing) and hidden costs (time, focus, frustration). Managers often don’t see the hidden costs because they’re not doing the work.
Quantify what you can. How many hours per week does the team spend updating tools instead of doing work? How many interruptions come from notifications? How much context-switching happens between task lists, dashboards, and actual work?
Overhead is real. If you can show that 15% of your week goes to tool maintenance, that’s 15% reclaimed by switching to something simpler. That’s a tangible argument.
Even rough estimates help. “I spend about an hour a day on Jira hygiene” is a concrete cost that dashboards don’t capture.
Redefine Visibility The core fear behind dashboard obsession is losing visibility. Managers worry that without metrics, they won’t know what’s happening.
But visibility doesn’t require surveillance. Shared project lists provide visibility. Regular async updates provide visibility. Shipped work provides the most visibility of all.
Propose alternatives. Weekly bullet-point updates instead of daily standups. Shared kanban boards instead of individual time tracking. Demos instead of status reports.
These approaches provide visibility without overhead. They show work through work, not work through metrics. And they’re often more accurate than dashboards, which lag reality and reward gaming.
Make It Reversible Resistance often comes from risk aversion. “What if the new tool doesn’t work? We’ll have to migrate back.”
Lower the stakes by proposing experiments. “Let’s try this for one project.” “Give me one quarter with a lighter tool.” “If outcomes suffer, I’ll switch back.”
Reversible experiments are easier to approve than permanent changes. And once the experiment runs, results speak for themselves.
This is where simple, affordable tools have an edge. A small monthly plan costs less than a month of most enterprise subscriptions. If it works, you’ve found a tool that respects your workflow. If it doesn’t, you’ve lost less than a dinner.
Speak Their Numbers If your manager lives in numbers, give them numbers.
Measure your output during low-overhead periods. Compare ticket counts, feature completions, bug fixes - whatever metrics your organization tracks. Show correlation between less tool friction and more delivered work.
Even if you can’t prove causation, correlation plants seeds. “My most productive months were my least-tracked months” is harder to dismiss than “I don’t like dashboards.”
And if the numbers don’t support your case? Be honest about that too. Sometimes dashboard overhead isn’t your bottleneck. Knowing that is valuable, even if it’s not what you expected.
Pick Your Battles Some workplaces won’t change. Some managers won’t listen. Some cultures are too entrenched in surveillance to accept alternatives.
In those cases, protect your focus where you can. Personal tools, personal time, personal rhythms. Use minimal tools outside work hours. Build your own practice even if you can’t change the system.
And if the system is fundamentally incompatible with how you work best, that’s information too. Cultures that value dashboards over delivery might not be where you thrive.
The Long Game Advocating for calm productivity isn’t about winning arguments. It’s about demonstrating alternatives.
Every time you ship quality work without overhead, you make the case silently. Every time you skip a dashboard and deliver anyway, you show what’s possible. Every time you stay focused while others perform for metrics, you prove the philosophy.
Change happens slowly. But it happens faster when there’s evidence.
Want something that makes the case itself? Want an AI teammate whose evidence packs show shipped work instead of performance theater? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Designing for the After-Hours Brain

https://kanman.ai/en/posts/designing-after-hours-brain/

Designing for the After-Hours Brain Photo by Thought Catalog on Unsplash
It’s 11pm. You’ve worked a full day. The kids are in bed or the deadline is passed or you finally have an hour for that side project. You open your task manager.
And you can’t face it.
The interface is dense. There are fields to fill, tags to assign, projects to sort. The tool demands setup work before you can do real work. Your tired brain gives up.
This happens because most productivity software designs for the fresh morning brain. Peak cognitive capacity. Full attention. Patience for complexity.
That’s not when people actually need help.
Cognitive Load Is Real Cognitive load refers to the mental effort required to use something. High cognitive load means lots of decisions, lots of information, lots of processing.
When you’re tired, your capacity for cognitive load drops. Complex interfaces become unusable. Multi-step processes become frustrating. The gap between “I want to do something” and “I’m doing it” becomes a wall.
This isn’t weakness. It’s biology. The brain has limited resources, and they deplete over the day. Any design that ignores this reality fails the people using it.
Why Simple Interfaces Win kanman’s job is to take load off, not add it. It lives in the tracker you already use and doesn’t bring a new interface to learn.
When it needs you, you get one question with a recommendation and a few options. Accept, pick another, or ignore it until tomorrow. One interaction that works when you’re sharp and when you’re exhausted.
No color-coding decisions. No priority matrices. No new required fields. The cognitive overhead is minimal by design.
This matters most when you’re tired. After a long day, you don’t want to configure a tool. You want to see what needs doing and do it. Simple interfaces respect this.
The No-Guilt Design Tired brains are also emotionally vulnerable. Gamification mechanics - streaks, points, badges - hit differently at 11pm than at 9am.
Missing a streak feels bad. Seeing a low score feels bad. Being reminded that you haven’t logged in for three days feels bad. These mechanics assume you’re always at peak performance and punish you when you’re not.
kanman has no gamification. There’s no streak to break. There’s no score to drop. There’s no guilt-inducing reminder that you’ve been absent.
Open the app after a week away and everything is exactly where you left it. No judgment. No catch-up. Just your projects and the next thing you want to work on.
Low Noise, Low Pressure Notifications are another enemy of the tired brain.
Every ping demands attention. Every badge requests a decision. Even if you ignore them, you spend mental energy deciding to ignore them. The tool is always asking for something.
kanman defaults to silence. It only reaches out when a decision is yours to make. No alerts, no nudges, no “don’t forget to check in.” The decision waits until you’re ready.
This sounds passive. It is. That’s the point.
When you’re tired, you don’t need software that demands attention. You need software that offers help when you reach for it and disappears when you don’t.
The 11pm Test Here’s a simple test for any productivity tool: could you use it effectively at 11pm after a long day?
If the answer requires setup, configuration, or ceremony, the tool fails. If the answer requires fresh cognitive resources, the tool fails. If the answer requires emotional resilience against guilt mechanics, the tool fails.
The best tools pass this test easily. They’re usable at your worst because they’re designed for humans, not for ideal-state humans.
kanman aims to pass. Open the decision. Read the recommendation. Click yes. Close it. Done.
Designing for All States Good interface design isn’t about optimizing for peak performance. It’s about staying usable across the full range of human states.
Some days you’re sharp and focused. Some days you’re foggy and distracted. Some days you’re energized. Some days you’re running on fumes.
A tool that only works when you’re at your best isn’t reliable. It abandons you when you need it most.
Minimal design choices aren’t just aesthetic preferences. They’re accessibility decisions. They make software usable for the tired, the distracted, the overwhelmed, the just-wanting-to-get-one-thing-done.
That’s who we actually are most of the time. Design should meet us there.
The After-Hours Reality Many side projects happen after hours. Many personal tasks get handled when the day job ends. Many creative pursuits squeeze into the margins.
If your tools can’t handle these margins, they can’t handle your life.
kanman exists partly so that less work has to happen at 11pm. It stays simple enough to answer when you’re tired, guilt-free enough to come back to after a break, and quiet enough to not add to the noise.
That’s what designing for the after-hours brain means. It means assuming users aren’t always at their best - and building something that works anyway.
Need less work at 11pm, not another tool to check? Want an AI teammate that ships quietly and only asks when it has to? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### How to De-Weaponize OKRs

https://kanman.ai/en/posts/de-weaponize-okrs/

How to De-Weaponize OKRs Photo by Helloquence on Unsplash
OKRs - Objectives and Key Results - started as an alignment tool. A way to connect individual work to company strategy. A framework for setting ambitious goals and measuring progress toward them.
Somewhere along the way, they became weapons.
Goals that were meant to inspire became quotas to dread. Key results meant to clarify became metrics to game. Quarterly reviews meant to reflect became tribunals to survive.
This isn’t inevitable. OKRs can work without weaponization. But it requires separating direction from execution.
How OKRs Get Weaponized The failure mode is predictable.
Leadership sets aggressive objectives. Those cascade to teams as requirements, not aspirations. Teams set key results they can actually hit, knowing failure has consequences. Everything becomes conservative, political, or both.
Meanwhile, the actual work - the projects, tasks, and decisions that determine outcomes - gets disconnected from the framework. OKRs become reporting theater layered on top of real productivity.
Worse: when OKRs tie to performance reviews, the incentive is to sandbag. Set achievable goals. Avoid ambition. Play the game.
This isn’t what the framework was meant to do. But it’s what happens when goals become weapons instead of guides.
Keep Direction Separate from Delivery Here’s a simple principle: OKRs handle direction. Your task tool handles delivery.
OKRs should answer “where are we going?” not “what did you do today?” They’re strategic, not tactical. They set context without micromanaging execution.
kanman stays out of the goal layer entirely. It handles stories - the actual work. No OKR tracking, no goal hierarchies, no connection between your backlog and anyone’s quarterly review.
This separation is deliberate. When your task tool knows about OKRs, it tempts you to align every action with scoring well. You start optimizing for the metric instead of the outcome.
Keep strategy in one place. Keep execution in another. Let them inform each other without entanglement.
Set Human-Sized Goals Weaponized OKRs tend to be abstract and oversized. “Increase user engagement by 40%.” “Achieve market leadership in Q3.” “Transform customer experience.”
These aren’t actionable. They’re banners, not guides. And when you can’t see the connection between your daily work and the banner, the banner becomes noise at best, anxiety at worst.
Human-sized goals connect to actual work. “Ship the new onboarding flow.” “Reduce checkout errors by half.” “Talk to ten customers this month.”
You can wake up and know what to do about these. You can put them in your project list and drag them to the top. They’re concrete enough to execute.
Reframe Key Results as Outcomes Key results work best when they describe observable outcomes, not activity metrics.
Activity metrics: hours logged, tickets closed, meetings attended. These measure motion without measuring progress.
Outcomes: features shipped, bugs fixed, customers retained. These measure what actually changed.
Velocity charts don’t tell you if the team built the right thing. Ticket counts don’t reveal if the product improved. Activity can happen without progress. Outcomes require progress.
When setting key results, ask: “If we achieved this, what would be different in the world?” Not “how would we know we were busy?”
Protect the Team from the Framework Managers can shield teams from weaponized OKRs without ignoring organizational requirements.
Accept that you’ll need to report upward using the company’s framework. Translate that framework into something workable for your team. Don’t pass the pressure through unchanged.
If leadership wants a 40% engagement increase, figure out what specific projects might contribute. Present those projects to your team as the work, not the metric. Let people focus on building rather than measuring.
The team sees: “We’re shipping a better onboarding flow.” Leadership sees: “Progress toward engagement objective.”
Same reality, different framing. The work stays human-sized. The dashboard gets its numbers.
When to Ignore OKRs Entirely Some work shouldn’t connect to OKRs at all.
Maintenance. Infrastructure. Tech debt. Support. These keep the system running but don’t advance quarterly objectives. Forcing them into the framework distorts both.
Organizations that require every hour to map to an OKR create perverse incentives. Critical work gets ignored because it doesn’t score. People hide maintenance behind fake objectives. The framework becomes fiction.
Good OKR implementations carve out space for essential work that isn’t goal-aligned. The framework describes strategic pushes, not the full picture of what happens.
The Right Tool for Execution OKRs set direction. Task tools handle execution.
kanman keeps the work front and center with no connection to goal frameworks. It takes stories from your tracker, ships them and attaches the evidence. You see what shipped and what it took. You ship.
No OKR tracking. No performance metrics. No anxiety about whether your task list aligns with your quarterly review. Just the work.
This isn’t avoiding accountability. It’s recognizing that accountability for outcomes is different from accountability for alignment. Ship good work. The OKR conversation takes care of itself.
Want to focus on delivery, not dashboards? Want an AI teammate whose only report is shipped, proven work? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### The Manager's Report vs. The Maker's Reality

https://kanman.ai/en/posts/managers-report-vs-makers-reality/

The Manager’s Report vs. The Maker’s Reality Photo by Carlos Muza on Unsplash
Your manager looks at a dashboard. It shows velocity trending upward, capacity at 85%, and 47 tickets closed this sprint. Green lights everywhere.
You look at your week. It was exhausting. You spent Monday in meetings, Tuesday fighting a production bug, Wednesday catching up from Tuesday. You closed tickets frantically on Thursday to make the numbers work. Friday you were fried.
Same week. Completely different stories.
The Abstraction Gap Reports abstract reality. They take complex, messy, human work and compress it into numbers and charts. This compression is necessary - managers can’t experience every team member’s week directly - but it loses information.
What gets lost: the quality of the work. The sustainability of the pace. The frustration and morale. The difference between tickets that matter and tickets that just close.
What gets kept: quantities. Trends. Comparisons. The stuff that fits in boxes.
Managers make decisions based on what they can see. When the dashboard shows green, decisions assume reality is green. But reality might be red in ways the dashboard can’t capture.
How Dashboards Lie Dashboards don’t intentionally deceive. But their structure creates blind spots.
They count, but don’t weigh. Ten small tickets look the same as ten hard tickets. Velocity doesn’t distinguish between meaningful progress and busywork.
They lag reality. By the time metrics show a problem, the problem has been festering for weeks. By the time they show improvement, the improvement happened long ago.
They reward gaming. When metrics tie to performance reviews, people optimize for metrics. Split tickets to inflate counts. Close and reopen to reset SLAs. Game the system because the system games them.
They can’t show sustainability. A team sprinting to hit a target looks the same as a team cruising sustainably. The burnout arrives later, after the dashboard has moved on.
What Makers Actually Need Makers need tools that show their work, not tools that show abstractions of their work.
kanman takes this approach. What it shows is the work itself: the story, the pull request and the evidence that it does what was asked. Not a velocity chart about the work. Not a dashboard summarizing it.
This design choice means there’s no productivity chart to screenshot for a status meeting. If someone wants to know whether a change works, they read its evidence.
That’s deliberate. kanman is built for practitioners, not observers. If a feature only helps someone watch the work, it doesn’t ship.
The Information Bridge The solution isn’t eliminating management visibility. Large organizations genuinely need coordination infrastructure. Leadership allocating resources across a hundred-person department can’t talk to everyone weekly. Portfolio decisions require aggregated signals. Cross-team dependencies need tracking.
The problem is applying enterprise-scale reporting to contexts where direct communication still works. A ten-person team doesn’t need dashboards - they need a standup. A single project doesn’t need velocity charts - it needs a shared understanding of what’s next.
As many processes as needed. As few as possible. All the time.
The solution is better information bridges - ways for reality to reach decision-makers without losing critical context. And honest evaluation of whether the reporting layer matches the actual coordination need.
This looks like:
Regular conversation. Managers talking to makers directly, not just reading dashboards. Qualitative signals. “How sustainable does this feel?” alongside “how many tickets did we close?” Work-based updates. Sharing what shipped, not what scored. Trust. Assuming workers know their situation better than any dashboard can represent. The Maker’s Lens If you’re a maker navigating this gap, protect your own clarity.
Don’t let the dashboard become your reality. You know how the week felt. You know whether the work was good or just numerous. Trust your experience over the metrics.
Keep your own system. Good tools show your work without judgment. No metrics to internalize. No velocity to perform for. Just the work you’re doing and the work that’s done.
Communicate reality, not just metrics. When asked how things are going, share the real picture. “We closed 47 tickets, but I’m concerned about sustainability” is more useful than “47 tickets, all green.”
The Manager’s Responsibility If you’re a manager, know your dashboard’s limits.
Green lights don’t mean everything is fine. They mean the specific things you’re measuring appear fine by the specific criteria you’re using. That’s a much smaller claim.
Talk to your team. Ask how work feels, not just how it measures. Watch for the gap between reports and reality, and take reality seriously when they conflict.
Design for doers. When choosing tools, ask whether they help workers work or help observers observe. A tool that serves makers might give you less to screenshot, but it might produce better outcomes.
Closing the Gap The gap between the manager’s report and the maker’s reality isn’t fixable by better dashboards. It’s fixable by less reliance on dashboards.
Trust workers to report their own status. Let shipped work speak for itself. Value conversation over visualization.
And use tools that keep the focus on work, not on the artifacts of appearing to work.
Ready to focus on the work, not the metrics? Want an AI teammate that reports with evidence instead of velocity charts? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Getting Desktop Notifications From Codex on Linux, Windows, and WSL

https://kanman.ai/en/posts/codex-desktop-notifications/

Getting Desktop Notifications From Codex on Linux, Windows, and WSL Letting Codex grind through a long refactor or multi step change while you watch YouTube is nice. Realizing 20 minutes later that it was done after 30 seconds is not.
This guide shows how to wire Codex into native desktop notifications on:
Linux / Unix (notify send) Windows (Python + win10toast) WSL (Codex in WSL, notifications in Windows via PowerShell) All three variants use the same basic mechanism: Codex calls a script on every completed turn, passes a JSON payload, and the script triggers a desktop notification.
Where this integrates nicely with your workflow Once Codex can nudge you through the OS notification system, several patterns open up:
Use Codex to perform codebase wide changes while you are reviewing merge requests in the browser.
Let Codex run integration tests, fix failures and report back with “ready to review” notifications.
Combine it with your tracker to keep larger refactors visible:
Create a story for “Migrate FooService to new API”. Let Codex execute the mechanical steps. Each completed step triggers a notification, and you can tick off subtasks as you go. The notification bridge solves the attention problem: Codex does the heavy lifting, your desktop tells you when it is time to come back and make the next decision.
How Codex notifications work Codex reads a config.toml file in ~/.codex (Linux / WSL) or C:\Users\<user>\.codex (Windows).
The Codex docs on notifications explain the JSON payload and the notify setting, but they stop at the interface: you still have to supply an OS-specific script, and some setups (WSL, minimal Linux desktops) do not ship anything that can show a toast out of the box.
There is a single key that matters here:
Copy notify = ["command", "arg1", "arg2"] Codex runs this command whenever it wants to raise a notification and appends one final argument: a JSON string describing the event.
Typical payload:
Copy { "type": "agent-turn-complete", "last-assistant-message": "I have finished applying the changes.", "input-messages": [ "Refactor the FooService to use dependency injection.", "Update all call sites accordingly." ] } Important points:
type is agent-turn-complete when Codex finishes a turn and is waiting on you again. last-assistant-message is the last message Codex produced. input-messages is what you asked it to do. In realtiy, Codex injects a lot of context into input-messages (open tabs, working directory, active file, etc.) and often uses Markdown lists in last-assistant-message:
Copy { "type": "agent-turn-complete", "thread-id": "019aa2d1-f501-7760-9354-afb6d88317e9", "turn-id": "0", "cwd": "/code/project", "input-messages": [ "# Context from my IDE setup:\n\n## Active file: /home/<user>/.codex/config.toml\n\n## Open tabs:\n- config.toml: /home/<user>/.codex/config.toml\n- blog.html: themes/kanman/layouts/partials/sections/blog.html\n- hero.yaml: data/home/de/hero.yaml\n- blog.yaml: data/home/de/blog.yaml\n- styles.css: themes/kanman/assets/css/styles.css\n\n## My request for Codex:\nPlease revisit the product box in the sidebar of the blog post layout. Use the text content of the feature section and the hero section to come up with an actual meaningful pitch.\n" ], "last-assistant-message": "- Refreshed the blog post sidebar pitch in `themes/kanman/layouts/_default/single.html` to mirror the hero/features messaging: project-first, no KPI/gamification noise, drag-and-drop Priorisierung, and no calendar/AI baggage.\n- Swapped CTA copy to “kanman.ai jetzt nutzen,” added a supporting bullet list with real strengths, and included the pricing subline from the hero text.\n\nTests not run (copy-only change). Next step: preview the blog post page to ensure the new sidebar layout/line breaks feel right." } Unfiltered, that would be a wall of text in a toast. The scripts below trim the request down to a short title, pull only the bullet points from the assistant response, and truncate each line so your notification stays readable. You can extend that idea to:
Strip the “Context from my IDE” block entirely if you do not want path leaks. Keep the Markdown bullets (useful to see multiple actions Codex took) or collapse them into a single sentence. Route different type values to different notification channels (e.g. errors vs. completions). You only need to:
Implement a small script that:
reads argv[1], parses the JSON, decides whether to notify, fires a desktop notification. Point notify in config.toml at that script.
The rest of this post is just three concrete scripts for three environments.
Use cases: why bother at all This wiring is useful whenever Codex is doing something non trivial:
Large multi file refactors. Code generation followed by test runs and fixes. Migration work across services or modules. Any workflow where Codex says things like “I need your approval to apply these changes”. Instead of staring at a progress log, you can:
Switch to another IDE window. Work on documentation. Or yes, watch YouTube. The notification brings you back when Codex either finished or needs input again.
Variant 1: Linux / Unix with notify-send This assumes:
You run Codex inside a normal Linux desktop session. notify-send is available (libnotify-bin on Debian / Ubuntu). Install dependencies On Debian / Ubuntu:
Copy sudo apt update sudo apt install -y libnotify-bin python3 Notification script Create ~/.codex/notify.py:
Copy #!/usr/bin/env python3 import json import re import subprocess import sys def trunc(text: str, limit: int) -> str: """Truncate at a word boundary and add ellipsis when needed.""" if len(text) <= limit: return text cut = max(0, limit - 3) head = text[:cut] head = re.sub(r"\s+\S*$", "", head) if not head: head = text[:cut] return f"{head}..." def title_from_request(inputs: list[str]) -> str: """Use the 'My request for Codex' block as title, else fall back.""" block = "\n".join(inputs or []) lines = block.splitlines() capture = False picked: list[str] = [] for line in lines: if capture: picked.append(line) if line.startswith("## My request for Codex:"): capture = True picked.append(line.replace("## My request for Codex:", "", 1).strip()) title = " ".join(" ".join(picked).split()).strip() return trunc(title or "Codex chat", 120) def body_from_assistant(text: str) -> str: """Prefer Markdown bullets; otherwise condense to one line.""" bullets: list[str] = [] for line in text.splitlines(): if re.match(r"^\s*[-*]\s+", line): bullets.append("- " + re.sub(r"^\s*[-*]\s+", "", line)) if bullets: return "\n".join(trunc(b, 80) for b in bullets) one_line = " ".join(text.split()).strip() return trunc(one_line or "(no assistant message)", 220) def main() -> int: if len(sys.argv) < 2: return 0 try: payload = json.loads(sys.argv[1]) except json.JSONDecodeError: return 0 if payload.get("type") != "agent-turn-complete": return 0 assistant = ( payload.get("last-assistant-message") or payload.get("last_assistant_message") or "" ) title = title_from_request(payload.get("input-messages") or []) message = body_from_assistant(assistant) try: subprocess.run(["notify-send", title, message], check=False) except Exception: # Never break Codex on notification failure pass return 0 if __name__ == "__main__": raise SystemExit(main()) What it does (same flow as the WSL and Windows variants below):
Drops any payload that is not agent-turn-complete. Builds the title from the “My request for Codex” section (or falls back to “Codex chat”) and truncates it. Pulls Markdown bullets from the assistant reply for the body (else uses a single condensed line), truncating each line. Sends the cleaned title/body to notify-send and swallows errors. Make it executable:
Copy chmod +x ~/.codex/notify.py Codex config on Linux Edit ~/.codex/config.toml and make sure notify is a top level key near the top of the file:
Copy model = "gpt-5.1-codex-max" notify = ["python3", "/home/your-user/.codex/notify.py"] [history] persistence = "save-all" [tui] notifications = ["agent-turn-complete"] Two critical details:
Use your actual home path. notify must be a root key, not inside [tui] or any other table. Quick end to end test In a terminal:
Copy python3 ~/.codex/notify.py \ '{"type":"agent-turn-complete","last-assistant-message":"Linux notification test","input-messages":["Example task"]}' You should see a native notification. If that works, start Codex, give it a non trivial task, switch away, and wait for the toast.
Variant 2: Windows notifications with win10toast On Windows, the easiest path is Python plus the win10toast library. No PowerShell modules, no registry hacks.
This variant assumes:
Codex runs on Windows, not inside WSL. Your config.toml lives in C:\Users\<user>\.codex\config.toml. Install Python and win10toast Install Python if you have not already, then in a terminal or PowerShell:
Copy py -m pip install win10toast (or python -m pip install win10toast depending on your setup).
Notification script on Windows Create this file:
C:\Users\<user>\.codex\notify.py
Copy #!/usr/bin/env python import json import re import sys from win10toast import ToastNotifier def trunc(text: str, limit: int) -> str: """Truncate at a word boundary and add ellipsis when needed.""" if len(text) <= limit: return text cut = max(0, limit - 3) head = text[:cut] head = re.sub(r"\s+\S*$", "", head) if not head: head = text[:cut] return f"{head}..." def title_from_request(inputs: list[str]) -> str: """Use the 'My request for Codex' block as title, else fall back.""" block = "\n".join(inputs or []) lines = block.splitlines() capture = False picked: list[str] = [] for line in lines: if capture: picked.append(line) if line.startswith("## My request for Codex:"): capture = True picked.append(line.replace("## My request for Codex:", "", 1).strip()) title = " ".join(" ".join(picked).split()).strip() return trunc(title or "Codex chat", 120) def body_from_assistant(text: str) -> str: """Prefer Markdown bullets; otherwise condense to one line.""" bullets: list[str] = [] for line in text.splitlines(): if re.match(r"^\s*[-*]\s+", line): bullets.append("- " + re.sub(r"^\s*[-*]\s+", "", line)) if bullets: return "\n".join(trunc(b, 80) for b in bullets) one_line = " ".join(text.split()).strip() return trunc(one_line or "(no assistant message)", 220) def main() -> int: if len(sys.argv) < 2: return 0 try: payload = json.loads(sys.argv[1]) except json.JSONDecodeError: return 0 if payload.get("type") != "agent-turn-complete": return 0 assistant = ( payload.get("last-assistant-message") or payload.get("last_assistant_message") or "" ) title = title_from_request(payload.get("input-messages") or []) message = body_from_assistant(assistant) try: toaster = ToastNotifier() toaster.show_toast( title, message, duration=5, threaded=True, ) except Exception: pass return 0 if __name__ == "__main__": raise SystemExit(main()) Same behavior as the Linux/WSL variants:
Only reacts to agent-turn-complete. Title comes from “My request for Codex,” truncated; fallback is “Codex chat”. Body prefers Markdown bullets from the assistant reply; otherwise uses one condensed line, truncating each part. Errors are swallowed so Codex keeps running. Codex config on Windows Edit C:\Users\<user>\.codex\config.toml:
Copy model = "gpt-5.1-codex-max" notify = ["py", "C:/Users/your-user/.codex/notify.py"] [history] persistence = "save-all" [tui] notifications = ["agent-turn-complete"] Adjust the interpreter (py, python, python.exe) and path to match your system.
Test From PowerShell:
Copy py C:/Users/your-user/.codex/notify.py ` '{"type":"agent-turn-complete","last-assistant-message":"Windows notification test","input-messages":["Example task"]}' If you see a Windows toast, Codex can now ping you whenever a turn completes.
Variant 3: Codex in WSL, notifications in Windows This is the interesting one.
Scenario:
You run Codex inside WSL because your toolchain lives there. WSL has no GUI or notification daemon. You still want native Windows notifications while Codex runs in the background. The solution:
notify in config.toml points to a Bash script in WSL. That script receives the JSON payload and forwards it to Windows. The Bash script calls powershell.exe directly; no extra .ps1 file on Windows. Windows PowerShell uses the BurntToast module to fire a native toast. You get the best of both worlds: Linux toolchain, Windows notifications.
Install BurntToast on Windows Open Windows PowerShell (Windows PowerShell 5, not PowerShell 7):
Copy Install-Module -Name BurntToast -Scope CurrentUser -Force If NuGet is missing, install it when prompted.
Quick sanity check:
Copy Import-Module BurntToast New-BurntToastNotification -Text 'Codex', 'Direct BurntToast test' You should see a toast.
Bash wrapper in WSL (calls PowerShell directly) Install jq if missing:
Copy sudo apt-get install -y jq Create ~/.codex/notify.sh:
Copy #!/usr/bin/env bash set -euo pipefail payload="${1:-}" type=$(jq -r '.type // empty' <<<"$payload" 2>/dev/null) [ "$type" != "agent-turn-complete" ] && exit 0 # truncate to max chars, cut back to last full word, add "..." if truncated trunc() { local s="$1" n="$2" [ ${#s} -le $n ] && { printf '%s' "$s"; return; } local cut=$((n-3)) local head head=$(printf '%s' "${s:0:$cut}" | sed -E 's/[[:space:]]+[^[:space:]]*$//') [ -z "$head" ] && head="${s:0:$cut}" printf '%s...' "$head" } # ---- title: extract after "## My request for Codex:" title=$(jq -r '."input-messages"[]? // ""' <<<"$payload" 2>/dev/null \ | awk 'f{print} /^## My request for Codex:/{f=1; sub(/^## My request for Codex:[[:space:]]*/,""); print}' \ | tr '\n' ' ' | sed -E 's/[[:space:]]+/ /g; s/^[[:space:]]+|[[:space:]]+$//g') [ -z "$title" ] && title="Codex chat" title=$(trunc "$title" 120) # ---- body: bullets if present, else full assistant msg assistant=$(jq -r '."last-assistant-message" // .last_assistant_message // ""' <<<"$payload" 2>/dev/null) bullets=$(printf '%s\n' "$assistant" | grep -E '^[[:space:]]*[-*][[:space:]]+' || true) if [ -n "$bullets" ]; then message=$(printf '%s\n' "$bullets" \ | sed -E 's/^[[:space:]]*[-*][[:space:]]+/- /' \ | while IFS= read -r l; do trunc "$l" 80; echo; done) else one_line=$(printf '%s' "$assistant" | tr '\n' ' ' | sed -E 's/[[:space:]]+/ /g; s/^[[:space:]]+|[[:space:]]+$//g') message=$(trunc "${one_line:-"(no assistant message)"}" 220) fi title_esc=${title//\'/\'\'} message_esc=${message//\'/\'\'} powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass \ -Command "Import-Module BurntToast; New-BurntToastNotification -Text '$title_esc', '$message_esc' -AppLogo '\\\\wsl.localhost\\Ubuntu-22.04\\home\\<your-user>\\.codex\\codex-logo.png'" What happens in this Bash wrapper:
Exits unless the payload type is agent-turn-complete. Pulls the title from the “My request for Codex” section, trims whitespace, and truncates to 120 chars at word boundaries (fallback: “Codex chat”). Prefers Markdown bullets from the assistant reply for the body (each truncated to 80 chars); if none exist, condenses the entire reply to 220 chars. Escapes single quotes for PowerShell and calls New-BurntToastNotification directly from WSL, including an icon (adjust the UNC path to your distro/user or drop -AppLogo). Make it executable:
Copy chmod +x ~/.codex/notify.sh Adjust the UNC path inside -AppLogo to match your distro and user. If you do not want an icon, drop that flag.
Codex config in WSL Edit /home/your-user/.codex/config.toml inside WSL:
Copy model = "gpt-5.1-codex-max" notify = ["/bin/bash", "/home/your-user/.codex/notify.sh"] [history] persistence = "save-all" [tui] notifications = ["agent-turn-complete"] Make sure:
This config.toml is the one the WSL Codex installation uses. notify is at the top level, before any [table]. Test from WSL Run:
Copy ~/.codex/notify.sh \ '{"type":"agent-turn-complete","last-assistant-message":"WSL test notification","input-messages":["Example task in WSL"]}' If you see a Windows toast, the bridge works.
Now start Codex from WSL (or from VS Code attached to WSL), queue a longer task, switch away, and wait for the notification.
Optional: use an icon Point the -AppLogo path in ~/.codex/notify.sh to a file Windows can read. Use a UNC path into WSL (\\\\wsl.localhost\\<distro>\\home\\<user>\\.codex\\codex-logo.png) or a straight Windows path (C:\\Users\\your-user\\Pictures\\codex-logo.png). Remove the flag entirely if you want a plain toast.
The rest of the WSL setup stays unchanged.
Summary The core ideas are simple:
Codex already knows how to call an external command on each completed turn. Every desktop platform has a way to show notifications from scripts. Gluing those together is a matter of a few lines of Python, Bash or PowerShell. Linux users wire notify to a Python script that wraps notify-send. Windows users point notify at a small Python script using win10toast. WSL users run a single Bash wrapper that filters the JSON and calls powershell.exe with BurntToast directly - no extra .ps1 file.
Once set up, Codex becomes something you can safely leave running in the background, while focusing on the next item on your board instead of staring at a log window.

### Breaking the Burnout Loop

https://kanman.ai/en/posts/breaking-the-burnout-loop/

Breaking the Burnout Loop Photo by Elisa Ventur on Unsplash
The cycle goes like this:
Work intensely. Check your productivity score. Fall short of targets. Feel guilty. Work harder. Check again. Repeat until something breaks.
This is the burnout loop. It’s built into most productivity systems, most goal frameworks, and most work tools. The loop runs until you can’t run it anymore.
Breaking out requires understanding how the loop works - and building systems that don’t feed it.
How the Loop Works Modern productivity culture creates three interlocking pressures:
The grind. Always-on expectations. Notifications at all hours. The sense that someone, somewhere is outworking you. The guilt of rest.
The evaluate. Metrics everywhere. Velocity scores, time tracking, streak counts, dashboard percentages. Constant measurement creating constant awareness of gaps.
The punish. Targets missed trigger consequences. A broken streak feels like failure. A red metric feels like judgment. Even when nobody’s watching, the tools watch.
These pressures reinforce each other. The grind produces exhaustion. Exhaustion produces falling metrics. Falling metrics produce guilt. Guilt produces more grinding.
The loop doesn’t have an exit. It only has a crash.
What Tools Enable This Most productivity tools are designed to maintain the loop.
Gamification mechanics create artificial stakes. Streaks punish missed days. Badges reward unsustainable effort. Points gamify what should be natural work rhythms.
Dashboards create constant visibility into gaps. You’re never just doing work - you’re always comparing to targets, averages, and peers. The gap is always visible.
Notifications keep the loop spinning. Every ping pulls you back. Every reminder creates urgency. The tool refuses to let you disengage.
These features aren’t bugs. They’re designed to maximize engagement. But engagement isn’t the same as health.
What Breaking Out Looks Like Breaking the burnout loop means removing the pressures that maintain it.
No streaks. kanman doesn’t track your streaks or your hours. Miss a day, miss a week - it doesn’t notice. There’s no chain to break, no counter to reset. Rest is invisible because it’s not the app’s business.
No scores. No productivity metrics. No velocity dashboards. No comparisons to yesterday or last week. You see your projects and tasks. That’s it.
No pressure. Default silence. No notifications unless you enable them. No nudges, no reminders, no guilt. The tool waits until you’re ready.
These omissions aren’t laziness. They’re deliberate design choices to avoid feeding the loop.
Sustainable Rhythms The alternative to the burnout loop isn’t doing less. It’s working sustainably.
Sustainable work has natural rhythms. Intense periods followed by recovery. Sprints followed by rest. Shipping followed by reflection.
Tools should support these rhythms, not flatten them. A task manager that guilts you for taking a weekend off doesn’t understand how creative work happens.
kanman stays out of the way. It works the stories your team hands over and only asks when a decision is actually yours. Take a week off and nobody gets a report about it. Come back and the evidence for what shipped is waiting, not a guilt counter.
Breaking Your Own Loop If you’re caught in a burnout loop, recognition is the first step.
Notice when you’re grinding because of guilt rather than need. Notice when you’re checking metrics compulsively. Notice when rest feels impossible rather than unnecessary.
Then start removing pressure sources:
Disable notifications. Start with work tools. See how it feels to choose when to engage rather than being summoned.
Ignore dashboards. Stop checking productivity metrics. For a week, then a month. Notice what actually suffers - often nothing.
Kill streaks. If a tool punishes missed days, either disable the feature or replace the tool. Artificial urgency isn’t helping you.
Protect rest. Treat breaks as essential, not earned. You don’t need to hit a target before you’re allowed to rest.
The Quiet Alternative The productivity industry profits from the burnout loop. More engagement means more value extraction. The loop keeps you on the platform.
Quiet tools take a different approach. They help when you need help and disappear when you don’t. They don’t gamify, don’t measure, don’t guilt.
kanman is one example. It exists to take work off your team’s plate and prove it got done. The business model doesn’t depend on keeping you engaged - just on the work shipping.
This matters. When a tool’s profit motive aligns with your wellbeing, it designs differently. When a tool profits from your attention, it designs to capture it at any cost.
After the Loop Breaking the burnout loop doesn’t mean becoming unproductive. It means becoming sustainable.
Sustainable productivity doesn’t crash. It doesn’t require recovery periods that erase the gains. It builds over years rather than burning out in months.
The work gets done - not because you’re grinding against guilt, but because you’re rested enough to do it well. Not because streaks pressure you, but because the work matters.
That’s what tools should enable. Not more loops. More finished work, from people who can keep finishing it.
Ready to break the loop? Want an AI teammate that ships the work, proves it, and never counts your streaks? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Hustle Culture's Hidden Costs

https://kanman.ai/en/posts/hustle-cultures-hidden-costs/

Hustle Culture’s Hidden Costs Photo by Andy Beales on Unsplash
The pitch is simple: work harder, achieve more. Put in the hours. Grind through the obstacles. Sleep when you’re dead.
Hustle culture sells intensity as the path to success. What it doesn’t advertise are the costs.
Not the obvious costs - exhaustion, burnout, damaged relationships. The hidden costs. The productivity you lose while appearing productive. The focus destroyed by the very tools that promise to enhance it.
The Context Switching Tax Every time you switch tasks, you pay a tax.
Research suggests it takes 23 minutes to fully regain focus after an interruption. A notification ping, a Slack message, a quick check of the dashboard - each one extracts time you don’t notice losing.
Hustle culture normalizes constant interruption. Always available. Always responsive. Always context switching between urgent requests.
The hidden cost: you’re never actually productive. You’re always in the recovery period from the last interruption, waiting for the next one. Deep work becomes impossible when the culture celebrates availability over focus.
The Rework Penalty Tired people make mistakes. Rushed work has errors. Work done while distracted needs revision.
These aren’t failures of effort - they’re failures of condition. When you grind through exhaustion, quality drops. When you rush to hit artificial deadlines, you cut corners that create future work.
The hidden cost: hours spent fixing what shouldn’t have been broken. The meeting to explain the bug. The weekend spent on emergency patches. The technical debt that compounds forever.
Hustle culture counts the hours worked. It doesn’t count the hours of rework those hours create.
The Focus Decay Focus is a resource that depletes. The more you use it, the less you have. The more you’re interrupted, the harder recovery becomes.
Hustle culture treats focus as infinite. Just push through. Just try harder. Just caffeinate and continue.
The hidden cost: declining quality over time. The first hours of the day produce better work than the last. The first weeks of a sprint outpace the final slog. The burnout isn’t sudden - it’s gradual decay you don’t notice until something snaps.
The Health Debt Bodies and minds have limits. Ignore them long enough and they collect the debt with interest.
Sleep deprivation accumulates. Stress compounds. The back pain from endless desk hours, the anxiety from constant pressure, the relationships damaged by unavailability - these costs don’t appear in productivity metrics.
The hidden cost: reduced lifespan, reduced healthspan, reduced ability to enjoy whatever success the hustle purchased. You can’t spend achievements from a hospital bed.
What Calm Alternatives Look Like kanman explicitly rejects hustle culture. The flag list calls it out: “hustle culture” and “always-on mindset” are problems, not features.
This shapes the product:
No pings for the sake of pings. kanman doesn’t remind you or pull you back when you’ve stepped away. It only asks when a decision is yours, and the decision waits until you’re ready.
No gamification pressure. No streaks to maintain. No points to accumulate. No badges to earn. The pressure to perform every day, even when you shouldn’t, isn’t built in.
Minimal surfaces. No second board next to your tracker. Not a platform that tries to be everything. Fewer surfaces mean less context switching between apps, more time in actual work.
No surveillance. Your work patterns are private. No activity tracking means no pressure to appear busy. Work when it makes sense. Rest when it makes sense. Nobody’s watching.
The night shift isn’t yours. Yes, an AI teammate can keep working while you sleep. That’s the point: the humans don’t have to.
Reclaiming What’s Lost The hidden costs of hustle culture are recoverable. Focus rebuilds with rest. Quality improves with sustainable pace. Health recovers when you stop burning it as fuel.
Reclaiming starts with tools that don’t extract these costs:
Choose silence. Disable notifications on everything possible. Experience the difference when you decide when to engage rather than being summoned.
Protect blocks. Create periods of uninterrupted work. Even two hours of focus per day outproduces eight hours of fragmented availability.
Trust rest. Recovery isn’t laziness. Taking a day off isn’t failure. The work that happens after rest is better than the work that happens instead of rest.
Measure outcomes, not hours. Track what you shipped, not how long you sat at the desk. Shipped work is the only metric that matters.
The Sustainable Alternative The opposite of hustle culture isn’t laziness. It’s sustainability.
Sustainable productivity compounds over years. It doesn’t burn out in months. It produces consistent output without the peaks and crashes of grind cycles.
Sustainable work uses tools that respect human limits. Calm software that stays quiet. Task managers that don’t gamify. Pricing that doesn’t require monthly justification.
The hidden costs of hustle culture are real. But they’re avoidable. The alternative isn’t less achievement - it’s achievement that lasts.
Done paying hustle culture’s hidden costs? Want an AI teammate that takes work off your team’s evenings, under your rules? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### The Weekly Reset: A Five-Minute Ritual

https://kanman.ai/en/posts/the-weekly-reset/

The Weekly Reset: A Five-Minute Ritual Photo by Glenn Carstens-Peters on Unsplash
Sunday evening arrives and the dread sets in. Tomorrow is Monday. The week’s work looms. You should probably do some planning.
So you open your task manager. You review the backlog. You estimate, categorize, and prioritize. You create a plan for the week. An hour passes. Maybe two.
By the time you’re done, you’re exhausted - and you haven’t actually done anything yet.
There’s a better way.
The Five-Minute Version Open your board. Look at what’s in progress. Drag the most important thing to the top. Maybe drag two or three more things into rough order.
Close the board.
Done.
That’s the weekly reset. No templates. No frameworks. No time-blocking. No sprint planning. Just a quick look at what’s in progress and a gut-check on priority order.
Why This Works The weekly reset works because prioritization doesn’t actually require ceremony.
You already know what matters. You know which project is urgent, which is important, and which has been sitting untouched for too long. The knowledge exists in your head.
The tool’s job is to capture that knowledge quickly, not to extract it through elaborate rituals. Drag-and-drop ordering takes seconds, not hours. The interface gets out of the way so your intuition can work.
Most planning overhead comes from tools that demand more information than you actually have. Estimates for tasks you haven’t started. Categories for work that doesn’t fit categories. Dependencies for projects that will change next week anyway.
Skip all of it. Look at the list. Order it by gut feeling. Move on.
Replacing Sunday Dread The traditional weekly review creates dread because it’s work about work. You’re not shipping anything. You’re not making progress. You’re maintaining a system that’s supposed to help you make progress - someday.
The five-minute reset replaces dread with action. You spend less time planning and more time doing. The planning that matters happens in the doing.
This doesn’t mean you never plan. It means you plan lightweight. When a project needs detailed steps, write them as tasks. When priorities shift, drag projects around. When something new arrives, add it and decide where it goes.
None of this requires a dedicated planning session. It happens as you work.
What Gets Dropped The five-minute reset intentionally drops several practices that traditional planning demands:
Time estimates. You don’t estimate how long things will take. You’ll find out when you do them. Estimates are usually wrong anyway.
Capacity planning. You don’t calculate how many “points” you can fit this week. You work on what’s most important until you can’t, then you rest.
Calendar blocking. You don’t assign projects to specific days. Reality will reshuffle your week regardless of what you put on the calendar.
Detailed next actions. You don’t break everything into tiny steps in advance. You break things down when you start working on them, when you understand what they actually require.
These practices feel productive. They’re often just procrastination that looks like work.
The Ritual Details If five minutes feels too vague, here’s a slightly more structured version:
Step 1: Open your project list. See everything you’ve started. Notice what’s stalled, what’s active, what’s waiting.
Step 2: Identify the top priority. Ask yourself: “If I could only finish one thing this week, what would it be?” Drag it to the top.
Step 3: Quick-order the next few. Don’t overthink. Gut feeling is fine. You can reorder mid-week if priorities shift.
Step 4: Close the app. Resist the urge to tinker. The plan is good enough. Go do something else.
That’s it. Sunday evening reclaimed.
When More Planning Makes Sense The five-minute reset doesn’t replace all planning. Some situations need more:
Large project kickoffs. When starting something substantial, spend time understanding scope and breaking it into phases. This is project work, not weekly maintenance.
Team coordination. When multiple people work on shared projects, alignment discussions matter. But these are conversations, not dashboard ceremonies.
Stuck projects. When something has stalled for weeks, ask why. Maybe it needs re-scoping. Maybe it’s not actually important. This is problem-solving, not planning.
The five-minute reset handles the routine. Save deeper thinking for when it’s actually needed.
The Anti-Ceremony Productivity culture loves ceremonies. Morning routines. Weekly reviews. Monthly retrospectives. Quarterly planning. Annual goal-setting.
Each ceremony adds overhead. Each one takes time from actual work. Each one promises to improve productivity while consuming it.
The five-minute reset is an anti-ceremony. It’s the minimum viable planning - just enough structure to stay oriented, not enough to become its own job.
Try it this week. Open your projects, drag a few things around, close the app. See how much of your planning overhead was actually necessary.
Ready for simpler weeks? Want an AI teammate that picks up the top of your list and comes back with proof? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### Screw Plans, Ship Work: Why Perfect Roadmaps Stall Real Progress

https://kanman.ai/en/posts/screw-plans-ship-work/

Screw Plans, Ship Work: Why Perfect Roadmaps Stall Real Progress Photo by Steve Johnson on Unsplash
The roadmap looks beautiful. Color-coded swimlanes. Dependencies mapped out. Milestones at regular intervals. Quarterly targets aligned with annual OKRs.
It’s perfect. And it’s fiction.
Two weeks from now, something will change. A customer request, a technical discovery, a strategic pivot. The roadmap will need updating. Then it will need updating again. And again.
Meanwhile, the actual work sits waiting while you plan how to plan it.
Plans Are Guesses Every plan contains assumptions. Estimates of how long things take. Beliefs about what customers want. Predictions about what the market will do.
These assumptions are guesses. Some informed, some hopeful, most wrong in ways you can’t predict.
Roadmaps hide this uncertainty behind precision. Exact dates. Specific deliverables. Dependencies mapped to the hour. The precision is comforting but illusory.
Reality doesn’t care about your plan. It unfolds messily, revealing information you couldn’t have had when planning. The only honest response is to adapt - which means the plan was always temporary.
Planning Theater Some planning is necessary. But much of what organizations call “planning” is performance.
Sprint ceremonies that take hours. Roadmap presentations that impress stakeholders. Estimation poker that creates false precision. Dependency mapping that becomes obsolete before the ink dries.
This isn’t planning. It’s planning theater - the appearance of control in a fundamentally uncontrollable situation.
The theater serves purposes. It creates alignment. It gives stakeholders something to approve. It makes everyone feel like they know what’s coming. But it doesn’t actually improve outcomes. Sometimes it degrades them by consuming time that could go to actual work.
Ship, Then Adjust The alternative is straightforward: ship something, learn from it, adjust.
Not “move fast and break things” - that phrase justified too much recklessness. More like “ship carefully and learn constantly.” Do small work, see what happens, respond to reality.
This requires less planning, not none. You still need direction. You still need priorities. But you need them lightweight, updated in minutes not meetings, and held loosely.
kanman works with this, not against it. Your priority is the order in your tracker. Change the order and the next story I pick up changes with it. No ceremony, no slide deck, no realignment meetings.
Adaptability Beats Rigor Rigid planning works in stable environments. When you know exactly what needs building, when requirements are fixed, when nothing unexpected happens - detailed upfront planning makes sense.
That’s not the environment most of us work in.
In real work, requirements shift. Customers change their minds. Technologies surprise you. Team capacity fluctuates. The ground moves while you’re standing on it.
In this environment, adaptability beats rigor. The team that can reprioritize in an afternoon outperforms the team that needs a sprint boundary. The individual who reorders their task list by gut feeling outperforms the one waiting for the next planning session.
Planning should enable adaptation, not prevent it.
What Minimum Planning Looks Like Here’s what planning actually needs:
Direction. Where are we headed? This can be a sentence, not a document.
Priority order. What’s most important right now? A ranked list, not a matrix.
Current focus. What are we actively working on? The things you’ve started and intend to finish.
That’s it. Everything else - estimates, timelines, dependencies, capacity calculations - is optional overhead that may or may not help.
kanman relies on just these essentials. Your tracker’s order shows direction and priority. The stories in progress show current focus. kanman adds nothing else because nothing else is necessary.
When Plans Do Matter Some contexts need more structure:
Coordination dependencies. When Team A’s work blocks Team B, you need some shared timeline understanding. But this is coordination, not detailed upfront planning.
External commitments. When you’ve promised a customer a feature by a date, you need to track toward that date. But the internal path to get there can stay flexible.
Large initiatives. When work spans months and multiple teams, some structure prevents chaos. But even then, the structure should be minimal and adaptive.
The principle holds: plan enough to coordinate, not enough to constrain.
Shipping as Learning The deepest problem with upfront planning is that it assumes you know things you can’t.
How long will this take? You don’t know until you’ve done similar work. What will customers want? You don’t know until they use it. What will break? You don’t know until you push to production.
Every shipped piece of work generates knowledge. Features reveal customer preferences. Bugs reveal system weaknesses. Timelines reveal estimation accuracy.
This knowledge improves future work. But it only comes from shipping - not from planning to ship.
The Anti-Roadmap “Screw plans. Get it done.” isn’t anti-planning. It’s anti-planning-theater.
Real planning takes five minutes. Look at what’s in progress. Decide what’s most important. Start working.
The roadmap that matters is the project list. The strategy that matters is the priority order. The commitment that matters is the thing you’re actively building.
Everything else is noise dressed as signal.
Ready to skip the planning theater? Want an AI teammate that takes the top story from your tracker and ships it with proof? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### The Myth of the Perfect Workflow

https://kanman.ai/en/posts/myth-of-perfect-workflow/

The Myth of the Perfect Workflow Photo by Kvalifik on Unsplash
Somewhere out there is the perfect productivity system. The one that finally makes everything click. The framework that matches your brain. The tool that eliminates friction.
You just haven’t found it yet.
So you research. You try new apps. You read productivity books. You watch YouTube videos about bullet journaling, time blocking, GTD, PARA, Zettelkasten. You test methods, abandon them, try others.
Meanwhile, the actual work waits.
This is the myth of the perfect workflow: the belief that finding the right system is a prerequisite to doing the work. It’s not. The search for perfection is often procrastination in disguise.
Workflow Optimization as Avoidance Tweaking your system feels productive. You’re organizing! Improving! Getting ready to really work!
But it’s not the work. It’s preparation that prevents the work.
Every hour spent perfecting your task categories is an hour not spent on tasks. Every day spent migrating to a new tool is a day not spent shipping. Every week spent learning a new methodology is a week of actual work delayed.
The returns diminish quickly. The first hour of system setup helps. The twentieth hour of optimization is probably procrastination.
Good Enough Is Enough The threshold for a functional workflow is low.
Can you capture tasks? Can you see what needs doing? Can you mark things done? Can you roughly prioritize?
That’s it. Everything beyond this is optional enhancement that may or may not help.
kanman is built around this threshold. It doesn’t bring a workflow of its own. It works in your tracker, with your columns, under your review rules. No methods, no frameworks, no optimizations to chase.
This isn’t feature poverty. It’s recognizing that workflow tools serve work - they’re not the work itself. A good-enough tool used consistently beats a perfect tool endlessly configured.
The Perfectionism Trap Workflow perfectionism has a particular flavor.
You start with a new system. It seems great. You’re productive for a while. Then you notice a friction point. Maybe tags aren’t quite right. Maybe the calendar integration is imperfect. Maybe the mobile app is laggy.
So you search for something better. You find it, migrate, feel productive again. Until the next friction point.
This cycle can run for years. You’re always optimizing without finishing. Always preparing without producing. The perfect system stays just over the horizon, always one more tweak away.
The trap: productivity systems are never frictionless. The friction you’re escaping will exist in the next tool too. The only way out is to accept imperfection and work anyway.
Shipping Beats Optimizing The measure of a workflow isn’t how elegant it feels. It’s how much work gets done.
A messy system that ships beats a clean system that doesn’t. A rough prioritization method that produces beats a sophisticated framework that stalls. Ugly progress beats beautiful preparation.
This inversion challenges productivity culture’s assumptions. We’re told better systems produce better work. Sometimes that’s true. But often, the search for better systems prevents any work at all.
Ship first. Optimize later - if ever.
What You Actually Need Here’s the minimum viable workflow:
A place to capture. When something needs doing, write it somewhere. A task manager, a text file, a paper notepad. Capture prevents forgetting.
A place to see. Review what’s captured. Know what exists. See your projects in one view.
A way to prioritize. Put important things before unimportant things. This can be as simple as order in a list.
A way to complete. Mark done things done. Clear the finished work to see what remains.
Everything else - categories, tags, time estimates, due dates, dependencies, automations - is enhancement. Some enhancements help some people. Most are unnecessary for most work.
Try the minimum first. Add complexity only when the minimum fails.
Embracing Constraint kanman’s restraint is a feature, not a limitation.
It adds no tags to categorize, no due dates to invent, no time tracking to log. It doesn’t ask anyone to estimate. It takes the stories your team hands over, ships them and proves they work. Your choices about what matters stay yours.
These constraints prevent workflow optimization. You can’t spend hours tweaking because there’s nothing to tweak. The tool does its job and gets out of the way.
This frustrates people who want sophisticated systems. It liberates people who want to stop building systems and start building things.
The Work Is the Point Your workflow exists to serve your work. Not the other way around.
When optimizing the workflow becomes the work, something has gone wrong. When you spend more time on the system than in the system, something has gone wrong. When choosing tools feels like productivity, something has gone wrong.
The work is the point. The workflow is just how you see it, organize it, and track completion. Any workflow that lets you do those things is good enough.
Stop searching for perfect. Start using what you have.
Done searching for the perfect workflow? Want an AI teammate that fits the one you already have and proves every change? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.

### When Metrics Gaslight Makers

https://kanman.ai/en/posts/when-metrics-gaslight-makers/

When Metrics Gaslight Makers Photo by Luke Chesser on Unsplash
You shipped a major feature this week. The code is clean. Users are happy. The thing works.
But the dashboard shows your velocity dropped 15% compared to last sprint. Your completion rate is “concerning.” The burndown chart slopes the wrong way.
According to the metrics, you’re failing. According to reality, you’re succeeding.
This is what it looks like when metrics gaslight makers.
The Distortion Machine Metrics are supposed to reflect reality. But they often create a parallel reality that contradicts experience.
This happens because metrics measure what’s countable, not what’s valuable. They track tickets closed, not problems solved. Story points completed, not quality shipped. Time logged, not outcomes achieved.
When these abstractions diverge from reality, the metrics don’t update - your perception does. You start believing the dashboard instead of your experience. You feel behind when you’re ahead. You feel unproductive when you’re producing.
That’s gaslighting: making someone distrust their own perception in favor of an external narrative.
How It Happens Several mechanisms create this distortion:
Arbitrary baselines. Velocity is measured against previous sprints. But previous sprints might have been unsustainably fast, artificially easy, or just different work. The baseline becomes a trap.
Counting the wrong things. Not all tickets are equal. A ticket that takes an hour might matter more than ten that take five minutes each. The metric sees ten, not one. The metric is wrong.
Context collapse. Metrics strip context. Was the sprint slow because of vacation, illness, technical debt, or a hard problem? The number doesn’t say. It just says “down.”
Comparison spirals. Dashboards invite comparison - to other sprints, other teams, other people. But those comparisons are usually invalid. Different work, different constraints, different definitions.
The Anxiety Tax Metric gaslighting extracts a tax on makers.
When the dashboard says you’re failing, anxiety follows. You question your performance. You wonder if you’re working hard enough. You feel pressure to game the numbers next sprint.
This anxiety doesn’t improve work. It consumes energy that could go to actual production. It creates the burnout loop: work harder to fix the metrics, burn out, metrics get worse.
The worst part: the anxiety is based on fiction. The numbers are wrong. You’re actually fine. But the dashboard’s authority overrides your judgment.
When Metrics Actually Help Metrics aren’t universally bad. At scale, they serve real purposes.
A hundred-person engineering org needs signals about where work is stuck, which teams are overloaded, and how initiatives progress across quarters. Portfolio-level visibility helps leadership allocate resources. Cross-team metrics help prevent collisions and identify bottlenecks.
The problem is scope creep - applying enterprise coordination tools to teams that don’t need them. A five-person team tracking velocity across sprints has created overhead without creating insight. They already know who’s working on what. The dashboard just makes it look more official.
As many processes as needed. As few as possible. All the time.
Most teams using metric dashboards would be better served by a whiteboard and a weekly conversation. The metrics exist because someone bought an enterprise tool, not because the team required enterprise coordination.
The Alternative: No Metrics kanman doesn’t show productivity metrics. No velocity charts. No burndown graphs. No completion percentages. No comparisons between people.
You see the story, and the evidence that it does what was asked. That’s the only measurement: proven done or not done.
This sounds radical, but it’s actually the simplest possible measurement. Did you ship the thing? That’s the question. Not how fast, not compared to what, not according to which estimation methodology.
The absence of metrics isn’t a feature gap. It’s a deliberate design choice. kanman trusts you to know whether you’re being productive without requiring a dashboard to validate it.
What Matters Instead If metrics don’t measure what matters, what does?
Shipped work. Did the feature go out? Did the bug get fixed? Did the project complete? These are observable outcomes, not abstractions.
Quality. Does the thing work? Are users happy? Is the code maintainable? Quality doesn’t fit in a number.
Sustainability. Can you keep this pace? Are you burning out or coasting? Sustainability is felt, not measured.
Learning. Did you get better? Did the team improve? Growth is long-term and hard to quantify.
These matter more than velocity scores. But they can’t be dashboarded, so productivity culture ignores them.
Reclaiming Your Perception If you’re caught in metric gaslighting, start trusting yourself again.
Notice when dashboards contradict your experience. Notice when you feel behind despite shipping. Notice when the numbers don’t match reality.
Then question the numbers, not yourself.
Metrics are one signal, not the signal. They’re often wrong. They’re always incomplete. Your direct experience of the work is more accurate than any abstraction of it.
The Quiet Confidence Makers who escape metric gaslighting develop a quiet confidence.
They know what they shipped. They don’t need a dashboard to validate it. They track progress by looking at the work, not at charts about the work.
kanman supports this confidence. It shows the work without judging it. It shows what shipped without scoring anyone. It lets outcomes speak without commentary.
No metrics means no gaslighting. No charts means no distortion. Just the work, and your own judgment of it.
Ready to trust outcomes instead of charts? Want an AI teammate that shows evidence, not velocity? kanman - Pilot from €5,000 for 6 weeks, Team €990 per AI team per month.