Claude Code to manage engineering teams

Your engineers code 5x faster with AI. Your team ships at the same pace.

The problem isn’t productivity. It’s systems thinking.

A system’s throughput depends on its bottleneck. If ICs write code faster but code reviews take a week, the team is slow. If stories ship quickly but requirements are unclear, the team wastes time. If individual velocity is high but work distribution is uneven, the team burns out or misses targets.

We increased engineering speed by 10%, reduced PR review time by 20%, and stabilized sprint throughput, while cutting management overhead in half. This not only made the team happy but freed me to focus on strategic work and write blogs like this.

The lever: Claude Code plugins that automate the coordination layer between fast ICs.

Like all engineering teams quickly ramping on AI, my teams adopted coding tools to boost productivity. Looking at data few months later, we noticed that the engineers did end up writing more code but the organization’s delivery speed didn’t improve much. We identified three main bottlenecks:

Planning: Unclear requirements cause back-and-forth. Engineers build the wrong thing. Managers spend hours clarifying in Slack or meetings.

Reviews: Slow feedback cycles block PRs. Human reviewers focus on tactical issues instead of architecture. Knowledge stays siloed.

Allocation: Poor workload distribution creates overload or idle time. Without data, managers react too late.

These aren’t engineering problems. They’re coordination problems. AI makes engineers faster, but coordination still runs at human speed. As a manger, I needed to automate these bottlenecks to match the new engineering speed and leadership expectations.

I started playing around with Claude Code plugins to create a framework that addresses each bottleneck. I have been using Claude Code extensively for my coding tasks but I’ve only recently started using this to manage my teams. MCPs(atlassian, github, slack, aws, chrome-devools etc) and tools give it superpowers to work with both business and engineering context.

Problem: Engineers asked clarifying questions on 60% of stories. Bugs lacked reproduction steps. I spent 10 hours per sprint answering “what does done look like?”

Solution: Template driven task creation

The plugin enforces structure and standardization before tickets are created. Stories require:

• Clear summary: [Component] - [Action]

• Context: Why this work matters. What’s the user impact? What part of a feature does this enable?

• Scope: What’s included, what’s not

• Acceptance Criteria: Specific, testable conditions. This what a Product Manager or QA would use to validate completion.

• Definition of Done: Tests, docs, deployment checklist. Think of this as engineering sign-off criteria.

Bugs require:

• Steps to reproduce: Useful for both the QA teams and agents to validate

• Expected vs actual behavior: Helps agent to use TDD

• Environment details

• Severity with response time

• Bug reports or any other attachments

Impact:

• 50% reduction in bug clarification time

• 30% reduction in story refinement time

• 10% increase in engineering speed

When requirements are clear, coding agents get better instructions. They validate solutions against explicit criteria. Token usage drops because agents don’t retry wrong approaches. Engineers spin up multiple agents in parallel because each has clear outcomes.

Example Template (Story):

Context: Why is this needed? Scope: - Included: API endpoint, validation, audit logging - Not included: UI changes (separate story) Acceptance Criteria: - [ ] POST /api/certificates/rotate endpoint - [ ] Validates device ownership - [ ] Returns job ID for tracking - [ ] Unit tests >90% coverage Definition of Done: - All acceptance criteria met - Code reviewed - Deployed to staging - Documentation updated

No meetings needed. No Slack threads. The template forces clarity.

Problem: PR reviews took 2+ days. Reviewers focused on tactical issues (missing tests, style violations) instead of architectural problems. Specialist knowledge stayed siloed. Experts were the bottleneck and if they didn’t pay attention, critical issues slipped through. With PR volume increasing, this was unsustainable.

Solution: Persona-driven development.

I cloned my team’s specializations as review agents:

• Ethan (DevOps): Infrastructure, CI/CD, resource limits, deployment

• John (Backend): APIs, data models, testing, performance

• James (Frontend): UI/UX, React patterns, accessibility

Engineers run reviews locally BEFORE submitting PRs on their local systems. Agents provide specialist feedback instantly. Human reviewers focus on architecture and design decisions.

Impact:

• 20% reduction in PR review cycle time

• Democratized team knowledge—anyone gets specialist reviews without waiting

• Critical issues caught before PR submission

Some Examples:

API Change Review:

• James (Frontend): “This API change is missing corresponding UI updates in the device management screen.”

• John (Backend): “Add integration test in Android code—devices call this endpoint during enrollment.”

Infrastructure Review:

• Ethan (DevOps): “Pod resource limits too low. This service handles certificate rotation—similar services use 2GB memory, 1 CPU. Current config: 512MB, 0.5 CPU. Will OOM under load.”

One API change, three specialist perspectives, zero wait time.

This method is equally effective in reviewing technical documentation and proposals. For technical reviews we load more personas belonging to different teams and methods like this:

Using this plugin, we democratized team knowledge by letting any engineer get specialist reviews without waiting for the expert to be available. Owners of each persona are expected to periodically update their agent’s knowledge with new patterns which improves review quality over time.

Problem: Work distribution was invisible until retrospectives. Some engineers overloaded, others underutilized. I discovered allocation problems too late to fix them. Constant need to provide status updates distracted me from strategic work.

Solution: Data driven sprint reports with corrective actions.

The plugin generates three reports:

• /sprint-report: Velocity, work type distribution, blockers

• /team-status: Individual workload and capacity utilization

• /analyze-retrospective: Pattern detection across sprints

Impact:

• Work type stabilized and aligned with org targets e.g. 50% product, 20% KTLO, 30% tech debt

• Improved throughput from better allocation. Since engineers weren’t overloaded, they finished work faster. Experts focused on high-impact tasks.

• Reduced burnout through early intervention and balanced workload.

Example (Sprint 100):

Mid-sprint report flagged:

• John: 22 points assigned (110% capacity) ⚠️ Overloaded

• Sarah: 15 points assigned (75% capacity) ⚠️ Underutilized

Action: Redistributed 5 points from John to Sarah based on skillset match and current workload. Outcome: Both completed their work without stress. Sprint velocity: 85% (up from 60% baseline).

The report runs in 30 seconds. No manual tracking. No spreadsheets. Just data. This is part of my daily routine now. It also reduced the need for constant status updates, reducing context switching for the team and me.

The most important part of this approach is the compounding benefits of all of these improvements working together. They not only solve individual bottlenecks but amplify each other.

Clear stories → Agents work faster → Better validation → Lower token costs → More parallel agents

Better reviews → Faster PRs → Higher throughput → More knowledge sharing → Stronger team patterns

Data-driven allocation → Balanced workload → Reduced burnout → Sustained velocity → Predictable delivery

Week 1: Fewer Slack questions. Month 1: PRs merge faster because stories were clear from the start. Month 3: Agents learn codebase patterns from accumulated reviews. Quality improves.

There’s no one-size-fits-all approach of configuration here. In this post I’m sharing my patterns and setup but every team is different. The hardest part is understanding your workflow and bottlenecks. Before configuring anything, map your as-is workflow. Document it. Identify your biggest bottleneck. If you’re a manager, you likely already know where the pain points are, so that’s a good place to start.

Quick Github search will show multiple plugins and marketplaces (like this: https://github.com/wshobson/agents/tree/main/plugins) .

I highly recommend NOT copy-pasting them blindly. That’s a recipe for frustration since these will not solve your team’s unique problems. Instead, use them to learn how to write your own plugins. I use these as resources and merge these with my team’s unique setup, processes and problems to create custom plugins.

We also allocate dedicated time in each sprint to review existing plugins and update them based on our experience so far. This keeps the team engaged and invested. At the end of the day, this process helps them deliver more code faster.

Each plugin follows this structure:

plugin-name/ ├── agents/ # Specialized reviewers or task handlers ├── commands/ # Slash commands for quick actions └── templates/ # Reusable workflows and formats

Customization is iterative. I spent two weeks understanding these patterns and configuring for my team. You’ll adapt based on your problems. There’s no universal “required” configuration—only what solves your bottleneck.

1. Map your workflow: Document your current process. Where do you spend time? Where do engineers get blocked?

2. Identify your bottleneck: Planning chaos? Slow reviews? Allocation blindness? Start with the most painful one.

3. Configure one plugin: Don’t tackle all three. Pick the bottleneck. Configure. Measure.

4. Iterate: Add capabilities as you learn. Refine templates. Adjust personas. Expand coverage.

Configuration takes time. I spent two weeks. Your timeline will vary based on your process and team composition. But the ROI compounds.

This process isn’t about working less. It’s about eliminating coordination overhead so managers can focus on what matters: strategy, mentorship, unblocking, culture.

Your team doesn’t need you copy-pasting status updates. They need you removing bottlenecks.

AI makes ICs faster. But teams need better processes to convert individual productivity into team throughput. These three plugins automate the coordination layer - planning, reviews, allocation - so your fast engineers become a fast team.

Choose your bottleneck. Configure the plugin. Measure the impact.

**Working through similar team coordination challenges? I’m happy to brainstorm solutions or share what’s worked. Also available for talks on AI-powered engineering management.**