At Draper U, when Cristina Cordova started talking about her path through Stripe, Notion, First Round and now Linear, I found myself thinking about a rather unglamorous question.
If you are not the founder, how do you actually become important inside a startup?
Not “important” in the LinkedIn sense. Not the polished kind that looks good in a tidy career retrospective. I mean important in the more operational sense. The company is small. Everything is half-formed. One day you are working on partnerships, the next you are helping unblock a product issue, and by Friday you are in the weeds on onboarding or distribution. In that sort of environment, what makes an early employee genuinely valuable?
Cordova’s résumé makes it easy to tell the wrong story. She is now COO at Linear. Before that she worked across platform, partnerships and go-to-market at Notion, and much earlier she was one of Stripe’s early business hires. She also spent time investing at First Round. Read quickly, it all looks quite linear.
What she described on stage was the opposite.
Not a grand career plan. Not a carefully sequenced ladder. More like getting pulled into a compelling environment, then repeatedly making herself useful inside it.
That order matters.
Early startups are not short of people who can do tasks. They are short of people who can spot the real gap.
I used to think the most valuable early employees were simply strong specialists.
That is only partly true.
Startups obviously need deep specialists. But what they often need even more, especially in the early years, is a different kind of person. Someone who can see where the organisation is actually leaking before the issue has been named properly, and then do enough to stop the bleeding.
In a First Round interview, Cordova uses a phrase from Elad Gil that fits this perfectly: gap filler. Fast-growing companies need people who can plug holes in the organisation. She adds the more important bit: you need to grow with the company, rather than have the company grow around you.
That line clears up a lot.
A startup does not usually grow a neat role around you first and then invite you into it. More often, the company gets messy, stretched and under-designed first. If you do not widen your own judgement, technical range and operating scope as the company changes, the company moves on and you stay where you were.
That gap becomes visible very quickly.
A good operator is not someone who says yes to everything
“Generalist” is often used too loosely.
It sounds flattering, but also vague. In practice, early-stage companies do not need someone who is mildly capable at everything. They need someone who can sort signal from noise under pressure.
That is the version of an operator I trust most now.
Not a person who touches every function. A person who can decide what actually matters at this stage, what is merely loud, what is worth jumping on personally, and what would turn into an endless sinkhole if they touched it.
That distinction matters.
Cordova’s way of talking about usefulness did not sound servile or endlessly accommodating. It sounded directional. She was not describing the person who volunteers for every stray task. She was describing someone who asks a sharper question: if no one handles this, will it materially slow the company down?
If the answer is yes, then the job is not merely to help. The job is to turn that fuzzy problem into something a team can understand, prioritise and ship against.
Those people usually become far more central than their initial titles would suggest.
Because what founders lack early on is not “help”. It is often someone who can turn ambiguity into movement.
I was corrected by something else as well: when the people are wrong, a lot of other leverage stops being leverage
That is also why this talk made me think of something beyond operators. It made me think about what my own second startup taught me about people.
I used to be pulled in by the usual signals as well. Strong résumés. Big-company backgrounds. Impressive titles. It is very easy to believe that if you can bring this sort of person into a tiny company, the team will instantly become more solid.
After actually trying to build with people under early-stage conditions, I stopped trusting those signals quite so much.
Someone can perform brilliantly inside an existing structure and still struggle badly when the structure does not exist yet.
Those are not the same thing.
I wrote about that experience in another piece, “I thought product would be the hardest part. Later I realised people were harder.” That post changed how I think about early operators and early teams. Not because it magically made me better at judging people, but because I got corrected by reality the expensive way.
So now I pay closer attention to a different set of signals.
- When the work is fuzzy, does this person create some structure, or wait for structure to appear?
- When the work is boring, dirty or slow to reward, do they stay in it or quietly retreat?
- When they say they have an owner mindset, do they mean the story of ownership or the work of ownership?
- Under pressure, do their standards hold or start slipping?
In an early company, these things tend to compound more than titles do.
That is why I increasingly read this whole question differently. It is not really about how a non-founder builds a glamorous career. It is about something more practical than that:
when the company does not yet have enough structure, who can add a usable piece of structure before things start distorting?
If you want to operate well, get more technical than is comfortable
One of Cordova’s recurring themes is that she deliberately pushed herself to become more technical.
Not because she wanted to become an engineer.
Because in a product company, if you refuse to touch the technical boundary, your judgement stays shallow. In that same First Round piece, she says she always disliked the wall between business and technical functions. She liked being the person in the room whom others could not easily categorise.
I find that instinct incredibly useful.
It is not another tired “everyone should learn to code” slogan. It is much more practical than that. Do not instantly outsource whatever feels unfamiliar into someone else’s domain.
Read the API docs. Understand enough of the system to know whether a point of friction is a copy issue, a workflow issue, or a capability issue. Know enough to tell whether a bottleneck is organisational theatre or something genuinely hard in the product.
If you refuse that layer entirely, you risk becoming the sort of operator who is very polished in meetings, very good at alignment theatre, and strangely disconnected from the actual levers of the company.
That can survive in a large organisation.
It is much harder to hide inside a small one.
Many so-called career moves are really just repeated experiments
One of the most useful parts of Cordova’s fireside was how she described her early job search.
There was no romance in it.
Cold emails. Silence. Being ignored. Reframing. Trying again.
What struck me was not perseverance as a moral virtue. It was the operating posture underneath it. She did not treat every non-response as a referendum on her worth. Quite often it was just the wrong framing, the wrong timing, the wrong entry point.
So she changed the variable.
Tried again.
Changed it again.
That feels very close to sales. It also feels very close to product work.
The more time I spend around early teams, the more I think good operators have a kind of experimental instinct. Not in a chaotic way. In a disciplined one. They know many early-stage problems do not have stable answers yet, so you have to ship a version, read the system’s response, and adjust.
- Was that email ignored because the audience was wrong, or because the hook was poor?
- Did that partner stall because they did not care, or because there was no internal owner?
- Is onboarding weak because the product is unclear, or because you are still chasing the wrong customer?
The strongest operators are not always the ones with the most static expertise.
Often they are the ones who are unusually responsive to feedback without being emotionally wrecked by it.
But do not romanticise startup chaos
This is where the story usually gets too shiny.
Not everyone should work at an early-stage startup.
And not every kind of chaos is worth your time.
People like to talk about startups as high-freedom, high-learning, high-growth environments. All true. What gets skipped is that the inverse usually arrives in the same package. High freedom often means low support. High learning often means long periods of not knowing whether you are doing the right thing. High growth usually means underbuilt systems and blurry ownership.
If what you need right now is strong scaffolding, clear feedback loops and stable boundaries, a more mature company may simply be the better place to learn. That is not a failure of ambition.
I increasingly think it is irresponsible to treat startups as the universally superior training ground.
Even if you do want to join one, it helps to separate productive chaos from merely neglected chaos.
The first can sharpen your judgement. The second can turn you into a permanent emergency response team.
Those are not the same sort of hardship.
The real leverage is not your title. It is how close you are to the company’s core problems.
What makes Cordova’s trajectory useful is not that it can be copied into a neat template.
It is that it points to a harder truth. Early employees create leverage not by collecting titles, but by moving closer and closer to the company’s actual bottlenecks.
Can you understand the product? The customer? The economic engine? Can you turn the fuzzy, cross-functional no-man’s-land into something the company can actually scale?
That is where the leverage is.
Cordova’s own advice elsewhere makes this sharper. The work that changes your trajectory is often not the most glamorous work. It is the work with cross-functional impact. The work that gives other people more leverage. The work that changes the speed of the system.
That has changed how I think about “finding your place”.
You do not usually think your way into it first.
More often, you enter the room, do the work, get corrected by reality a few times, and slowly discover where your judgement compounds.
So if someone asked me now what early startup employees should get good at, I would not answer with a function.
I would answer with this:
Become useful to the problems that actually matter.
That sounds simple.
It is not.
Because it requires more than execution. It requires seeing clearly enough to know what deserves execution in the first place.
Series | What Reality Corrected