At Integral we build and release on weekly cycles. Every cycle one product team member (engineer, designer, PM) is assigned the role of Captain, responsible for leading the cycle.

Small teams avoid assigning ownership because it feels hierarchical. Everyone’s responsible for everything, but shared ownership becomes no ownership. Features drift, everyone has multiple streams, and communication breaks down even when sitting next to each other.

The Captain keeps the cycle on track. They know what everyone’s building and whether it’s going to make the release. They are responsible for checking in on team members, and communicating the release scope across the company.

Why the Captain isn’t a position

Everyone on the team takes turns. We rotate every single week. No exceptions, no “I’m too busy this week” excuses. If you’re on the team, you are Captain. Period.

The rotation isn’t random. We plan it out so people know when they’re up. You get a week’s notice: “Hey, you’re Captain next week, start thinking about what we’re shipping.”

This forced rotation prevents the usual problems: No one becomes the permanent “project person” while others just code. No one gets comfortable never having to think about the bigger picture. Everyone learns what it actually takes to ship features, not just build them.

When you know you’ll be Captain next week, you pay attention to how the current Captain handles scope creep. When you see someone struggle with cross-team coordination, you learn from their mistakes before it’s your turn.

The PM Captains too. They don’t get to just throw requirements over the wall and disappear. They have to own delivery, deal with engineering trade-offs, and feel the pain when their “simple feature” turns into a three-week nightmare.

The Captain makes small cycle decisions for that week like “what we should cut, expand, merge, or drop.” But they don’t have to decide everything; they’re best when they are “figuring out what we need to decide.”

The Captain holds the cycle goals, coordinating and handling communication while others focus on building.

What the Captain owns

Feature completion: Making sure all pieces get built, integrated, tested, and shipped. Tracking progress and identifying gaps.

Scope management: Making trade-off decisions about what’s in scope and what gets deferred. Pushing back on feature creep.

Cross coordination: Working with design, product, operations or other engineers when the feature requires external collaboration.

Cycle timeline: Communicating progress, identifying delays early, adjusting scope to hit deadlines.

Shipping Mode: Deploying all the changes to production, after giving a small but comprehensive demo.

What the Captain doesn’t own

Individual task assignment: Team members choose how to contribute to the feature. The Captain coordinates but doesn’t dictate the approach.

Implementation decisions: Technical choices remain with the people doing the implementation. The Captain provides context but doesn’t override expertise.

Quality control: Code review and testing remain collaborative. The Captain doesn’t approve or reject work unilaterally.

How it actually works

The Captain communicates cycle progress: “this is going well, we need help, this is in danger.” You’re checking up with everyone: “How are you going to test this? How are you going to solve this problem?”

You make scope calls when trade-offs come up. Cut features, merge things, drop what won’t make it. The team can push back, but someone has to drive decisions.

By Thursday, you make sure everything’s tested and ready to ship. Because if something breaks, it’s on you to make sure it’s fixed.

Captain skills by feature type

New feature development: Strong product sense, ability to make scope trade-offs, good at cross-functional coordination.

Infrastructure work: Technical depth, understanding of system dependencies, ability to communicate technical concepts to stakeholders.

Performance improvements: Data analysis skills, benchmarking expertise, patience for iterative optimization work.

Bug fix initiatives: Debugging skills, attention to detail, ability to prioritize fixes by impact.

We match cycle Captain assignments to the type of work and the person’s strengths when possible.

When Captain authority matters

Scope creep: Someone wants to add “just one more small feature.” The Captain decides whether it fits or gets deferred.

Integration conflicts: Two pieces don’t work together as expected. The Captain coordinates a resolution and makes architectural decisions.

Timeline pressure: The feature is behind schedule. The Captain decides what gets cut to hit the deadline.

Cross-team dependencies: External team changes their timeline. The captain adjusts scope or negotiates alternatives.

The real downsides

Every Friday we give direct feedback to the Captain: “Yeah, you did a good job, but you were annoying on Wednesday. We could have had this conversation much earlier."

Or: “You missed that point. We released; who was Captain? You were Captain. We didn’t test this. Why?”

It can force you to push too much. You can miss critical things. It’s distracting from your own work because you’re focused on everyone else’s.

But we “try to intentionally make it better” each week. The feedback is direct, but the goal is always to learn and improve.

Why it works despite the pain

Features actually ship because someone owns whether they ship. When you know you’ll be Captain next week, you pay attention to how the current Captain works.

Everyone learns to coordinate, there is no single “project manager”. You understand what it takes to drive features to completion.

The feedback is direct and fast. We fix Captain problems in a week, not after months of accumulated frustration.