TL;DR I’m joining the engineering team at FastAPI Labs ⚡ and closing this chapter of my career in product management. Read on for more!

Building for builders

A little over five years ago, I shared on social media that I was transitioning from engineering to product management. Since then, I’ve had the privilege of working on developer tools at Microsoft, Docker, and most recently at Snowflake.

What I have loved the most about working in developer tools product management is that I got to stay technical and in the weeds, all while deeply focusing on user experience. I was able to participate in engineering conversations about design and implementation, even though I wasn’t writing production code, because lower-level design choices directly impacted the end-user experience. Despite having a recurring existential crisis that I missed working as an engineer full-time, I continued to work as a product manager because I loved it and was good at it (and my open source work scratched the true engineering itch whenever I needed it).

I’ve learned a great deal by working as a product manager, and I genuinely believe that I’ve become a better engineer through this experience than I would have been if I had stayed an engineer in name only. There’s also a long series of personal and professional events that followed the choice to try product management, for which I am eternally grateful. If I could go back in time, I would choose this path a thousand times over.

However, as time has gone on, I’ve felt myself getting further from the parts of the role that gave me the most energy, which, as it turns out, are the engineering bits. I also always said that the title was irrelevant to me. Of course, levels (e.g., senior, staff, principal) do matter, as they help garner a certain level of respect, but titles like software engineer or product manager never held much significance for me.

What I know is that I want to build things - specifically, tools and experiences for builders. For me, that has always meant two things: a deep commitment to developer experience and a connection to Python and open source. The products and projects I am proudest of are those that have genuinely made developers’ lives easier, removed friction, and allowed people to spend more time creating (or, frankly, just giving them the agency to choose what they want to spend their time on). I think often when we’re thinking about scaling quickly or signing the biggest deal, it’s easy to lose sight of what delightful looks like. However, when we ignore too many papercuts, we create an open wound. We make our products unusable and fail to solve the problem in front of us.

What’s important to me is remembering and emphasizing the humanity of what we’re building. I want to focus on solving problems for people. I want to spend the time talking to developers about how their workflow sucks, I want to fix that tiny bug that will make them more productive, and I want to deeply understand user workflows and tooling to the point where I can anticipate what better looks like before they might be able to articulate it themselves.

I want to take the “less scalable” path if it means that I can solve the problem correctly the first time. I sincerely believe that if you build the right experience and truly solve the problem, the people (and the money) will come.

One key problem that still has not been truly solved for Python developers is the journey from local development environment to a deployed application (with all the bells and whistles). Developers will spend hours setting up everything locally, only to face infrastructure, cloud jargon, and difficult decisions. This is a problem I’m all too familiar with, as both an engineer and someone who worked on tooling for Azure. This problem persists, especially in an era where an increasing number of new developers are choosing Python as their language of choice (just look at the latest JetBrains Python Developer Survey). I believe there’s still a significant developer experience pain point here.

And so, this all leads me to the title of this post: in a couple days, I’m starting a new chapter.

On October 6th, I’m joining the engineering team at FastAPI Labs to help build the future of deploying and managing FastAPI applications 🚀.

So why FastAPI Labs? Why now?

FastAPI is now the most popular Python web framework, so fixing this problem is both timely and impactful. More than that, I believe that FastAPI Labs is set up to build this the right way from the start, both in terms of working toward the right solution to the problem and the company ethos. You can read more about the FastAPI Cloud announcement here, or better yet, join the waiting list.

I first met Sebastián Ramírez (aka tiangolo) on Twitter about five years ago when I was working on the Pylance language server. Even then, what stood out to me was his attention to detail, his relentless focus on developer experience, and his understanding of the importance of open source in our community. It was always clear in his work that he didn’t just care about making something work but about making it delightful. So when Sebastián approached me about joining FastAPI Labs, it was a no-brainer. The chance to work alongside someone whose values resonate so profoundly with my own, on a problem that matters, at the right time, was an easy yes. I am absolutely stoked to be joining the team at such an exciting time!

I’m also grateful that part of my role includes dedicated time to contribute to open source. I’ll finally have the space to focus more deeply on my work on CPython, preparing for my role as Release Manager for Python 3.16/3.17, advancing CPython performance work (e.g., ensuring FastAPI runs smoothly on JIT/free-threaded builds), and continuing to support FastAPI and other related projects in the ecosystem. I feel tremendously fortunate to have the opportunity to work at a company that not only understands my open source work but also celebrates it as core to its own mission. This is something I never really thought I’d have the opportunity to do, so I’m incredibly excited.

So, that’s it. With one chapter ending, another one begins.

Savannah 🤝🏻 FastAPI Labs

…and yes, in case you were wondering, the subheader of this blog post is indeed a Charli xcx reference. Always.