Microsoft

I joined to build a scheduling form and I now lead customization for an AI agent that speaks inside meetings. The line between those two things is straighter than it sounds: every job I have had here has been about what happens when a meeting is configured wrongly, and the stakes of that question have gone up each time.

Everything below is drawn from Microsoft's public product documentation and from work whose shape I can describe without disclosing anything internal.

My first project was the Virtual Appointments template — the Teams meeting type built for business-to-consumer appointments with external attendees, where the guest joins from a browser without needing to know anything about Teams.

I designed and built the front-end form in React and TypeScript and integrated it with its backing services in C# and .NET. That was my introduction to full-stack work inside a product this large, and to how much of a scheduling experience comes down to what you do not ask the person booking.

Meeting Options is the panel that governs how a Teams meeting behaves: who bypasses the lobby, who can present, whether recording and transcription are permitted. It applies to effectively every meeting in the product. Meeting Templates sit above it, letting administrators preset those settings across a tenant and lock the ones that matter for compliance so an organizer cannot change them.

I led the reflow work on that surface. I also moved Meeting Options onto a modular architecture where the backend describes each setting and the interface is generated from that description. Before, a new meeting setting meant a client release. After, it meant a configuration change.

I also carried on-call for it and triaged production issues in the field. A settings panel is invisible when it works and immediately consequential when it does not, and being paged about one teaches you exactly what a configuration system is promising people.

Microsoft rebuilt the Teams calendar on Outlook's calendar and made the new unified experience generally available in January 2025. My job was to carry Meeting Options and Meeting Templates into it.

Porting a live configuration surface into another team's live product is mostly not an engineering problem. Getting the features across every environment took continuous work with the Outlook team and their partners: no regressions, no quiet loss of function, on a surface where a regression is visible to everyone in a meeting the moment it lands.

Facilitator is the AI agent inside Teams meetings: it surfaces the agenda, tracks progress against it, and captures highlights in real time. Copilot in Teams answers you privately. Facilitator's prompts and answers are visible to everyone in the room.

I started on the agenda product — reading into an unfamiliar codebase and shipping improvements against user feedback, governance requirements, and performance work. That was my first sustained work on prompt engineering, LLM orchestration, and evaluation-driven improvement. It was also the first time I owned a feature whose output could be wrong in a way tests do not catch.

I now lead Customization. The work is unreleased, so I will not describe it, but the problem is the interesting part and I have written that up separately.

I run this development close to fully agent-driven. The question I spend my time on is how to make agents more autonomous and self-sufficient while putting a governance layer underneath them that keeps the output safe, performant, and actually the thing we meant to build.

In practice the standards live in the repository as checked-in instructions, skills, and agent definitions, so they are reviewable artifacts and not review comments. Behaviour changes are judged against rubrics, not against a demo. Day to day this runs alongside AI scientists, prompt engineers, architects, designers, and product management, where most of the disagreements turn out to be definitional.