Table of Contents
We've been thinking a lot about time lately. Not in the existential, the “how is it already Q2” way or “how old am I, again?” way (okay, sometimes that way), but in the way that time works when you're building something that doesn't exist yet, in an industry that moves at the speed of sound, with a team that could fit in a Denny’s booth.
The Deepgram for Restaurants team is smaller than you'd expect for the brands we work with and the pace we ship at. Even so, we don't treat moonshots as optional, and we think that says something fundamental about our engineering culture.
The Moonshot Framework
Here's a framework that (hopefully) encompasses all of the work that you do in your job.
Circle one is what the company needs. Ship the point-of-sale integration. Fix the bug that's transcribing "tender" as "flounder." You know… the stuff that funds our team's fruit snack stock.
Circle two is what's interesting to you. For Lawrence, that might be using AI to dynamically adjust STT and TTS behavior based on environment. For Pranav, it’s finding a way to automate every possible manual workflow. If you’re not at the right company, you might not get a chance to focus on the ‘cool’ stuff.
The overlapping slice is where those two intersect. The stuff that moves the business forward and lights up your brain. That's where the best work happens.
The problem? That's also where the moonshots live – the ideas that often do not survive prioritization because there's always something more urgent from Circle 1. Unless you build a culture and system that encourages you to chase them anyway.
Engineers who compound their own leverage
Here’s what the Moonshot Framework looks like in practice: Pranav Bachu, one of our engineers, got tired of a bottleneck that was slowing everyone down.
If you're a developer, he wrote a whole post about it a few months ago (before OfOne was acquired by Deepgram) and you should read it. To summarize:
Our stack runs on microservices (before you ask: yes we've heard of monorepos). Most features touch multiple repos. Everything runs in Docker locally. If you're mid-feature and something urgent comes in, you're stashing, rebuilding, context-switching. Two tickets that touch the same repo are competing for the same checkout. On a small team, a blocked engineer blocks the team.
So he built a system that gives each feature its own fully isolated environment. Git worktrees for code isolation, deterministic port allocation for Docker isolation. Spin up a new ticket, only create worktrees for the repos it actually touches, everything else points to main. He wrote about the philosophy behind it a few months ago.
What started as isolated environments turned into something more ambitious. The system now handles the full lifecycle of a feature. Before anyone writes code, it explores the codebase, asks hard questions about the design and approach (we love the AskUserQuestion tool), and works with the engineer to produce a spec that both the human and the model are aligned on. It runs end-to-end conversation simulations against your local stack. It pulls production telemetry and reads source code to build a theory before you ever touch a log. If a teammate is stuck, you can pull their in-progress work locally and pick up context from their commits and PR discussions. When it's time to ship, it runs risk analysis across repos and generates a release summary ready to post in Slack. All orchestrated through conversation in a single terminal.
We even have tickets that ship themselves. Add a label in Linear and an agent spins up on its own infrastructure, reads the ticket, plans an approach, implements across all six repos, opens PRs, and responds to review feedback until it merges. No human touches code unless they want to.
None of this would have survived a prioritization meeting. But it made the entire team faster.
Fewer people than you’d think, more moonshots than you’d expect
Most teams treat moonshots as a luxury, something you earn after the "real" work is done. We treat them as the real work. And that changes how it feels to show up every day. When you're building from scratch and you get to focus on what you think is important – not just what survived a prioritization meeting – working feels really good. The thing you're building is yours. That's more fulfilling than any sprint velocity metric.
So we don't wait. We build kitchens with multiple stoves. We let our engineers cook (and make sure Pranav has a Coke Zero in hand).
We're hiring, by the way. If you want to work on voice AI for restaurants with a team that actually lets you build the things you care about — come talk to us.
