How Claude became our Project Manager

Last Sunday evening, I realised something: Claude had become our project manager.

I normally use a few hours on Sunday nights to prepare the week ahead for our team. We’re a fast-moving small team of builders and, like most startups, we don’t have dedicated project manager in the team or time for heavy processes either. But thanks to Claude, today we’re running the best project management process we’ve ever had, and with minimal human effort.

Why project management wasn’t working

We’ve tried multiple approaches to project management in our company, ranging from no project management at all to a formal agile setup with a dedicated project manager.

The No Project Manager approach only works when you are in an extremely focused sprint (we call it survival mode). It can work for short bursts but I don’t recommend it for anything longer than one of two weeks.

At the other end of the spectrum, when we were a larger team of 18 (back when we were building Flowrite), we brought in a dedicated project manager and adopted an agile framework. It worked to some extent, but it was clearly overkill for a team of our current size. More importantly, the process itself demanded a significant time investment, which often slowed execution rather than enabling it.

The amount of time and energy required to keep the process running is very important factor that determines if an approach will stick with our team or not. Any overhead compounds quickly for a fast-moving startup.

We decided to experiment with different custom approaches, still informed by best practices but deliberately lightweight. And after some trial and error, we landed on an extremely lean framework that actually fits how we work. See Appendix A for details.

But even after moving to a much leaner, custom setup, someone still had to run the process. In practice, that someone was me.

As the AI Lead, I was spending roughly 4–6 hours per week on what you could categorised as project management: planning projects, creating Linear project, cycle reviews, updating tasks, reshaping scopes, following up, keeping things coherent, etc.

And this was with a very lean stack, Linear for execution and Notion for documentation. Yet, that time was still coming directly out of deep thinking, scoping, actual problem-solving and development.

This is the gap Claude ended up filling and the reason why our framework really took off.

How Claude Code took over most of my project management work

At some point, it became obvious that I shouldn’t be doing those tasks myself. They were necessary but shallow, and were consuming time that should have gone into thinking and problem-solving.

So I tried something simple: delegate them to Claude.

That’s when things really took off. So much that Claude effectively became our official project manager.

I wanted Claude to do mainly two things:

1. Take over all repetitive, shallow project management work: creating projects, assigning Linear issues, pinging engineers for updates, keeping things in sync.
2. Assist me with project management tasks for higher-level work: helping with scoping, drafting specs, analysing project status, spotting risks, and surfacing patterns.

Before explaining how I set up Claude code, I’ll answer why I chose Claude Code over any other tool. The answer is simple: Claude Code is our go-to coding agent. Every engineer has a 20x MAX subscription. Everyone uses it daily. Therefore, it’d very simple for me to setup a repository with Claude Code project-level configuration, and pretty much everybody in the team would be able to use it.

Ok now on to the setup. The setup itself is intentionally simple:

The repository structure that serves as Claude Code's operational context

I created a small repository that acts as Claude Code’s operational context. Inside it, I added our internal project management framework in .md, created a project-level .mcp.json configuration for Linear, Notion, and GitHub MCP servers and also included a few docs from previous cycles so Claude could learn our patterns.

Once I had all of this in place, I asked it to /init and explained what its role should be. That resulted in a very focused CLAUDE.md that defines responsibilities, boundaries, and expectations:

The CLAUDE.md file that defines Claude's role as project manager

This minimal setup alone took me from ~4–5 hours per week of project management to about one hour. I didn’t need to create sophisticated skills or slash commands to get started.

Claude has full access to our Linear and Notion workspaces, plus a carefully scoped set of GitHub repositories. Permissions are explicit and easy to customise depending on what you’re comfortable delegating.

What this enables in practice

With this context and setup, Claude can answer questions I used to manually assemble from multiple tools and sources of information.

I can just go and ask for a quick snapshot of the current cycle status:

Asking Claude for a quick snapshot of the current cycle status

Then ask Claude to prepare the mid-cycle review for mw, which gets written directly into our Notion workspace and readily available for the Monday weekly:

Claude preparing the mid-cycle review and writing it to Notion

The Mid-cycle review document in Notion

Because Claude understands our internal docs, past cycles, and team structure, it can now handle the execution work I used to do manually, not only much faster but even better than myself. I just need to stay on top providing guidance (at least for now!):

Claude handling execution work by creating Linear issues

The issue created by Claude in Linear

Scoping with Claude

Scoping has become much easier since Claude acts as our project manager as well. In the scoping phase, I provide much more guidance and use Claude primarily as a sounding board to review technical approaches, evaluate tradeoffs, and surface considerations I might miss.

As a previously mentioned, Claude Code is connected to our actual working environment via MCP servers: Linear, Notion, and GitHub. This fundamentally changes the quality of the conversation. When I’m thinking through an architectural decision, Claude can inspect our existing implementation in a Github repo, reference our past architectural decisions in Notion, and check related work already tracked in Linear or even comments from engineers. I don’t need to reconstruct context or paste snippets myself.

Because of this, Claude isn’t just giving generic advice. It’s reasoning about our codebase, our constraints, and our history. That makes it a legitimate thinking partner during scoping rather than a high-level reviewer.

Once I’m happy with the technical direction, I ask Claude to break the work down into milestones and tasks. Since it understands both the technical complexity and the team structure, it usually proposes a reasonable level of granularity and ownership.

I fully review everything Claude proposes during scoping. I push back, ask for revisions, and manually adjust scope or priorities where needed. Once I’m satisfied, I ask it to create the actual Linear project, tickets, and assignments, etc. and I follow with a final pass in Linear.

Careful review is essential during technical scoping, since incorrect decisions compound quickly. The difference is that I’m now faster than ever and the quality of our scopes has improved significantly: my time goes into thinking, evaluating alternatives, and making tradeoffs, rather than gathering context or creating materials. I focus on what actually matters and what Claude can’t do.

A quick note on Claude Cowork

Anthropic recently released Claude Cowork in research preview, which is essentially Claude Code for non-technical users. It builds on the same agent architecture but wraps it in a more approachable interface so broader teams can delegate tasks without touching a command line.

I’ve tested it a bit as a potential alternative to Claude Code for collaborators who don’t work in terminals. So far, it’s promising but it still feels a bit rough and buggy in this early stage. It will soon work well for non-technical users too though.

Claude Cowork: a more approachable interface for non-technical users

Closing thoughts

Since promoting Claude to project manager within Flow AI:

• There is significantly less overhead
• I can spend more time on the decisions that actually matter
• Execution is healthier and more predictable than ever

For a small, fast-moving team like ours, this has been a real force multiplier.

This doesn’t mean project managers are no longer needed. In larger teams with complex dynamics, experienced project managers are still critical. But even there, they could benefit massively from having a setup like this, offloading execution glue and context management so they can focus on people, priorities, and judgment.

If this resonates and you're interested in the full setup, reach out! We're happy to share what's working for us.

Appendix A: Our framework

I've asked Claude, our official Project Manager, to summarise our framework for us:

Heavy processes slowed the team down, while no process led to confusion. The root cause of missed deadlines and scope issues is uncertainty — this process makes it visible.

Key Principles

1. Fixed 2-week cycles — Only plan detailed work for the next 2 weeks
2. No individual deadlines — Only milestones have deadlines; issues just fit within a cycle
3. Confidence levels on every issue:
   • 🟢 High: Clear scope (bugfix, refactor)
   • 🟠 Medium: Some unknowns, manageable
   • 🔴 Low: Requires a spike first
4. Spikes — Short research tasks (max 1 week, aim 2-3 days) to move confidence from Low → Medium/High
5. Parking Lot — Capture ideas without distraction; review at cycle end

Tracking Uncertainty

Use tags when unexpected things happen:

• #surprise — Discovered blocker/dependency you didn't expect
• #pivot — Changed direction mid-execution

Document with: Surprise/Pivot → Impact → Next Step

Cycle Workflow

1. Before cycle: Project owners define issues with confidence levels, scope to "minimum within minimum"
2. Start: Review in weekly meeting, assign team members
3. During: Updates in Slack, truth in Linear
4. Mid-cycle: Check progress, flag blockers/surprises
5. End: Issues must be completed, redefined with reason, or cancelled

Rules

• Only create detailed issues one cycle ahead
• Every issue needs: one assignee, confidence level, fits in one cycle
• Slack = coordination layer, Linear = source of truth

This is the result of many trial and error iterations, and it let us create the enough structure to be efficient.

Reach out to me if you want the full framework!