Building the platform, and the team, that transformed scheduling at scale.
0 → 15
Team Size
3 years
Timeline
650K+ / yr
Meetings Scheduled
18.5 yr effort / yr
Time Savings
$20MM / yr
$ Savings
01
Context
Why this mattered
Every meeting begins with the same question: When are you available? For Amazon recruiters, answering that question thousands of times meant countless emails, calendar negotiations, reschedules, and time spent coordinating logistics instead of connecting with candidates. We called it "scheduling ping-pong". Prelude was born by working backwards from that experience. The objective wasn't simply to make scheduling faster, it was to remove friction from the relationship between an employee and an end customer. By allowing customers to view availability and book meetings in just a few clicks, recruiters could spend less time managing calendars and more time focused on hiring great talent, while candidates benefited from a faster, more transparent scheduling experience.
Although Prelude was conceived to support Talent Acquisition, we intentionally avoided building a recruiting application. Instead, we designed the platform around two universal actors: an internal employee and an end customer. We knew that scheduling wasn't a problem unique to TA. By solving the broader scheduling problem rather than a recruiting-specific workflow, Prelude naturally evolved to support increasingly sophisticated scheduling scenarios and was adopted across Amazon by Solutions Architects, Sales, Human Resources, Customer Service, and many other organizations. What started as a tool to improve the candidate experience became a platform that simplified how employees connected with customers across the company, reducing administrative overhead while creating a more seamless and consistent experience for everyone involved.
02
The Challenge
Simple on the Surface
Complex underneath
Complex underneath
01
Constraint-heavy domain
Scheduling needed to be fast and simple for the customer but the system needed to be robust and flexible for the internal users. Prelude provided a myriad of configuration options to control a user's availability while keeping the customer experience clean and simple
02
High human stakes
Each scheduling experience reflected on Amazon as a company. The customer scheduling a meeting with a recruiter was almost always an Amazon customer too. A poor recruiting experience wasn't just frustrating for the candidate, it would reflect poorly on Amazon as a company.
03
Unforgiving integrations
We built Prelude on top of Amazon's existing email and calendaring systems. If those systems were unavailable, we had to handle that gracefully. Robust retry strategies, queueing, critical path telemetry, and clear messaging to customer meant an initial failure didn't halt the scheduling process. And when the failures were persistent, we knew immediately.
04
Moving organizational target
Adoption grew while workflows evolved. Every job-role Prelude supported brought it's own unique workflow and demands of the product. Our challenge was to distill these unique workflows into generic, extensible controls that could meet the needs of any organization.
03
How I Led
Creating the Conditions for Success
Building Prelude wasn't just about delivering a product, it was about creating the conditions that allowed an engineering organization to deliver consistently as the product, team, and customer base grew. Success required much more than a sound technical design. It meant assembling the right team, establishing a clear architectural vision, defining an effective operating model, and creating an environment where engineers could focus on solving meaningful problems. My responsibility was to provide the technical direction, organizational structure, and leadership that enabled the team to execute with confidence while adapting to the evolving needs of our customers.
As the organization expanded, my role continually evolved. Some days that meant mentoring engineers through complex design decisions or partnering with product to shape a realistic roadmap. Other days it meant working across organizational boundaries to remove blockers, aligning with principal engineers on architectural direction, or writing production code to accelerate delivery while the team was still taking shape. Whatever the challenge, my objective remained the same: create an environment where talented engineers could do their best work and deliver a product that customers trusted.
01
Hiring for Today and Tomorrow
Building a strong engineering organization starts with thoughtful hiring. I worked to assemble a balanced team of experienced engineers, emerging talent, and college hires, creating an environment where mentorship happened naturally and knowledge was shared across experience levels. Rather than hiring for immediate needs alone, I focused on building a team that could continue growing alongside the product.
02
Creating a Shared Technical Vision
Before development accelerated, I established the initial system architecture and validated key design decisions with principal engineers across Amazon. Those early conversations helped identify risks, challenge assumptions, and ensure the platform was built on a foundation that could scale as adoption expanded beyond its original use case.
03
Mentorship Through Everyday Engineering
Mentorship wasn't limited to 1:1 meetings or performance reviews. Design reviews and code reviews became opportunities to challenge assumptions, strengthen technical judgment, and help engineers think beyond the immediate implementation. By setting clear expectations and providing continuous feedback, I helped engineers develop the confidence and decision-making skills needed to take on increasingly complex technical leadership.
04
Creating Space for Engineers to Build
One of the most valuable things an engineering manager can do is protect the team's focus. I served as the primary interface with stakeholders, partner teams, and service owners, coordinating dependencies, resolving organizational friction, and ensuring integrations progressed smoothly. By handling much of the external complexity, the engineering team could remain focused on delivering value to customers.
05
Turning Vision into Delivery
Successful execution depends on strong partnership between engineering and product. I worked closely with product managers to shape the roadmap, evaluate the technical feasibility of new ideas, prioritize investments, and establish the engineering processes that kept delivery predictable. The result was a shared understanding of what we were building, why it mattered, and how we would deliver it.
06
Stepping In When It Mattered Most
As the founding engineering manager, there were periods when building the product and building the team had to happen at the same time. To accelerate our initial milestones, I contributed directly to the implementation of several foundational components, including the messaging framework, business intelligence and telemetry systems, and portions of the customer-facing web application. Once the team was established, my focus shifted back to creating opportunities for engineers to own those systems, ensuring my greatest contribution was enabling the team's long-term success rather than remaining the primary contributor.
04
Key Decisions
The choices that shaped the outcome
01
Invest in the Team and the Product
Situation
Like many product organizations, our roadmap was naturally centered on delivering customer-facing features. Investments in operational tooling, monitoring, engineering quality, and internal improvements often competed for the same limited engineering capacity, making them difficult to prioritize despite their long-term value.
Behavior
I worked with product leadership to intentionally carve out space for engineering excellence initiatives alongside feature development. Engineers were encouraged to identify and lead small, focused projects that improved our operational posture, developer experience, or team processes. These contributions became an important part of career growth conversations, reinforcing that strengthening the engineering organization was just as valuable as shipping customer features.
Impact
Over time, these investments paid dividends across the organization. Better operational tooling reduced support overhead, improved service reliability, and gave the team greater confidence in production. Just as importantly, engineers developed a stronger sense of ownership by improving not only the product, but the environment in which the team operated, creating a culture of continuous improvement that extended well beyond the roadmap.
02
Make Resiliency a First-Class Citizen
Situation
Prelude depended on enterprise systems that weren't always available and, in some cases, couldn't tolerate high request volumes. Designing for ideal conditions wasn't enough. We had to assume external dependencies would occasionally throttle requests, experience outages, or respond unpredictably, while still delivering a dependable experience for customers.
Behavior
Rather than treating failures as exceptional cases, we designed the platform with resiliency built into its core. Asynchronous workflows, intelligent retry strategies, and graceful degradation allowed the system to continue making progress when dependencies became unavailable. On the customer-facing side, we prioritized clear communication throughout the scheduling process so customers always understood what was happening, even when work continued behind the scenes.
Impact
Building for failure from the beginning produced a service that remained reliable despite the realities of a complex enterprise environment. Customers experienced a smoother, more predictable scheduling process, while engineers gained confidence that the platform could recover gracefully from issues outside of its direct control.
03
Give Engineers a Voice
Situation
As teams grow, it's easy for technical decisions to become concentrated among a handful of senior engineers or engineering leaders. While that approach can accelerate individual decisions, it limits growth opportunities and reduces the sense of ownership across the broader team.
Behavior
I intentionally created opportunities for engineers to lead. Team members owned design reviews, drove implementation plans, delegated work across the team, and partnered directly with product to refine ideas and propose new capabilities. Every engineer was encouraged to contribute not only to the implementation of features, but also to the direction of the product itself.
Impact
Giving engineers meaningful ownership produced stronger technical solutions and accelerated individual growth. More importantly, it created a culture where every engineer had a genuine stake in the success of the product, leading to higher engagement, better collaboration, and a team that consistently challenged itself to raise the bar.
04
Different Roles, One Team
Situation
Product, design, and engineering each bring different perspectives to product development, but those differences can easily create organizational friction when teams work in isolation or optimize for competing goals.
Behavior
From the outset, we worked to build a single, collaborative team rather than separate functional groups. Product and design participated in technical discussions, engineers were involved in product reviews and roadmap conversations, and successes and setbacks were shared across the entire organization. Every discipline had a voice, but everyone remained accountable to the same customer outcomes.
Impact
This collaborative approach built trust across disciplines and significantly reduced the friction that often develops between product, design, and engineering. Decisions were made with a shared understanding of customer needs, technical constraints, and business priorities, allowing the team to move faster while remaining aligned around common goals.
05
Outcomes
What Changed
650K+
Meetings Scheduled / Year
4
External Integrations
99.99%
Uptime
48
Languages Supported
Global
Adoption
80+
Organizations Supported
06
Reflection
Looking Back on Prelude
A great product is the outcome of a great engineering organization. Build the team with the same care you build the software, and success becomes repeatable.
01
Ownership changes everything
Engineers build better products when they genuinely feel responsible for the outcome.
02
Walk with the customer
The best product decisions come from understanding how people actually use what you've built.
03
Don't let your charter define your horizon
Solve the broader problem, and opportunities for impact will naturally follow.
04
Culture is an engineering investment
Time spent building trust, collaboration, and shared ownership pays dividends throughout the life of a product.
05
Design organizations to scale, not just systems
The architecture of the team is just as important as the architecture of the software.