The most valuable person on an early team

Early teams do not die from a lack of ideas. They die from dropped handoffs. The person who keeps those handoffs from dropping is one of the most valuable people on the team, even though their work never shows up in the demo.

For five years at my company, that person was me. Not because of a title. Because someone has to be the connective tissue, and I decided it would be me, and I ran it on purpose.

What the work actually is

It is easy to picture the valuable person on a startup as the one with the big idea at the whiteboard. On a small team, the idea is almost never the bottleneck. The bottleneck is the space between the idea and the shipped thing. That space is full of handoffs, and every handoff is a chance to drop the ball.

So a lot of my real job was making sure the ball did not drop. In practice that looked like a few specific habits.

I kept everyone on the same page, out loud. When a thread had gone quiet or tangled, I would post the state of it. As I would open these, here is the current progress to date to catch everyone up, and then the list. Nobody had to reconstruct what was happening. It was written down.

I made alignment a visible action, not an assumption. When I posted the day’s priorities or a release plan, I would ask the team to “review and check mark if you agree, or comment with any questions or corrections.” A green check meant you had actually read it and you were in. That one small ritual turned silent, assumed agreement into something real I could see.

I made sure nothing fell through the cracks. If something mattered but could not be handled right now, I set a reminder on the message so we would come back to it. I asked teammates to do the same, to “set a reminder to come back to this if you cannot right now.” A small team moves fast and forgets faster. Reminders were how we remembered.

Removing blockers was half the job

If handoffs are where teams die, blockers are how they bleed out slowly. So I treated unblocking people as a first class task, not a favor.

I would go through our tickets, look for anything blocked, take action to clear it, and comment on the ticket saying what I did. I would ask directly, is there anything on our end we can unblock you on? At one point I framed a whole week’s goal around it. The big goal was getting our developer completely unblocked on everything design related so he could be in pure developer mode. His job was to build. My job was to clear the road in front of him.

When blockers kept slipping, I built a tiny format so we tracked them the same way every time. The latest update on the ticket, who is involved in the block, what specifically is blocking it, what it will take to unblock it, and the date we would have the next update. Five lines. But now a blocker could not hide. It had an owner and a clock.

I built loops so handoffs could not break

The cleanest version of this was a validation loop I set up for inbound signups. The rule was simple. A checkmark in Slack on a new signup meant two specific things had happened. A record was created in the CRM, and the follow up sequence had started. One small mark, two guarantees. Nobody had to wonder whether a lead got dropped, because the checkmark was the proof.

That is the pattern. Find the handoff that keeps breaking, and wrap it in a loop where the done state is visible and means something exact.

Why this work is undervalued, and why it should not be

None of this shows up in a product demo. You cannot screenshot a handoff that did not drop. So this work is easy to overlook, and easy to wave off as “just coordination,” as if coordination were beneath the real builders.

I see it the other way. On an early team, getting good ideas out the door is the rare skill, not having them. Ideas are cheap and everywhere. Execution, the unglamorous chain of small handoffs that turns an idea into something a customer can use, is where most startups actually fail. Owning that chain is not support work. It is one of the highest forms of ownership there is.

I also tried to do it generously. Keeping the machine running gave me a clear view of who was carrying the load, so I made a point of crediting them out loud. We could not hit a release date, I once said, if we did not have someone like our lead developer. Running the operation and lifting the people in it are the same job.

If you are early in your career and you are the person who naturally catches the dropped ball, do not undersell it. That instinct is rare and it is valuable. Name it, own it, and get great at it.

And if you are building a team, look past the loudest idea in the room. Ask a quieter question. Who here keeps the handoffs from dropping? In my experience, that person is holding the whole thing together, and they are usually the last to tell you so.