Operator Mindset
your guide to early stage chaos (and fun!)
I’ve been thinking a lot about what separates people who thrive at early-stage startups from people who struggle.
And I don’t think it’s intelligence, or work ethic, or even experience.
It’s something more specific.
The ability to walk into a situation where nothing is structured yet, and start building the structure yourself, without waiting to be asked. (This post is written under the assumption that thinking with first principles is the baseline)
Most people are trained to operate inside systems that already exist. You get a role, you get a scope, you get processes to follow, and your job is to do them well. That's a perfectly valid way to work at companies that have already figured out what needs doing. But early-stage startups haven't figured that out yet. The processes don't exist. The role you were hired for will probably morph into something completely different within three months. And the founder is moving too fast to stop and build the operational backbone the company needs to function.
So someone has to do it.
The people who step into that gap, who see what’s missing and start building it before it’s assigned, are the ones who actually make these companies work.
This isn't about being a generalist who does a little of everything. I think the most useful framing is T-shaped: you go deep in one area where you build genuine expertise, and you develop enough range across other functions that you can build the first version of almost anything the company needs. The depth gives you credibility and judgment. The range is what lets you be useful in situations nobody planned for.
My depth is GTM and growth.
But across companies, I’ve had to build recruiting systems, product processes, community engines, expansion strategies, and internal tooling.
Not because I was the best person for all of it. But because nobody else was going to build it, and I love figuring things out!
And the barrier to doing this has basically collapsed. The technical threshold that used to stop non-engineers from building tools and automations basically doesn't exist anymore (love you, Claude Code :) & Cursor, you too, babe). What's left is just the willingness to do it.
The core of the operator mindset is thinking in systems rather than tasks.
Most people think in tasks. Answer the question → Close the loop → Move on.
Systems thinking is different.
Why does this keep happening?
What needs to exist so it stops repeating?
At an agentic AI infrastructure startup where I was employee number seven, developers were constantly sharing feedback across Discord, GitHub issues, and forums.
The signal was there. It just wasn’t going anywhere useful. The task would’ve been to stay active in the community.
The task-level response would have been to answer questions and keep the community active. What I actually built was a feedback infrastructure: categorised issues, recurring pattern analysis, feature signals routed to the people who could do something about them, all on a weekly cadence.
The community grew from ~9k to 33k GitHub stars.
The framework scaled to over a million monthly downloads.
But the real shift was this: Product decisions started being shaped by real user behaviour instead of internal assumptions.
At a B2B SaaS investment platform serving PE and VC firms, the problem looked different, but it was the same underlying gap.
The core product wasn’t structured for how users actually worked. I led the revamp of the core portfolio module, the product that investment professionals used daily to manage their deal flow and portfolio operations. That meant expanding into new geographies like the UK and Nordics, adapting the platform for regional use cases, and shipping strategic product components across three product lines: deals, sourcing, and portfolio management. (Pre ChatGPT era.)
Different industries, different problems, same approach every time. Find the gap where a system should exist but doesn’t. Build the first version. Lead it until it works. Then make it repeatable enough that it scales beyond you.
How does this work?
Find the gap → Build the first version → Stay with it until it works →Then make it repeatable.
Simple. Just make sure you're looking at where the company is headed, at the pace it's growing, at the commitments it's making, and you realise that a system needs to exist before the need becomes urgent. If you wait until it's a crisis, you're already behind.
The thing that actually separates this mindset from just being organised or resourceful is the willingness to lead what you build.
Basically, high agency!
A lot of people can identify a gap, and some of them will even build a first version of something to address it. But most people stop there. They hand it off, or they move on before anyone knows whether the thing actually worked. The operator mindset doesn’t let you do that. You build the feedback system and then you own it until the product team is actively changing roadmap priorities based on what it surfaces. You build the recruiting operation and then you run it until it’s generating consistent results and the team can sustain it without you in every decision. You don’t get to say “I built it” unless you can also say “and here’s what happened because of it.”
That’s a high bar, and it’s uncomfortable because it means you’re accountable for outcomes in areas where you might not be an expert. The community feedback infrastructure I built wasn’t my area of deep expertise; that was GTM and growth. But the company needed it, nobody else was building it, and I was willing to stay with it long enough to make it work and iterate when the early versions were too detailed or too shallow for anyone to actually use. That willingness to build outside your comfort zone and stay accountable for the result is what makes the T-shape actually valuable. The depth gives you confidence that you know how to build well, and the range permits you to try things you haven’t done before.
I want to push back a little on the idea that you’re either born with this instinct or you’re not, because I think the operator mindset is something you develop by doing it repeatedly across different contexts.
Every company I’ve worked at has been a different version of the same fundamental puzzle: here is a situation with no structure, figure out what needs to exist and build it. And each time, the pattern recognition gets faster. You start seeing the shape of the problem before anyone describes it to you. You know that the first version of any system you build will be wrong, and that’s fine because the skill isn’t getting it right immediately, it’s iterating fast enough that you converge on something useful before the company runs out of patience.
There’s this assumption that a career that moves across functions and industries is scattered or unfocused, and I understand why it looks that way from the outside. But from the inside, every context taught me a different version of the same skill, and each one made me faster and more confident at the next. Non-linear careers have the most advantages. The ability to walk into any mess and know where to start is the most important.
If you’re reading this and it resonates with how you already work, here’s what I’d say: stop waiting for your scope to be defined and start looking for the thing that everyone on your team knows is broken but nobody is building the fix for. The feedback loop that doesn’t exist. The process that costs the team hours every week because nobody has systematised it. The decision that keeps getting re-made because nobody documented it the first time.
Build the first version. It doesn’t need to be perfect; it just needs to be better than what’s there, which is probably nothing. Then lead it long enough to see whether it works, and if it doesn’t, figure out why and rebuild.
And if you’re a founder, know what this looks like when you’re hiring. The person you want should simply be high agency, invested in what you are building and a first principal thinker. These folks can figure stuff out!
Thank you for reading. More of my writings live here, and learn About Me.
If you found this interesting, I'd love to hear your thoughts. Share it on Twitter, LinkedIn or reach out at monalidambre710[at]gmail[dot]com.
Thank you so much
Keep writing more like this….this was excellent!