ExpertsFMElevenLabs' Mati Staniszewski: How Voice Becomes the Interface for Everything
Training Data · May 8, 2026
5 Selected Lessons:
framework · 2 reasoning_pattern · 1 heuristic · 1 prediction · 1
Sequential audio capability stack
Source
Training Data — ElevenLabs' Mati Staniszewski: How Voice Becomes the Interface for Everything (May 8, 2026) · at 5:27 ▸
When this applies
when deciding what order to build capabilities in a multi-layered technical product
The takeaway
Build core capabilities in the order that later composite products require, rather than jumping straight to the flashiest end product.
Why it works
Each capability layer depends on the one below it being solid (text-to-speech needed before speech-to-text and translation could be combined into language-barrier-breaking products; real-time models needed before agent orchestration was viable), so sequencing follows technical dependency, not customer demand alone.
Where it stops holding
This stops working when market timing forces you to ship a composite product before its underlying dependencies (e.g. real-time latency, reasoning speed) are actually ready.
Detail
procedure:
- Solve core text-to-speech with context-aware emotion/intonation first
- Add speech-to-text/transcription as a data and product component
- Combine the two into localization/dubbing/translation pipelines
- Wait for reasoning models to become fast/smart enough, then build real-time streaming and turn-taking orchestration for voice agents
- Extend into hardest modality (music) once emotionality is solved
rationale: Composite experiences (dubbing, agents, music) are only possible once their technical prerequisites exist and are reliable.
In their words
So it started with the problem of breaking down language barriers. The things you need to solve doubling is transcription, so understanding, then the translation, and then text-to-speech.
Small, flat, titleless teams with embedded engineers
Source
Training Data — ElevenLabs' Mati Staniszewski: How Voice Becomes the Interface for Everything (May 8, 2026) · at 14:32 ▸
When this applies
when scaling a company and trying to preserve startup speed and quality control
The takeaway
As AI tooling lets everyone build, embed technical review capacity directly inside non-technical functions rather than centralizing all technical oversight, and keep org units small/flat to preserve speed and clear impact measurement.
Why it works
Keeping teams under ~10 people with ~10 direct reports per manager flattens hierarchy and reduces coordination overhead; embedding an engineer in every function (not just engineering) lets non-technical teams safely leverage AI-assisted ('vibe') coding while someone technical reviews for security/quality.
One level up
Scale without inheriting the coordination bloat scale usually brings, by distributing the capability that quality-control requires rather than centralizing it.
Where it stops holding
This stops working when functions grow complex enough that a single embedded engineer can't keep up with review load, or when flat structures create ambiguity about decision rights at larger scale.
Detail
procedure:
- Cap each team (research, product, go-to-market, ops, talent) at roughly fewer than 10 people
- Keep each manager's direct reports around 10, keeping the org flat
- Embed an engineer inside every team, including non-technical ones (people, go-to-market, legal)
- Use that embedded engineer for automation, upskilling, and reviewing AI-assisted ('vibe coded') output for security/infrastructure risk
- Remove titles so people and impact can scale without tenure gating advancement
benchmarks: {"team_size":"under 10 people per team","direct_reports":"~10 per manager","company_scale":"400+ people, $400M+ revenue"}
rationale: Preserves startup-like speed and decision quality even as headcount and revenue scale dramatically.
In their words
So we are, just for reference, we are just over 400 people, over 400 million in revenue, but still keep the teams extremely small. So it's like rough, arbitrary, a little bit cap. It's less than 10 people for each of the research product, even the go-to-market ops talent teams are all smaller than that size.
Picking an underinvested frontier domain
Source
Training Data — ElevenLabs' Mati Staniszewski: How Voice Becomes the Interface for Everything (May 8, 2026) · at 2:11 ▸
When this applies
when choosing which overlooked technical domain to commit a company to, before the crowd arrives
The takeaway
Look for domains where excitement, talent density, and resource requirements are all low relative to the long-term value you believe they'll have — that gap is your window.
Why it works
A domain with few researchers and lower compute requirements lets a small team reach competitive quality faster and claim mindshare before capital-rich competitors notice it's valuable.
One level up
The best opportunities often sit in categories temporarily dismissed as 'niche' by the market, not in the categories everyone is already racing toward.
Where it stops holding
This stops working when the 'overlooked' domain is overlooked because it genuinely lacks value, not because others haven't noticed it yet.
Detail
approach: Evaluate a domain on (1) genuine personal excitement/conviction about its future value, (2) whether others structurally underrate it, (3) whether resource requirements (compute, data, talent) are tractable for a small team.
signals:
- low researcher density in the field
- smaller compute needs than sibling domains
- large but unlabeled data that a focused team can annotate
- market attention elsewhere (crypto/metaverse at the time)
rationale: Being early and focused in a neglected domain lets a small, resource-constrained team become the best in that niche before it's contested.
In their words
For those of you working in the domain at the time, that was a year of crypto and metaverse. Nobody was still working on the AI side.
Imperfection signals humanness in generative audio
Source
Training Data — ElevenLabs' Mati Staniszewski: How Voice Becomes the Interface for Everything (May 8, 2026) · at 5:27 ▸
When this applies
when judging whether a generated artifact (text, image, voice) feels authentic versus mechanical
The takeaway
Deliberately engineered imperfection can be a feature that increases perceived authenticity of a generated output.
Why it works
Humans associate imperfections (laughter, pauses, filler sounds) with authenticity, so reproducing them removes an uncanny-valley cue even though they're 'errors' in a literal sense.
Where it stops holding
This stops working when the context demands precision/clarity over naturalism (e.g. safety announcements, legal readouts) where imperfection reduces trust instead of increasing it.
Detail
rule: Add natural imperfections (laughter, pauses, filler words) to generated speech to make it feel more human.
rationale: This single addition was identified internally as the feature that most increased felt humanness, and drove the model to the top of Hacker News.
In their words
Then the second moment was where we first got it to laugh, and people were like, Okay, this is actually the thing that makes the whole experience more human.
Agent-to-agent communication may abandon human-style voice for efficiency
Source
Training Data — ElevenLabs' Mati Staniszewski: How Voice Becomes the Interface for Everything (May 8, 2026) · at 19:06 ▸
When this applies
when designing communication protocols between automated systems that currently mimic a human-facing interface
The takeaway
An interface designed for human constraints is often not the most efficient channel once both parties are machines — expect systems to defect to denser protocols once mutual machine-identity is confirmed.
Why it works
Human-style spoken language is optimized for human comprehension, not information density; once two machines confirm they're both machines, they have no reason to stay constrained to that inefficient channel and can switch to a denser transmission method.
Where it stops holding
This stops working if infrastructure/regulation mandates human-auditable channels even between agents, preventing the switch to denser protocols.
Detail
situation: Two voice agents were speaking in human language during a hackathon demo.
decision: The agents detected they were both agents and swapped to a different, denser language/transmission mode.
outcome: More efficient transmission of information than spoken word.
lesson: Whether voice remains the agent-to-agent transmission layer will depend on what infrastructure is built for, not necessity.
In their words
We did a hackathon over a year and a half ago, and that was exactly the case where an agent was speaking with another agent, they detected that they are both agents, and they swapped over to a different language, and that was like a more of a more efficient transmitter of information than just the classic spoken word.