Captains
Apply now to join Glue Club, the home base where the strongest startup leaders in the world come together to find sanity, opportunity, and growth amidst the chaos of building a company. I pour all my mentorship and coaching energy in to Glue Club, in case you’re looking for something more than a blog post… Head over here to learn more.
A lot of us are familiar with decision-making frameworks like RAPID or RACI. They are useful tools for designing and assigning responsibilities on a project. In addition to kicking off a project, I sometimes use them when org design or project execution feels messy in order to help me debug what’s wrong. Putting names in boxes often helps me figure out where the mess is: too many people think they’re in charge, there’s no one in charge, the Responsible individual isn’t Consulting the right people, no one knows who the Approver is, etc.
That said, as someone who likes efficiency, I honestly get tired of all the letters. What’s the C? What’s the difference between the A and R? D vs P vs I? I swear that unless you worked at Bain (who created RAPID) you never remember what all the letters mean — you only remember the R.
And honestly, as a CEO or a company builder, you usually just want to make sure that each project has a clear owner and then hold that person responsible for everything after that — did they meet their goals? Did they inform the right people? Did they collaborate effectively? Said in RAPID or RACI terms, you honestly just want to assign the person in the R box and then make them fill out the rest of the matrix.
Enter Captains.
Captains is an ownership model we implemented at Lambda School that was suggested by the always brilliant Laura Reisert. We arrived at it through the following process:
We were experiencing ownership issues and projects that were slow/disorganized/unclear/etc. Standard startup stuff.
Molly hates tooooooo many letters. I also really don’t like the word Owner (see: slavery) and DRI (directly responsible individual), a term that some people use but, again, soooo many letters.
Laura suggested a word and a model that Trader Joe’s uses to design their store teams, which she had studied in a past job — Captains.
It was honestly a brilliant and simple model that allowed us to easily ask “who is primarily responsible for making this project/goal/whatever happen?” — Who is the Captain?
This model comes with two very nice features:
1) Solid emoji options 👩✈️🫡🚢
2) A very obvious implication that there can only be one Captain per ship — one single owner for a given project or goal. One of my struggles with RAPID and RACI (other than toooo many letters) is that it becomes a sea of names, and that makes it very easy to break the cardinal rule of clean delegation and decision-making — you can only have one name in the R box. Designing and deciding the single owner for a given project or goal is often very hard work. It’s so tempting to put two names in that box! Susie owns the project, but Joe is helping her. Or Susie and Joe will work together to make sure it happens. NO! There’s only one Captain on a ship.
Let me just pause here and say — unclear ownership is honestly the single thing that slows most companies down. Success comes from hundreds of projects being executed really well. Great execution often boils down to two things: 1) a clear, aligned definition of success and 2) a single, clear owner. If your most important goals don’t have one name next to them, if your most important projects don’t have a clear, SINGLE owner, you are likely moving more slowly than you could or should be.
At Lambda, when we rolled the Captains model out, we asked people to fight for that clarity on every project: that there is always an answer to “Who is the Captain?” AND that there is only one name — One Clear Captain.
The other thing we did when we rolled it out was to clearly define the role of a Captain. Again, versus filling out the letters and the boxes in RAPID, we made it clear what the Captain was responsible for and part of that was building the right crew — consulting the right people, getting the right approvals, etc.
For us, being a Captain meant:
Project completion: It is your job to define what success looks like and get the project to completion no matter what. It is your job to define what completion looks like including a high-quality definition of success, deadlines, who needs to be involved and agree with decisions, etc. Captains make it specific and clear what success looks like, and make sure we get there. If a project is something we decide not to do, it’s a Captain’s job to wrap up the project and communicate to all stakeholders.
Delegate where needed: It is not your job to personally execute the project, but to ensure that you have the resources and support you need so that you can steer the project to completion. We are here to help ensure that you can get to completion successfully. Captains ask for what they need in order to be successful.
Escalate effectively: As a Captain, it is your job to ask for help when you need it. Every project hits roadblocks. Captains don’t let things get stuck. Captains escalate quickly when they find a problem they can’t solve themselves.
Communicate: It is also your job to communicate progress regularly and keep stakeholders updated. Captains regularly share the status of their project with relevant teams.
No excuses, no surprises: Captains are ultimately responsible for the success or failure of a project or initiative. This includes (if required) overcoming roadblocks, asking for resources, and ensuring stakeholders know about issues as soon as they arise.
Once we rolled this out, Captains became a part of our culture. We asked people to have a Captain mindset in their roles and to continually reflect on the following three things:
What am I the Captain of in my role? We asked folks to think as big as possible and for everything where they were the Captain to reflect on the responsibilities listed above. It gave us an easy way to push folks to talk with a manager or leadership team member about what was working and what was not working, and most importantly, where they needed help.
Are there any important pieces of work or projects that don’t have a clear Captain? It’s hard once you’re running a company to identify where things might be messy. Sometimes it’s obvious but often, it feels clear to you and confusing to everyone else. Making this something that everyone owned — if a project felt Captain-less or like it had multiple Captains — made it much easier to identify messes.
For any project where you’re not the Captain, figure out what you can do to support the Captain. Captains don’t work alone — they simply steer the ship. Part of creating a Culture of Captains, for us, meant asking people to think about how they can support the folks that were leading various ships.
I’m sharing this because I’ve honestly found myself explaining the Captains model over and over again in recent conversations with founders and in the Glue Club. It’s elegant and simple, and a very effective tool for running a company. I really loved it.
I gift it to all of you in the hope that it helps make running your company a bit easier.