Watch a pickup game in a schoolyard for five minutes. Nobody has a position. The ball goes left and twelve kids go left. It squirts out the back and twelve kids turn around. Somebody plays in goal for a while, until the ball comes close and they can't stand it anymore, and out they run too.
And it works. Everyone touches the ball, the best players carry the game, and nobody needs a coach.
Early product teams look exactly like this, and for a while they should. A handful of people, one product, a few customers. The founder writes code on Tuesday and takes a sales call on Wednesday. The engineer answers support email. The designer writes the release notes. Everybody runs to whatever's on fire, and because there are so few fires, they mostly get put out.
The trouble is that pickup never announces when it stops working. The score just starts going the wrong way.
The moment pickup stops working
You'll see it before you can name it. The same few people are in every decision, because nobody else is sure they're allowed to make one. Everybody cares about quality and nobody owns it, so customers find the bugs, and the same kind of bug comes back next month. The backlog is whoever shouted last: the loudest customer, the founder's weekend idea, the thing sales promised on Friday.
None of these is a disaster alone. Together they mean the company has more ball than the players can chase.
Three positions, declared
Long before a team needs a full roster, it needs three positions filled, every time. A Strategic Lead owns the why and the what. A Delivery Lead owns the how and the when. A Technical Lead owns how well it's built. Everyone else is the team doing the building.
At five people, one person may hold two of those, and that's fine. What matters is that each one has a name next to it and everybody knows the name. ("Titles are for pay. Roles are for Tuesday." goes deeper on the three.)
The harder question is who you bring in first.
My first hire was a designer
The first time I built a product team, my very first hire was a designer. A designer could multiply what I envisioned the product should be. If I brought in outside build partners, the designer could talk to them. If I brought in outside sales partners, the designer could help with sales. One hire covered a lot of field.
I'd do it differently today. With AI in the picture, my first hire would be a designer-builder: someone competent in code and in AI tools, who can help build the thing and talk through solutions, and who can carry the vision of what it's supposed to be when partners or new hires come on. Someone who thinks strategically about what the customer needs and why, and leans on AI to capture it all as they go, documentation included.
Maybe I wouldn't even call that person a designer-builder. Maybe I'd call them the strategic lead. The technical piece can be solved in many more ways now than it could a few years ago. Someone who can hold the vision and explain it to everyone else is still hard to find.
Duplicate yourself, or fire yourself
My advice to founders is that it depends on your business, and there are two basic paths.
Duplicate yourself. Bring in someone who does something you understand well, to take it off your plate so you can scale. This one is usually driven by budget. If you can only afford someone part-time, pick an area you've done yourself, so you can still be quality control: the one who defines what done and good look like. Either hire someone who already knows what quality looks like, or hire in an area where you're the one defining done.
Fire yourself. Bring in someone for the thing you don't do well, or the thing that drains you, who can take it over and set a standard. This one is driven by your skills and your breadth. If you're a jack of many trades, look for where your energy produces the least value on work that still has to get done. Selling. Admin. Coding. Design, if you're really the technical lead.
Think of yourself as ten hats instead of one founder. Which of those hats still matters, but is the one you need to fire yourself from? That's the person you hire. You hire to fire yourself.
The other path runs the opposite way. You hand off a hat you wear well, to someone whose work you can still judge. Know which of the two you're hiring for before you write the job post, because they lead to very different people.
None of this is only for startups. A team lead inside a big company wearing too many hats has exactly the same choice, and the same ten hats. I wish I'd known it sooner.
Where the metaphor breaks
Pickup has one real advantage, and it's speed. Everyone sees everything, and anyone can jump in. Assign positions too early and you get a five-person company where people say "that's not my area," and the scrappiness that won the first customers goes quiet. Some people should keep playing every position for a while, usually the founder and often the first engineer. Let them roam, as long as someone is in goal.
A sport also has a fixed field and a fixed set of positions. Yours keep changing. The first hire that made sense for me back then isn't the one I'd make now, because the tools changed what one person can cover. Write your positions in pencil.
Try this
- Write down the ten hats you wear in a normal month. Include the small ones.
- Next to each, mark two things: does it still matter, and how much value does your energy produce there?
- Circle the hat that matters but where you add the least. That's a fire-yourself hire.
- Circle the hat you do well that eats the most hours. That's a duplicate-yourself hire, and a good one if the budget only stretches to part-time.
- For the work in front of you now, write who holds Strategic Lead, Delivery Lead and Technical Lead. If a seat is empty, that's your first position to fill, whichever hat it means taking off.
Where do you land?
