Similarities Between Leading Agents and Leading People

Why scaling autonomous AI agents has less to do with prompt engineering and more to do with classic organizational design.

Hi everyone - What happens when one person runs six to eight Claude Code sessions and another six to eight Codex sessions at once? Coding becomes less about writing code and more about leading a team! 🤯

To help dive into this new way of thinking about management and working with agents, I chat with Francis Ma - an entrepreneur, tech executive, investor, and former Google product leader who helped shape Firebase.

Check out our conversation below:

The full podcast summary and transcript can be seen here.

Also, besides ▶️ YouTube, you can listen/watch on 🎧 Spotify and 🍎 Apple Podcasts if these services are more your style!

Systems Thinking and Managing Organizations

Whether you and I are leading an organization made of agents or an organization made up of people, what we will have is a hierarchy:

Let’s say you are the leader of this organization. What is your role? Your role is to help drive results, and you do that by relying on the output of your team.

For a moment, let’s say that your team is made up of people. What is needed for this team of people to be successful?

I am going to simplify it into the following:

• A clear vision that tells everyone where the team is headed and what success looks like.

• Shared standards, like a design system or coding guidelines, so work built in parallel by different people still fits together as one product.

• The right people on the right problems, with work matched to each person’s strengths and experience level.

• A cohesive team where people trust one another and work together instead of around each other.

• Friction-free onboarding that helps new teammates quickly pick up the history, the lingo, and where everything lives.

• Proper communication channels, so information and decisions reach whoever needs them without a game of telephone.

• Feedback that flows both ways, where people feel safe saying what is and isn’t working in standups, 1:1s, and retros.

• Trust and autonomy within clear guardrails, so the team owns the how once the leader has set the what.

Keep this list handy. We’ll revisit it shortly, but with a team of agents instead of people.

Managing a Team of Agents

Now, let’s say that your team is made up of agents instead:

What this team needs to be successful looks a lot like what a team of people needs, and Francis learned this firsthand. When he first started parallelizing his work, one agent built a beautiful landing page while another built out the rest of the product, and the two didn’t quite look the same. Underneath, the code was architected differently too.

The fix wasn’t a more detailed prompt. It was the foundation that comes before the prompt, starting with a shared design system. This is the same idea behind Google’s Material Design, which let thousands of UXers build products in parallel that still had a similar look and feel.

Francis sees many of the same patterns in leading organizations and in orchestrating fleets of agents. He breaks them into three parts:

1. a very clear goal

2. shared systems like branding and coding guidelines

3. a feedback loop where the team learns and improves run after run.

None of these three parts are specific to AI.

Even picking models has a human parallel. In my own setup, the small, fast models behave like nervous early-career teammates who say “I got it” and do what they’re told, even when it’s wrong. The most powerful models behave like seasoned veterans, with the strongest opinions, the most stubbornness, and the occasional bit of drama. Francis calls this “the art of matching the problem to the talent,” and it applies to models just as much as it does to people.

Let’s revisit our list from earlier on what a successful team needs, this time tuned for a team of agents:

• A clear vision that tells every agent where the team is headed and what success looks like, ideally in terms it can measure.

• Shared standards, like a design system or coding guidelines, so work built in parallel by different agents still fits together as one product.

• The right models on the right problems, with work matched to each model’s strengths and “experience level.”

• A cohesive team where agents stay in their own lanes and build on each other’s work instead of undoing it.

• Friction-free onboarding that helps every new agent session quickly pick up the history, the lingo, and where everything lives, usually through files like CLAUDE.md and AGENTS.md.

• Proper communication channels, so handoffs, status updates, and questions reach whoever needs them (often you) without a game of telephone.

• Feedback that flows both ways, where agents are invited to say what is and isn’t working after each run, and the lessons get written back into their instructions.

• Trust and autonomy within clear guardrails, like permissions, limits, and tests, so the agents own the how once you have set the what.

Put the two lists side by side, and only one bolded word changes. Everything else is the same.

Conclusion

Seeing the side-by-side comparison between human organizations and agent fleets was a real lightbulb moment for me. It shows that as AI capabilities scale, our role shifts from micro-managing individual tasks to designing high-performing systems.

The best engineering managers and product leaders don’t write all the code or have all the ideas. They build the environment that makes great code and great ideas inevitable. That is a skill worth practicing, whether your teammates are people, agents, or some combination of the two.

What about you? How are you structuring your agent sessions, and what organizational patterns have you noticed emerging in your own dev workflows?

Drop a line in the comments or reply to the newsletter. I’d love to hear how you’re approaching it!

Lastly, follow me on Twitter / X if you aren’t already. You will get bitesized updates from me on a variety of topics you absolutely will find interesting 😅

Cheers,

Kirupa 🚀