A Manager's Guide to Working with Claude

Written by Michael Rood on 

I start most mornings with my coffee and two (sometimes three) automated summaries waiting in Slack. One tells me what my team did yesterday—tickets moved, PRs opened, potential bottlenecks. The second checks upcoming releases and cross-examines those with our JIRA board, flagging changes stuck in QA or review. The third is a recap of my team’s weekly performance in terms of velocity and defects. By the time I’m at my desk, I have a good idea of where to put my focus and what to follow up on. These automations let me spend more time diving into PRs and resolving risks and less time pulling data to understand where the risks might be.

My Claude Toolkit: Environments & Use Cases

Claude Code

Claude Code has become my primary interface for anything code-related. I use it when I’m actually writing code, but also for investigations and research. When I need to understand tickets in our backlog, research technical approaches, or onboard to unfamiliar parts of the codebase, Claude Code is where I do that work. It lets me interrogate the code, trace through implementations, and understand context without hunting through an IDE. For a manager who needs to stay technically informed without being in the code daily, Claude is a great way of efficiently navigating a codebase.

Claude in Slack

This is where I spend 80% of my AI time. Slack has become my command center with Claude and its connectedness to our systems as the commander.

Workflows that automate team summaries, upcoming release reminders, engineering metric summaries—all run before I get into the office. These are designed to make sure I know what my team is doing and surface any risks: aging PRs, QA issues, tickets bottlenecking in our process.

But the real game-changer is using Claude for operational investigations directly in Slack. Claude can query Splunk, Snowflake, look through our codebases, and read and make changes to JIRA tickets. After I’m finished with my investigation I can add that context to a JIRA or open simple pull-requests directly from Slack. It’s incredibly convenient to just live in Slack and I’m increasingly reluctant to leave.

I’ve built Claude Commands and Skills in Slack channels that help with common investigations. These are starting to evolve into something like a runbook—a collection of repeatable diagnostic workflows. It still needs work to truly function as a runbook, but I think it’s the right direction. Instead of documenting “here’s how to investigate X,” I’m building commands and skills that will correctly go investigate X.

Automations

Daily Rhythms: Coffee Routine

Every morning before I get into the office, Claude delivers two automated summaries to my Slack.

Daily Team Summary: This recaps the previous 24 hours across the team. I track two main things: ticket movement (what got created, what’s progressing through the board) and open pull requests per engineer. For each PR, Claude provides a one-sentence description so I can decide whether to dive in or just stay aware. It attempts to distill everything into “key takeaways,” though this is where the automation shows its limits—Claude will sometimes flag non-issues or make weird assumptions and I read those with a grain of salt. But it tries and I appreciate the attempt. It also tries to identify engineers that may be burning out, working on weekends, etc. It doesn’t do a great job of this either but with a bit of tweaking to the skill I think it can catch some pretty simple signals like commits or JIRA movement on weekends.

Upcoming Releases Tracker: This checks my team’s tracked releases against our JIRA board and alerts me if a ticket is ready to ship on time or whether it is likely to slip due to getting stuck in code review, QA, or PM Review. When ready to ship, Claude prompts me to create a release plan that conforms to a specific format. (see Release Management on Autopilot) I find that Claude does an excellent job of describing the changes in plain english as well as the impacted systems. It does less well in identifying risks of the release and identifying potentially impacted teams and I find myself generally writing that part of the communication.

Engineering Summaries: I Spy

My org reports on engineering metrics regularly—cycle time, defect rate, ticket velocity, the usual suspects. I have a Slack automation that handles the investigation work for this reporting. It pulls high-level metrics like ticket counts and cycle time, but more importantly, it identifies outlier tickets and investigates why those tickets were outliers.

The real value is in the deep dives: Claude analyzes process flow kickbacks (when tickets move backwards due to bugs found in QA or PM review failures) and identifies bottlenecks. Combined with my knowledge of sprint activities, this investigation helps me both spot issues and think through solutions to our software process problems. Instead of manually digging through data, JIRA, and other reporting tools, then doing data entry to get it into a shareable format, I can focus my time on addressing the defects and bottlenecks Claude surfaces. This summary gets shared with other leaders in the org.

Release Management on Autopilot

Release plans are internal communications that inform teams across our org what we’re releasing (in plain English) and when. They include risk assessments and highlight other systems and users that might be impacted.

The generation is completely automated in Slack. Claude creates surprisingly good plain-English descriptions by combining context from JIRA tickets and pull requests. For single-system releases, I rarely need to edit the generated plan. When multiple systems are involved, I usually need to simplify the description. Once I’m satisfied, I manually post it to the appropriate Slack channel.

Meeting Summaries

I’m a huge fan of Zoom meeting summaries for engineering meetings—design reviews, knowledge sharing sessions, technical deep dives. Every design review for my team gets recorded with the link posted to Slack, and the AI-generated summary accompanies the video for easy topic recall and documentation.

I find the summaries valueable for attendees who couldn’t make it, as well as keeping leadership and stakeholders informed on technical details without requiring them to watch full recordings.

The one pain point: Zoom’s web interface for fetching summaries and recordings is clunky. I find myself regularly annoyed navigating through it. Despite that kudos to zoom for the integration and the product.

Documentation Recommendations

I’ve also semi-automated documentation maintenance. Every PR gets analyzed, and Claude makes recommendations for augmenting our documentation based on the code changes. This helps keep our docs in sync with the codebase without requiring engineers to remember what needs updating. This documentation automation, together with the release management automation prompts the removal of launch flags in Slack, with pull requests made directly in Slack, sometimes from my phone while stuck in meeting marathons.

The Wish List: What’s Next

The biggest gap in my current setup is the inability to write to Google Docs from Slack. This is the one thing that still pulls me out of my Slack-centric workflow.

Once I fix this limitation, I’ll be able to:

All of this without leaving Slack. Right now, these tasks require context-switching to Google Docs, which breaks the flow and adds friction.

Closing thoughts

Not everything works perfectly. The daily summary will sometimes go off-the-rails and try and stack rank my team. Release plans for complex releases aren’t ideal. And the team metrics for cycle time and such need to be verified for completeness. But it does save me a significant amount of time. If you’re just getting started, pick a frequent and relatively simple task to start. For me, that was daily release management and planning. The more I automated the more I wanted to automate and the more aware I became of everything my team was doing.