Eagerness solves most problems. Judgement solves the ones we work on.
Sunday scaries
Every analyst remembers the first big mistake they made with a model. Mine nearly killed a deal.
When I was 21 and six months out of college, I owned subscription analytics at the consumer startup I joined as my first job. We were raising a round and wanted to show the strength of our retention numbers in the deck. The work landed on my desk. I had no experience with fundraising or with subscription retention modeling at the depth the deck required, just a mechanical engineering degree and six months of on-the-job pattern matching. None of this was unusual. At a small growing startup, lots of new terrain and a lot of green analysts learning by doing. The deal you make as a new grad is straightforward: throw eagerness at the problem, learn fast, ship.
So I did. I sprinted. First drafts were weak, I revised them, my bosses pushed back, I revised again. Deadlines closed in. Long nights were fueled by Loacker Quadratini chocolate wafers. Eventually we locked the numbers and shipped the deck. The lever worked. It had worked on every problem I’d been handed up to that point, because the stakes were usually low and the decisions reversible.
Then on Sunday morning, 7am, an email from the lead investor: “Can you explain why the numbers on slide 7 don’t match what we discussed before?” I had defined retention in a way that misrepresented our cohorts relative to the version they’d seen in a prior conversation. The metric was new and unfamiliar, which meant I had no intuition to sense-check it against. A more experienced eye would have caught it in five minutes. That panicked Sunday I focused on finding it, fixing it, and writing the explanation. The deal didn’t die, but the lever had been shaken. When the stakes rose, eagerness stopped being enough.
Where the model breaks
Four weeks ago I joined Kepler. The shape of the work looked familiar at first. Eight people, a lot of ground to cover, customers waiting, ship dates that matter. We work long hours. We push hard. That part is the same as every startup I’ve been part of and I assumed the rest of the lever would carry over too.
It didn’t take long to see why it wouldn’t.
In my first weeks I sat in on some engineering reviews discussing how to extend our spreadsheet building functionalities, a series of workflows available for our finance users. The obvious place to start was with skills, a set of files that directed the model to run a workflow. A quick afternoon MVP showed some initial progress and we discussed the next steps. The immediate quick win was to keep iterating on the prompts. That’s what most teams would do. But it’s also what most teams would lose weeks doing before realizing the path was a dead end.
This path would have a hidden flaw in it, unobvious at first. LLMs are built on probability, designed and trained for intent parsing. This step in the workflow required translating intent into process and then executing this process on a regular system, Excel, in a predictable way, so that each time the user ran it the process would repeat exactly: a deterministic outcome. Within the first 10 minutes of the team’s discussion one of our engineers immediately flagged this predicament. Forcing this structured behavior on top of LLMs, no matter how much we tuned the prompting, would always be a losing fight.
My previous six years had presented regular small unknowns: new feature ideas, changing behaviors to understand, bugs and initiatives to prioritize. The solution was clear. You picked a route, you ran at it, you learned what worked. It was an approach we encouraged and taught, take an intelligent person with energy and throw them at a problem until it cracks. The problems Kepler tackles aren’t like that. They have many possible routes and most lead to dead ends. Eagerness will get you down one of those routes and stuck there. It will not get you to the right one, not fast enough.
That’s the shift. Different problems. The work we tackle at Kepler doesn’t reward willingness to try. It rewards knowing where to start. The lever had changed.
Why judgement becomes critical
The problems Kepler builds for don’t yield to trial and error. They are correctness problems, not speed problems, and they sit on top of AI that doesn’t behave like traditional engineering. AI is non-deterministic. The same prompt can produce different outputs. A small change in one place can have unpredictable downstream effects, fixing one case while breaking three others. The traditional engineering loop of “try something, see if it breaks, fix it” doesn’t survive that. Building deterministic outputs on top of probabilistic models takes more than effort. It requires thought and experience about how these systems actually work.
Take traceability, the thing every Kepler answer is built on. Every number a customer sees has to click through to its source. Every formula has to be explicit. Every conclusion has to reveal its reasoning. This isn’t a feature we layered on top. It’s the spine of the architecture. Get the spine wrong and nothing downstream can be made right. Get the spine right and the rest of the product compounds.
Or take the semantic layer, the thing that maps natural language to precise data definitions. When a user asks “what was their revenue last quarter,” there are usually four or five things they could mean: as-reported revenue, organic revenue, currency-adjusted, the trailing twelve-month derivative. The semantic layer has to know which one to compute and why. If we make the wrong definitional call now, it doesn’t fail loudly. It fails quietly, in numbers that look right but mean the wrong thing, in answers a customer trusts and shouldn’t.
The same shape repeats across the work. Agent reliability where the same question has to produce the same answer twice. Data lineage where every cell traces to a tagged origin. These are all categories where you can ship something that works in the demo and breaks in the long tail. The cost of getting it wrong isn’t a few wasted hours. It’s months of unwinding architecture and customer trust you don’t get back.
You don’t solve this class of problem by trying harder. You solve it by recognizing, at the moment of decision, which route avoids the traps. That recognition isn’t just about being smart. It’s pattern recognition you can only get from having seen this shape of problem fail before. Junior engineers can be brilliant and hungry. They have not yet seen the failure modes. Senior engineers have, and they avoid them.
Judgement is the lever because the problem class doesn’t reward anything else.
How that’s changed our operating model
This shifts how we hire, how we work, and who we build the team around.
We hire experienced engineers and operators. People who have already shipped systems at scale, made the mistakes, watched the abstractions fail, and learned which routes are the dead ends. Between us, two PhDs, more than five decades of Palantir engineering, time at Meta and Lincoln Lab, several scaled startups and more. Pattern recognition transfers across domains, but you have to have built up patterns first.
We hire people who’ve seen the AI shift from both sides. Engineers who built systems before LLMs were tools you could lean on, and then learned how to embrace them to move faster. Our work demands both. Without the pre-AI engineering experience, you cargo-cult LLM behavior into places it doesn’t belong. Without the AI fluency, you over-build on top of capabilities the models already have. We need both perspectives in the room when decisions get made.
Seniority doesn’t win arguments. Pattern recognition does, and it travels in every direction. A less experienced engineer who’s seen something the room hasn’t can override our CTO, and does. The bar is “have you seen this shape of problem before?” not “what’s on your resume?” Our operating principles say this out loud: authority comes from initiative, not titles.
You do not want this if you are early in your career. The eagerness lever works for most problems, and you should go find one of those problems. Throw yourself at it, ship, learn, repeat. That’s the right move for the right phase. Come back when the lever changes for you.
If you’ve felt the lever change already, you’d recognize Kepler within a week. The problems are different. The room is different. The work rewards the thing you’ve spent your career building.
Eagerness solves most problems. Judgement solves the ones we work on.
If the lever has changed for you, we’re hiring.