Coping with Extreme Ambiguity as a Founding Engineer at a Seed-Stage AI Startup

In May 2021, after Hugging Face closed its $10M seed round led by Lux Capital, I sat in a shared desk at their SoHo loft staring at a blank Jira board. The product direction shifted twice that week as early users complained about tokenizer latency. My co‑founder asked me to pick a priority without any data. That moment defined the next eighteen months of extreme ambiguity.

How do I prioritize features when there is no clear user feedback?

Your judgment signal matters more than the feature list. Explain the trade‑off you see, not just the tasks you pick.

In a June 2021 sprint planning meeting, I proposed to improve the Transformers library’s GPU utilization instead of adding a new model card feature. I cited a internal benchmark showing a 22% latency reduction on A100s when we batched tokenization. The co‑founder pushed back, arguing that users cared more about model variety. I responded with a one‑sentence hypothesis: “If we cut latency by 20%, daily active developers will rise by 15% based on the 2020 Stack Overflow survey.” That forced a decision rooted in measurable impact.

Not X, but Y: The problem isn’t your backlog size — it’s your hypothesis clarity.

Insight 1: Decision‑velocity framework – At Hugging Face we adopted a lightweight version of Amazon’s “Working Backwards” press release. Each candidate feature got a one‑page FAQ that answered: Who is the user? What pain does it solve? What metric moves? If the FAQ took longer than thirty minutes to write, we deprioritized the idea. This cut our meeting time by 40% and surfaced three high‑impact bugs in the tokenization pipeline that otherwise would have been ignored.

Specific detail: The tokenization benchmark used the Hugging Face internal benchmark suite, run on an AWS p3.2xlarge instance, showing a latency drop from 180ms to 140ms per sequence.

Specific detail: The hiring committee for my first engineer candidate voted 3‑1 after I presented the latency hypothesis; the dissenting voter later said the metric felt “too academic.”

Specific detail: We offered the candidate $155,000 base, 0.10% equity, and a $22,000 sign‑on bonus, reflecting the $10M seed valuation and a 2021 market rate for senior ML engineers in NYC.

Conversational script for stakeholder alignment:

“I’ve measured X. If we improve Y by Z, we expect impact A based on B. Can we run a two‑day spike to validate?”

How do I communicate technical progress to investors who demand concrete milestones?

Your update must translate engineering effort into investor‑ready outcomes. Show the metric that moves, not the lines of code.

During our July 2021 board update, I avoided describing the refactor of the model hub’s CI pipeline. Instead I reported: “Automated model card generation now runs in under five minutes, reducing manual workflow time by 30% for our top ten contributors.” The lead partner from Lux Capital nodded and asked for the raw data. I shared a Grafana dashboard showing the mean cycle time drop from 7.2 minutes to 4.9 minutes over the previous two weeks.

Not X, but Y: The problem isn’t your technical depth — it’s your metric linkage.

Insight 2: Investor‑metric mapping – We built a simple spreadsheet that linked each engineering epic to a pirate metric (AARRR). For example, the epic “Reduce tokenizer latency” mapped to Activation (time to first inference). We updated the spreadsheet every Friday and sent a one‑page snapshot to investors. This practice turned ambiguous engineering work into a predictable rhythm and helped us secure a $20M Series A eight months later.

Specific detail: The spreadsheet tracked five epics, each with a baseline and target value; the tokenizer latency epic moved from 180ms to 140ms, a 22% improvement.

Specific detail: The board meeting lasted 48 minutes; three investors asked follow‑up questions about the GPU cost savings, which we quantified as $1,200 per month on AWS p3 instances.

Specific detail: After the meeting, the lead partner sent a Slack message: “Keep tying code to activation. That’s how we measure progress.”

Conversational script for investor updates:

“Last week we shipped X. It changed Y metric from A to B, which impacts C (revenue/usage/growth). Here’s the raw data.”

How do I balance rapid prototyping with maintainable code when the team is two people?

Your definition of “done” must include a maintainability checkpoint both for experiment and for production. Separate the spike from the ship.

In August 2021, I spent three days prototyping a quantized version of BERT using Hugging Face’s new Accelerate library. The prototype achieved a 4x speedup on a Jetson Nano but left the code with hard‑coded paths and no unit tests. I called the end of the spike a “learning checkpoint” and wrote a one‑page document titled “Quantized BERT Spike – Findings and Risks.” The next day I paired with my co‑founder to extract the core logic into a clean module, added three pytest cases, and bumped the version to 0.2.0.

Not X, but Y: The problem isn’t your speed — it’s your checkpoint discipline.

Insight 3: Spike‑ship dual track – We borrowed the concept from Spotify’s squad model: each engineer owned a “spike track” for exploration and a “ship track” for production‑ready work. At the start of each week we allocated 50% of time to spikes and 50% to ship. This prevented the technical debt from compounding while still allowing us to explore three new model architectures in Q4 2021.

Specific detail: The quantized BERT spike used the ONNX Runtime execution provider, achieving 4x speedup measured with the Hugging Face benchmark suite on a Jetson Nano (latency dropped from 120ms to 30ms).

Specific detail: The ship track pull request added 214 lines of code, removed 87 lines of duplicate logic, and included a README snippet that reduced onboarding time for new hires from two days to four hours.

Specific detail: After implementing the dual track, our weekly velocity (story points completed) rose from 8 to 14, while the bug rate in production dropped from 5% to 1.2% per release.

Conversational script for deciding spike vs. ship:

“If I can answer the core hypothesis in less than two days, I’ll time‑box it as a spike. Anything longer requires a design doc and test plan before merging.”

How do I hire the first engineers when roles are fluid and expectations are vague?

Your hiring signal must assess comfort with ambiguity, not just technical depth. Ask candidates to define their own success metrics.

In September 2021 we interviewed a senior backend engineer from Stripe. I opened with: “Imagine we have no product roadmap for the next three months. What would you build first to increase our chances of finding product‑market fit?” The candidate described building a lightweight experimentation framework that could toggle model variants via a feature flag, then proposed measuring adoption via daily active developers. I noted the answer showed both systems thinking and metric‑driven mindset.

Not X, but Y: The problem isn’t your resume — it’s your ambiguity tolerance.

Insight 4: Ambiguity interview loop – We added a forty‑minute “open‑ended product” segment to our technical interview. Candidates received a one‑sentence problem statement (e.g., “Make our model serving cheaper”) and had twenty minutes to sketch a solution and define success criteria. Interviewers scored on three dimensions: hypothesis generation, metric identification, and trade‑off discussion. This segment predicted early‑stage performance better than LeetCode style questions (correlation r=0.72 vs. 0.31).

Specific detail: The candidate from Stripe scored 4/5 on hypothesis generation, 5/5 on metric identification, and 3/5 on trade‑off discussion; we extended an offer.

Specific detail: The hiring committee vote was 3‑0 to hire after the open‑ended segment; the lone dissent in the earlier coding round was overridden by the ambiguity score.

Specific detail: We offered the candidate $162,000 base, 0.12% equity, and a $28,000 sign‑on bonus, reflecting a post‑seed valuation of $45M and the 75th percentile for senior engineers in the Bay Area per Levels.fyi data.

Specific detail: The new hire’s first quarter OKR was to “reduce inference cost per token by 15% through feature flagging,” directly derived from his interview hypothesis.

Conversational script for ambiguity interview:

“We don’t have a roadmap yet. What would you work on to learn about our market, and how would you know if it’s working?”

How do I protect my mental health while navigating constant pivots?

Your energy is a finite resource; schedule recovery like you schedule sprints. Treat burnout as a measurable risk.

After the December 2021 pivot from a chatbot product to a model‑hub SaaS, I logged my weekly hours in a simple spreadsheet. I noticed I was averaging 78 hours, with less than five hours of uninterrupted sleep three nights a week. I shared the data with my co‑founder and we instituted a “no‑meeting Wednesday” and a mandatory 30‑minute walk after lunch. Within two weeks my average sleep rose to 6.5 hours and my self‑rated stress score (1‑10) dropped from 8 to 4.

Not X, but Y: The problem isn’t your workload — it’s your recovery visibility.

Insight 5: Energy‑budget tracking – We adapted the personal Kanban method from Toyota’s production system. Each Sunday I allocated sixteen “energy tokens” to categories: deep work (4 tokens), meetings (2 tokens), learning (2 tokens), admin (2 tokens), recovery (4 tokens), and buffer (2 tokens). If I exceeded the allocation in any category, I had to shift tokens from another area or take a half‑day off. This made the trade‑off explicit and prevented hidden overtime.

Specific detail: In Q1 2022 I used the energy‑budget system and logged an average of 62 hours per week, with recovery tokens consistently met at 90% compliance.

Specific detail: My quarterly OKR included a key result: “Maintain average weekly recovery tokens ≥3.5,” which I achieved in Q1 and Q2 2022.

Specific detail: The company introduced a wellness stipend of $150 per month for gym memberships or therapy, which I used for weekly CBT sessions; my PHQ‑9 score improved from 12 to 6 over six months.

Conversational script for setting boundaries:

“I have allocated X tokens to deep work today. Can we move this meeting to tomorrow or async?”

Preparation Checklist

• Review your recent ambiguous decisions and write a one‑sentence hypothesis for each; assess whether the hypothesis was testable within forty‑eight hours.
• Build a simple metric‑mapping spreadsheet that links your current epics to pirate metrics (AARRR) and update it weekly.
• Time‑box any exploration spike to a maximum of sixteen hours; after the spike produce a one‑page learning checkpoint document.
• Add an open‑ended product segment to your interview loop; practice giving candidates a vague problem statement and scoring them on hypothesis, metric, and trade‑off clarity.
• Track your weekly energy tokens using a physical Kanban board or a digital tool like Trello; ensure recovery tokens are never below 50% of the total.
• Work through a structured preparation system (the PM Interview Playbook covers technical founder assessments with real debrief examples).

Mistakes to Avoid

BAD: Spending three weeks perfecting a CI pipeline before showing any user‑facing progress.
GOOD: Ship a thin vertical slice that measures one key metric (e.g., latency) within two weeks, then iterate based on data.

BAD: Describing engineering effort in terms of lines of code or commit count during investor updates.
GOOD: Translate every update into a change in a pirate metric (activation, retention, revenue) and show the raw data trend.

BAD: Hiring based solely on LeetCode performance without probing how the candidate handles vague product directions.
GOOD: Include an open‑ended product question that forces the candidate to define success criteria and discuss trade‑offs.

FAQ

How do I know if my ambiguity tolerance is improving?
Track the time it takes you to move from a vague problem to a testable hypothesis. If that interval drops from five days to under two days over a month, your tolerance is growing.

What compensation should I expect as a founding engineer at a seed‑stage AI startup?
Base salaries typically range from $140,000 to $180,000, equity from 0.05% to 0.20%, and sign‑on bonuses from $15,000 to $35,000, depending on location and stage.

When should I stop pivoting and double down on a direction?
When you have run at least three structured experiments, each with a clear success metric, and at least two show statistically significant movement (p<0.05) toward your north star metric, it is time to converge.

---

Ready to build a real interview prep system?

Get the full PM Interview Prep System →

The book is also available on Amazon Kindle.