New York City

The best programs don't need a deck to prove they shipped.

I'm Stevon Judd — a Technical Program Manager who's spent 10 years learning that the hardest part of building software isn't the code. It's getting the right people aligned on the right problem at the right time.

I've done this inside enterprises like MongoDB, where one wrong move breaks customer trust. And I've done it as a founder, where there's no playbook and no safety net.

What I actually do Get in touch
Scroll
The Operating System

What I actually do

01

I translate between layers.

I speak engineer, exec, and customer — in their language, not mine. Most programs fail because someone couldn't bridge the gap between "the system can't handle that" and "the customer needs it by Tuesday."

Evidence: At MongoDB, I translated customer SLAs into infrastructure investment priorities that engineering could execute against. At SquadTrip, I'm the person who talks to the payment processor, the angry customer, and the engineer — in the same hour.
02

I build systems, not just manage programs.

SquadTrip isn't a side project. It's proof I can build the machine — product, engineering, payments, compliance, ops — not just run someone else's. That's a different gear than program management alone.

Evidence: Built a payments-enabled SaaS from zero to $10M in annual booking volume. Designed the architecture, shipped the code reviews, handled the support tickets, negotiated the payment processor contract. Full stack of ownership.
03

I calibrate risk — I don't avoid it.

The goal isn't to minimize risk. It's to take the right risk given the stakes. Ship with a known edge case if it's rare and recoverable. Hold the line if failure is expensive and trust is on the table.

Evidence: Try the simulation below — it's built on real decisions. I've shipped features with manual workarounds to hit a window. I've also delayed launches that "felt ready" because the failure mode was catastrophic. Knowing which is which is the job.
04

I've operated across the full altitude range.

COBOL to modern payment systems. Enterprise insurance to Techstars startup. Individual contributor to founder. That range means I can pattern-match across contexts most people have never seen.

Evidence: Started debugging mainframe batch jobs at New York Life. Now I architect real-time payment flows and lead programs across globally distributed teams. The through-line: complex systems that can't go down, serving people who depend on them.
The Toolkit

I build tools, not just process

When I see repeated friction, I don't write a doc — I build a system. These are force multipliers I've created to eliminate overhead and ship faster.

PRD Generator

Structured prompts that turn rough ideas into complete product requirements in minutes. Consistent format, right questions asked, ready for engineering review.

Planning → Execution

Auto Bug Creator

Captures context, reproduces steps, and formats bug reports automatically. Engineers get what they need to fix it. No back-and-forth.

Friction → Flow

Response Toolkit

Templated responses for common customer scenarios, stakeholder updates, and cross-team communications. Consistency without the cognitive load.

Repetition → Automation

Program Scaffolding

Frameworks for spinning up new programs: stakeholder maps, risk registers, dependency tracking, status templates. Start structured, not from scratch.

Chaos → Structure

The pattern: I treat my own workflow like a product. If I'm doing something twice, I'm building a system the third time. This is how small teams operate at scale — and how I bring founder discipline to any role.

The Work

Three stories about building things that matter

MongoDB Technical Program Manager

How do you sunset a product that thousands of customers depend on — without a single disruption?

Ops Manager was legacy. Everyone knew it needed to go. But "legacy" doesn't mean "unimportant" — it means customers built their operations around it. Their alerts. Their workflows. Their trust.

The easy path was a hard cutover with a migration guide. The right path was understanding that for infrastructure products, reliability is the product. You can't ask customers to trust your new platform if you break their trust getting there.

I spent months in the ambiguity — mapping dependencies across four orgs, finding the customers who'd be hardest hit, building a transition that felt invisible. Not because invisible is impressive, but because invisible means we did our job.

We shipped a company-wide platform transition. Zero outages. Zero escalations. Most customers didn't even notice — which was exactly the point.

SquadTrip Founder

What happens when you can't hide behind process — because you have to build the process while building the product?

At big companies, program management often means inheriting systems that work. Your job is optimization. Coordination. Making the trains run on time.

When I started SquadTrip, there were no trains. No tracks. Just a problem I understood deeply — group travel is operationally brutal — and a belief that software could fix it.

I learned things you can't learn inside an enterprise: how to make decisions when you don't have data, how to ship when you're not ready, how to talk to customers who are angry because your product is their livelihood.

I also learned that most of what makes programs successful at scale — clarity, sequencing, knowing when to cut scope — matters even more when you have no margin for error.

Techstars NYC '22. Scaled to ~$10M in annual booking volume across 5,000+ travelers and 1,000+ trips.

MongoDB Platform Infrastructure

The metric that actually mattered wasn't on anyone's dashboard.

Backup systems are strange. When they work, nobody thinks about them. When they fail, it's the only thing anyone thinks about.

We had good backup metrics. Completion rates. Storage efficiency. The numbers looked healthy. But when I started talking to customers and support teams, I kept hearing the same thing: "Restores take forever."

Restore time wasn't a KPI anyone owned. It fell between teams — backup owned the data, infrastructure owned the pipes, nobody owned the experience of a customer watching a progress bar at 2am during an incident.

The fix wasn't technical. The fix was getting three teams to care about a metric that wasn't in their OKRs, then finding the infrastructure investments that would move it.

40% reduction in restore time. More importantly: a team that now thinks about customer experience, not just system performance.

Interactive

Think you can ship it?

A real scenario from SquadTrip. Make the calls. See what happens.

SquadTrip — May 2023

The Summer Rush

Summer travel season starts in 3 weeks. You're about to launch Group Payment Splitting — the most requested feature from your biggest customers. Trip organizers can finally split costs automatically instead of chasing Venmo payments.

Engineering says it's ready. Marketing has already teased it. Your largest customer — a travel agency doing $400K/year on your platform — is planning their entire summer around this feature.

Then three things happen at once.

Monday Morning

The QA Flag

Your lead engineer pulls you aside. "The refund flow has edge cases we haven't fully tested. If someone partially pays, then requests a refund, then the trip gets canceled... I'm not 100% sure what happens to the money."

She estimates 4-5 days to properly test and fix. But that pushes you past the marketing launch date, and your big customer's first summer trip is in 18 days.

What's your call?

You chose: Delay the launch

Reasonable, but...

Marketing is frustrated — they've already sent the teaser email. Your big customer calls you directly, concerned. "We already told our travelers this was coming."

You spend the week managing expectations instead of shipping. The feature launches clean, but you've burned some trust and lost momentum.

The lesson: Delays have costs beyond the timeline. Sometimes the right call is scoping down, not pushing back.

You chose: Ship without refunds

Smart scope cut.

You ship on time. The 90% case works perfectly. You're transparent with customers: "Split payment refunds require a support ticket for now — full automation coming in 2 weeks."

Three refund requests come in that first week. Support handles them manually. No drama. The feature lands.

The lesson: Perfect is the enemy of shipped. Scoping down beats delaying when the core value still works.

You chose: Ship and hope

This will cost you.

Week two. A trip organizer cancels a trip mid-payment. The system creates a negative balance. Their bank flags it as fraud. They're locked out of their account for 3 days during their busiest booking period.

You spend the next week in damage control. The customer is furious. You fix the bug under pressure instead of properly.

The lesson: "It probably won't happen" is not a risk mitigation strategy. Edge cases in payments always find you.

Wednesday

The Compliance Surprise

Your payment processor sends an email: new money transmission regulations require additional disclosures for "payment facilitation services" — which is exactly what split payments are.

Legal review will take 5-7 business days. Without it, you could be operating in a gray area. Your processor has flagged accounts for less.

What's your call?

You chose: Full pause

Safe, but slow.

Legal takes the full 7 days. Turns out the regulation applies to a different payment model — you were fine all along. You lost a week to uncertainty that a single phone call could have resolved.

The lesson: "Wait for legal" isn't always the responsible choice. Understanding the actual risk often takes less time than waiting for formal review.

You chose: Limited rollout

Creative, but complicated.

You now have two launch tracks: existing customers get the feature, new customers don't. Your support team is confused. Your docs say one thing, your app says another.

Legal clears you on day 4. But you've created operational complexity that takes another week to unwind.

The lesson: Partial solutions often create more work than they save. Sometimes it's better to wait or push forward — but not both.

You chose: Pick up the phone

This is the move.

Your contact at the processor explains it in 10 minutes: the regulation targets platforms holding funds in escrow. You don't do that — money goes directly to trip organizers. You're fine. They confirm via email.

You share the email with legal, they confirm in 24 hours, and you're unblocked.

The lesson: Process isn't always the answer. Relationships and direct communication often resolve ambiguity faster than formal review.

Thursday

The Customer Call

Your biggest customer calls. They've already told their 200+ summer travelers that split payments are coming. Their first trip departs in 16 days.

"We've been partners for two years. I need to know — can we count on this, or should I tell my travelers to use Venmo again?"

You're 80% confident you'll ship on time. But it's not certain.

What do you tell them?

You chose: Promise delivery

Confidence without certainty is a liability.

You ship 3 days late. The customer already told their travelers. Now they look bad, and they blame you.

The relationship survives, but there's a crack in the trust. Next time they'll wait to see it live before they believe you.

The lesson: Promising certainty you don't have erodes trust faster than admitting uncertainty ever would.

You chose: Honest uncertainty

Trust is built in moments like this.

You tell them: "I can't promise the exact date. What I can promise is that I'll tell you the moment I know more, and if there's any risk to your June 15th trip, you'll hear from me by Monday."

They appreciate the honesty. They have a backup plan ready. You ship on time anyway — and now they trust you more because you didn't oversell.

The lesson: Customers don't need certainty. They need honesty and a partner who manages risk with them, not for them.

You chose: Buy time

Reasonable, but you're avoiding the conversation.

You call back with more information, but you've signaled that you didn't know your own status. They're slightly less confident in you.

The delay wasn't necessary — you had enough information to have a real conversation. You just didn't want to have it.

The lesson: "Let me get back to you" is sometimes just avoidance in professional clothing. Know when you're ready to have the conversation.

The Result

You shipped it.

Group Payment Splitting launched 2 days before your biggest customer's first summer trip. 847 travelers used it in the first month. Support tickets for "how do I collect money from my group?" dropped by 60%.

The feature became SquadTrip's most-used functionality. Three enterprise customers signed specifically because of it.

What this scenario is really about:

Program management isn't about having the right answers. It's about making decisions with incomplete information, communicating honestly under pressure, and knowing when to scope down versus when to hold the line.

Every choice in this simulation was one I actually faced — or something close to it.

Let's talk for real
Now

What I'm looking for

I want to work on hard problems with people who care about getting them right. Infrastructure, developer tools, platforms — systems where reliability isn't a feature, it's the foundation.

I'm most useful when things are ambiguous, cross-functional, and high-stakes. When there's a clear playbook, you probably don't need me. When nobody's sure what the playbook should be — that's when I do my best work.

I'm also open to advising early-stage teams on program foundations, delivery systems, and how to scale operations without losing speed.

Let's talk

I'm not looking for a job. I'm looking for the right problem. If you're building something that matters and need someone who can operate in the gray area — I'd like to hear about it.

Email stevonjudd@gmail.com LinkedIn in/stevon-judd