Small Business and Startups

Titles are for pay. Roles are for Tuesday.

On a sailboat, the best sailor isn't always at the helm. Split how senior someone is from what the work needs from them, then write the names down.

Brandon Harris · Essay · 5 min read

Share
An older sailor trimming the sail of a small boat heeling through the waves while two crew work beside him

On a sailboat, the person with the most experience isn't always at the helm. Some days they're forward, trimming the sails, because that's where the boat needs them. The newer sailor steers. Nobody thinks anyone's been demoted. Everybody aboard knows who the best sailor is. The question on the water is a different one: what does the boat need from each of us today?

Most product orgs can't do that. The title says Senior PM, so the senior PM runs the squad, whether the squad needs a strategist, an operator or someone to translate between design and engineering. The title is doing two jobs. It tells you how complex a problem someone can handle. It's also supposed to tell you what they do all day.

Those are different questions. Cramming them into one word causes a lot of the friction I see in product orgs.

Split the word in two

When I redesigned the operating model for a product, design and engineering org, I pulled them apart.

Title conveys complexity. Pay, scope, how much ambiguity you can be trusted with. It moves slowly, and it should.

Role describes what the work needs from you right now. And any work worth doing needs three roles filled:

  • Strategic Lead. Owns the why and the what: the problem, the outcome, the bet, and what we won't do. Keeps asking whether we're working on the right thing.
  • Delivery Lead. Owns the how and the when: cadence, dependencies, getting it out the door. Will it ship, and when?
  • Technical Lead. Owns how well it's built: architecture, quality, the decisions that are expensive to undo. Will it hold up, and what will it cost to keep?

Everyone else is the delivery team, the people building the thing. Designers, engineers, analysts, whoever the work calls for. It all comes back to those three seats, though.

The roles don't follow the badge

Here's the part people push back on. The three roles don't have to follow the title, and they don't have to be split by function.

Someone with a technical background can be the Strategic Lead. Someone else with a technical background can be the Technical Lead on the same work. A PM can be the Delivery Lead. So can a project manager, or someone from operations who's great at untangling dependencies. The role follows the problem.

It doesn't have to be the same people every time, either. The Strategic Lead on one outcome might be the Delivery Lead on the next. And one person can hold two roles at once. On a small team that's normal.

What can't happen is an empty seat. The three roles have to exist, every time. If nobody holds delivery, the work slips, and nobody knows whose job it was to notice.

Say it out loud

Of everything in the model, the change that mattered most was the simplest. We declared the roles. For each piece of work, we wrote the three names down where everyone could see them.

That sounds like paperwork. In practice it ended a lot of "who owns this?" arguments, because the answer was already on the page. It gave people a way to stretch without waiting for a promotion. And it let me staff work around the problem instead of around the org chart.

It works at any size. An outcome, a project, a single deliverable, a roadmap, the way a whole squad runs. If you're trying to get something done, name the three.

The clearest payoff I saw was in planning. We started naming a Strategic Lead, a Delivery Lead and a Technical Lead for each major piece of work before the planning period began. Those three worked out what had to happen, why, and what it depended on. By the time execution started, someone had already been thinking about it, and the teams walked into something ready for them to put their hands to the shovel. ("Plan like a weather forecast" has the rest of that story.)

Why it matters more now

The lines between functions are blurring, and quickly. With AI in the mix I've watched designers write PRDs, lead specs and build working software. I've watched engineers take on go-to-market work, and PMs build features and commit code.

Titles can't keep up with that. A title describes a function, and the function is moving. A role describes what the work needs, which is the thing you actually have to staff. If your org still assumes the designer designs and the PM writes the spec, a lot of that new range sits on the bench.

Where it gets hard

Two things are worth having ready before you start.

Career anxiety. Once role isn't tied to title, people ask the obvious question: so how do I get promoted? Have the leveling story ready on day one. Otherwise every role assignment gets read as a ranking.

The Delivery Lead gap. Plenty of people want the Strategic Lead seat. Fewer raise a hand for delivery, and it's the seat that makes the work land. On a boat, nobody fights over the tiller while the sails flap. In a product org, people do.

Titles are for pay. Roles are for Tuesday.

Where the metaphor breaks

A sailing crew can swap positions between tacks. Teams shouldn't swap that often. A role that changes every week barely counts as a role, because nobody builds the context to do it well. Let a role run for a piece of work, start to finish. If people rotate, write the rules before anyone does.

A boat also has a skipper whose word is final. Three leads don't, unless you say so. Put the decision rights on paper: which calls belong to strategy, which to delivery, which to the technical lead, and what happens when two of them disagree.

And on a boat, nobody's paycheck depends on where they stand. In a company, someone holding a role that looks bigger than their title will eventually ask why the title hasn't caught up. Sometimes they're right. Have the answer ready.

Try this

  1. List the most important pieces of work your team has right now: outcomes, projects, whatever unit you plan in.
  2. For each one, write who actually acts as Strategic Lead, Delivery Lead and Technical Lead today. Go by who does the work, not who's supposed to.
  3. Circle the empty seats. Those are your real risks.
  4. Look for doubles, like two people both acting as Strategic Lead on the same work.
  5. Fill the gaps, put the names somewhere the whole team can see them, and check back in a month on what got easier.
Any industry10 to 50 people50 to 250 peopleLeadership and org designProductDecisions

Share

Not sure who holds strategy, delivery and the technical calls on your team? Let's write the names down.

Read next

All writing