Mark Bennett: Using Claude Code in Teams

Mark Bennett: Using Claude Code in Teams

What is Claude Code?

Claude Code (CC) is a command-line tool that helps you with your software project.  You give it selected permissions for things like editing and compiling code, and it shows you what it’s doing as you proceed.  You’re free to step through every single diff if you like, though you may get over this pretty quick.  You might start to trust it more over time if it seems like it knows what it’s doing a majority of the time.  It works from the command line, where you type commands, vs. a modern graphical UI app; it’s a very retro vibe, though it’s only been around since early this year.

Possible Confusion with ClawdBot

Although the names sound similar, these are two very different products.  Claude Code is a commercial AI product from the company Anthropic, who offers other products as well, all with the “Claude” prefix.  ClawdBot is a completely separate open-source AI project that has recently gained a lot of attention.  Even more confusing, ClawdBot can be configured to use Claude’s service.

How Does CC Scale?

Sean: Hello again Mark.  When we last spoke, you echoed some of the same incredible time-compressing effects that Claude Code (CC) can have for an individual experienced coder as some of the other people I’ve spoken to lately.  Crazy sounding things like more than an order of magnitude.  So CC is great for the individual coder, but how does it scale to multiple developers and teams in a more realistic corporate setting?

Mark: Thanks for having me back Sean.  You raise one of the biggest questions that corporate code governance will need to navigate.  On the one hand, real production code bases have millions of lines of code and potentially hundreds of developers.  You’ll recall I did mention pairing CC with the Git version control system, they do work well together, but by itself Claude Code has virtually no multi-user coordination at all outside of Git.  It doesn’t even recognize when other versions of CC are active within the same project or branch – this is a large “yet to be determined” area for CC, what should Anthropic do?

1. Keeping two or more Claude Agents stepping on each other in the same branch is an open challenge.  If two developers have their CC make changes to the same file at the same time in a shared directory, it’s likely some changes will be lost.  CC does NOT use file locking.
2. If you give each developer their own branch it increases the merge challenges.
3. More meetings to help coordination. Seems more expensive
4. Use JIRA, this can add more overhead
5. Rely on managers. Clearly have an up front role.

Shared Folder vs. Git:

Although using Git pushes and pulls is much safer, it’s not really something you’d want to do on a minute-by-minute basis.  This activity would partially negate the speedup of using multiple developers.  Either:

• Put developers on their own branch and periodically merge, or (aka “batch mode”)
• Have them work in a shared folder and in almost constant communications. (aka “realtime”)

“So just giving every developer their own Git branch to use, does that just “fix” it?”  It fixes some issues, but incurs its own overhead.  Git is a very important tool, and I DO suggest using branches, but eventually developers need to merge their code, this is not zero-expense nor automatic.  Claude can certainly help expedite the process.

So how often do you want to merge Git commits?  If you’re fine with many hourly or daily, then Git is the answer.  But if you want a real-time shared coding experience, then a live shared folder and constant communication could be feasible.

“Have more meetings to discuss it!?”  God no, CC is antithetical to the addictive and expensive time-wasting habit that MOST meetings seem to devolve into.  More meetings will gum up the works and slow everybody back down again.

JIRA to the rescue?  Maybe, for some project managers who are very productive with it, but remember last time I said that it often takes longer to write up a bug report than to just have Claude fix it.  Used incorrectly, this is still adding “more process” to an activity that begs for less of it.

So the answer to this question isn’t settled yet, but I see Managers as playing a front line role.  Claude Code has been around for less than a year, and geared towards individuals, so this is still an evolving situation.

You may want to avoid shared directories, or possibly try one of the techniques discussed below.

This begs a comparison to the old Pair Programming idea, which was trendy some years back.  In many ways CC team programming is the far opposite of that old “pair coding” practice.  First of all, Claude is your coding buddy here, not the other developer.  You and your human partner will often NOT be looking at the same code at the same time – it’s allowed if needed, but this is not a consensus building activity.  Rules aren’t strict here, but they should have a pretty good idea of what each other is doing, and what directory they’re each working in.

One idea when using a shared folder is that each person and their CC instance can work on different aspects of the code, for example one developer writing code, and a second developer focusing on testing, doc and Git.  Though when a problem is found, there needs to be clarity on which developer/CC pair is going to fix it.

Another idea on shared folder mode is that each team member could have a different role based on the section of code, for example one team member focuses on UI, the second on the database layer, and a third on back end services.  But I’m not convinced this will work well since CC actions often affect multiple levels of code.  Imagine an employee database app that wants to track a new piece of information about each employee, let’s say “preferred_name”.  Implementing this would cut across all 3 roles, affecting the UI, the backend, and the database.

So what’s to be done? I see two models for evolved “processes.” I still see the need for very lightweight processes, but they must jettison most of the busy work.

Sean: If your objective is to get new code developed faster it sounds like you may be able to allow two developers to share a folder but beyond that you need a source code control tool like Git. Assuming you are using Git what’s your take on the maximum number of developers who can collaborate in real time.

Mark: I think two can be done and three is probably the absolute limit today for real time sharing a common set of files.

Sean:  take me through what it would look like as the team scales from a solo developer to say 15.

Mark: My sense is three to five for Realtime (shared folder); 15 if you’re consistently using git branches.. Let me take you through it starting with the easiest example first: Two developers trying to both use CC on the same project and branch, to work “together” on some set of tasks, but each leveraging Claude as well.  This can even be done to mentor new folks.  I’d suggest:

• They both sit in the same physical room, or both have two-way headsets on.  If you’re going to juggle chainsaws with a friend, there should be a constant communications channel open.  There’s a talk-vs-text movement in part of the AI community, talk being seen as generally much faster.
• They start out working in the same top level shared directory (if possible)
• Work in the SAME Github branch; this type of coding requires good situational awareness.  Maybe one coder volunteers to manage Claude on the updating of Git commits and low-overhead doc.
• Then each launches one Claude Code instance from that shared starting directory.
• They want to be hyper aware of what each other is doing, while balancing that with pursuing their own thoughts and coding goals.

I’d say this could be expanded to a pod of maybe 5 developers, especially if some are new.  At that level of people, you might want to have a rotating role of team lead or sergeant – this role is a possibility for teams that think it’s a good idea at certain times.  So N=5

As one of your other recent articles pointed out, more developers can actually slow down coding. How do you assign N developers to work with Claude Code, but not have them slow down by N, that’s the challenge.

And going slow, at times, can be a good thing if there are critical design issues to consider.

The problem to solve: How to let N developers use Claude in a coordinated way, where they each maintain a productivity bonus such that N developers do more work than N-1.

And again it’s not always about being fast, good design can often benefit from seemingly extended discussions, there’s got to be a balance here somewhere. Let’s take it one step at time

• 1->2  Get used to “in each other’s business ALL THE TIME”
• 2->3  Probably less traumatic than 1->2, especially if the third person is willing to do some of their own “learn by doing” (with Claude’s help of course)
• 3->4 and beyond  At this point, 4 and beyond, you really should be using Git branches.

First up:

Radically different Sprints: “Sprints 2.0”

1-Week Sprints

Monday Morning:

• Monday morning sees a 1 hour or less meeting with all interested parties.  It’s controlled chaos, but by 10am everybody knows the theme for the week.  This should also include people from Sales, Marketing, support, doc and the C-suite.
• Project managers and QA people still use their respective tools, but they or Claude do most of the data entry
• Developers generally have their own branch, and 1 to 3 things to focus on that week, hopefully it ties into the bigger goals, and generally they’d have it in their head.  Maybe a half-page TODO list so things don’t fall through the cracks.
• And it’s fine to define and prioritize stretch goals.
• Hopefully somebody can show some visual goals of what’s desired.

Most of Week:

• Let developers and Claude Code do coding.  For skeptical coders, remind them that Claude is fine to take care of “boring” stuff like initial documentation, unit tests, etc.
• One of the time-sucking distractions in projects is status updates.  Developers should be productive, and we just had a meeting that ended at 10am for what we’re all doing this week, and their work product will be demo’d on Friday, so there really shouldn’t be a lot of sub-day updates needed.  Product and Project Managers should be wandering around in the developer area, gathering and caching verbal knowledge, with some accord for at least pooling developer interruptions.
• No daily scrum, too much overhead.  Claude can handle most of the data entry for Jira to keep everyone up to date. Developers are allowed to chat of course.  If somebody really doesn’t know what to do, ask the group. Managers should be interacting with their team members enough so that they know the updated status, and any critical blockers, by heart, along with a heavily modified lightweight TODO list.
• Formal meetings should be extremely rare. No “quick check-in with everybody.”  Doesn’t the associated Project/Product Manager have the current state in their head, can’t you just ask them?
• Still need a meeting: go to a cube and hash it out quickly, 1:1, or 1:1 on Slack. But Slack can become a time waster if not used sparingly.  Managers help their developers the most when saving them from meetings or documentation so they can keep coding.  Want to ask the developer, try the manager first; they’ll either know the answer, or should know the answer for next time.  And maybe try Claude; just be careful of Claude’s false confidence, times when he just doesn’t know he’s wrong again.  CC can also answer a number of the questions that a manager would previously have had to ask a developer.  Having a visual aid ready can often expedite a chat.
• Meetings should morph: ? Short Meetings ? 1:1 discussions ? shorter is still better.  Managers act as active caches of rapidly changing info.
• Key take-aways:
  • Respectful cubicle hopping
  • Show me, don’t tell me
  • Tell me, I’ll capture it, I’ll tell them
  • Show, don’t just tell.  Give deference to “show me” in all directions.

Friday: Review, Merge and Demo

• Git is still important.  On Monday, developers were consulted on what branch they’d be coding in; developers who constantly talk with each other can try sharing a branch.  Now on Friday all this new code needs to get merged back into a common WORKING branch; if not feasible, then merged into a clearly labeled broken branch.
• Developers may need to do code reviews with other developers to solve thornier merge issues.  This technical debt should be paid every week.
• The final goal on Fridays should be working demos, and a hint at priorities for next week.

Sean: OK so accelerated Sprints, Sprints 2.0.  You mentioned having another process idea?

Mark: Thanks Sean, yeah, the second suggested process builds on the first.

Hackathon 2.0: Almost a Code Vigil

The Scenario: You face a crisis.  For various reasons your project is a year behind schedule!!!  Some places call this a “Code Red.”

The Fix: Plan a 2-to-6 week round-the-clock coding marathon.  It’s the same mix of people and good habits as the normal Short Sprints, but now working in round the clock shifts.  If you can’t work that way… try following the best advice I ever heard from a CEO, “we suggest you get over it.”

Some Specifics:

• Some decent 24/7 food and beverages, with some hot meals at anticipated times.
• Not all coders need to be working in CC all the time, it’s OK to participate in discussions.  It’s also OK to have some temporary breakout teams if needed, in their own safe Git branch.  Ideally those efforts don’t stay separated for too long.
• Talk talk talk. Try try try. Show show show
• Some remote workers are OK too, some things can’t be helped. BUT if you do still have an office, this is the time to use it!  Have a 24/7 coding vigil for as many weeks as it takes.  Consider some good AV gaming headphones, especially for remote/Slack users.
• If some teams are remote, especially across the infamous California/India timezone gauntlet, this provides a nice respite, as all teams are doing the 24/7 shifts at the same time.  Have some faith that occasional sleep and family time are very important too.
• There will be some logistics costs for food and possibly some childcare reimbursement – but you’re saving your company, so don’t penny-pinch too much here.
• Setup webcam(s) so remote users can feel more involved and absorbed.  Or maybe even a roving bot with 2-way voice and video link.
• A Projector table: For running demos, and showing charts and stats.
• Expect to see upper management in attendance.  If they can’t be bothered, then the company was already going to fail long before Claude Code ever showed up.
• SHOW ME takes priority, in all directions.  Developers’ code, UI mockups, bug report screen shots, etc.
• Somebody needs to be a TODO LIST keeper.  This keeps great ideas from falling through the cracks.  Consider text editors, or very lightweight use of JIRA; beware specialized-tool-lock-in.  VI and Notepad can manage a short TODO list
• Have different instances of CC working with managers and JIRA.  When you must have “process”, make CC help you with it.
• Try to separate personalities from ideas
• Consider a “DJ” of sorts, maybe setting up some light music and mood, but who also knows what’s going on.  Maybe near the Projectors and Food tables.  When somebody new arrives, maybe the DJ helps give them the current lay of the land. Maybe a DJ could also help be a backup on logistics stuff.

The Cadence:

• Talk talk talk
• Try try try (Fail fast)
• Show show show
• Yeah yeah yeah
• Stop stop stop! (hopefully not too often)

Inverse Management Hierarchy

• Manages work to clear away busy-work items and keep coders coding (w/Claude of course).
• A good product/project manager should basically be a verbal cache for communicating with the developer and other interests.
• Interruptions are allowed, they just need to be respectful and hopefully pooled and to the point.
• Managers should also have the role of “wake me when this is working”

In Both Cases:

Sean: So the second form, the code vigil, is a greatly amplified version of Short Sprints.

Mark: Sure, remember I said “the same people and same good work habits”.  Some common things I’d point out:

• Lack of most formal meetings
• Inversion of control:
  • Managers remove blockages and busy-work from their underlings.
  • MINIMAL BUSYWORK for engineers.  Product and Project Managers have a busy role to play.
  • Let professionals really focus on critical tasks

• The Cadence:
  • Tell beats silence
  • In short bursts, Tell beats “write it down”
  • Try beats Tell
  • Show beats try/tell
  • Shorter talk transitions to try, and just skip the write-it-all-down for now
• QA, Support and Doc people have critical roles to play here as well, though perhaps altered a bit from their traditional form.  Things in large companies do eventually need to be written down, and tested.  Also real-world feedback can cut through a lot of academic debates.

In Closing:

Sean: In our last article (link) we talked about the amplification of the individual programmer via Claude Code.  While this can be a huge benefit, it’s not the world that many managers and developers live in.  And since CC currently lacks wiring to work in teams (though doesn’t forbid it  either), we find ourselves back using other tools (Git, Jira) and human processes to work around that.  And if you ask me what type of track record and payback window of time of Mark’s processes, I’d have to politely remind you that this stuff didn’t exist a year ago – we’re all in the Freshman Class on this stuff.

Mark: What CC has demonstrated for me is that most recurring mandatory meetings are unnecessary because they are not worth the cost in developer time compared to other synchronization techniques. There ARE productive and useful meetings, I even listed one at the top of Monday mornings after all!  But MOST meetings can be replaced by a quick 1:1 chat in somebody’s cube, or be handled offline by the responsible manager.  Talking is important, it’s just not a replacement for getting actual work done.  And having a meeting where every developer is on their laptop most of the time is a symptom, not a fix.