Products
Solutions
Resources
“Hopefully, this will help them know that I’m not a bot.”
As I sat down to interview three Statsig + Amplitude engineering leaders, my goal was to give readers more visibility into what they’re working on. Lew Gordon, senior staff engineer on the data pipeline, expressed an additional personal goal. I asked what he meant.
“We’re a lot closer to customers on Statsig, and I’ve been hopping into a ton of support threads. I’ll say, ‘Hi, I’m Lew!’ And customers are like, ‘Who is this guy? Is this a bot? Can I get a real person to talk to?’”
“Maybe that’s a vote of confidence,” offered Larry Xu, senior director of engineering heading up the Statsig + Amplitude eng team. “Like because your answers are so precise?”
“Or you just need to update your blue avatar on Unthread,” said Shelley Wang, engineering manager for Statsig Console.
We discussed their careers, how Statsig’s tech and customers compare to Amplitude’s, and the future of shipping fast and safely. As we did, two things were clear to me: these leaders care deeply about excellent engineering, and they are all very much human.
Starting with backgrounds: Lew, you were telling me you joined Amplitude because of a white paper?
Lew: So, it’s about to get really nerdy.
I have a personal belief that databases are the most important part of any application. I’m somewhat of a database nerd. I’ve always been curious about how to deal with large data problems at scale.
When I was working on marketing analytics at Segment, I was trying to figure out what a shared backend looked like. One of the white papers I read was called Procella, about YouTube’s analytics platform. In the conclusion, it mentioned there was a company called Amplitude that had built their own system that isn’t published.
So I was like, “Well, there’s one way to learn: join the company.” I joined Amplitude about two years ago.
Shelley, what about you?
Shelley: I’ve been at Amplitude for four and a half years. The whole time, I’ve been on our experiment product, most recently as the lead on Feature Experimentation, focusing on making it easier for people to run their whole experimentation program.
I was a big Amplitude fan at my previous company. I’ve always wanted to work on products that I believed in and was a power user of. When I applied, I didn’t even know that Amplitude was venturing into different products like Experiment.
The draw for the new experimentation product was getting to work in that startup mentality of building something from zero to one, shipping really quickly, but with the backing of this analytics product that I already believed in. It was the best of both worlds.
Had you previously been into experimentation?
Shelley: I was pretty new to it at the time. Coming from a startup, we just didn’t run that many experiments because we didn’t have a big enough customer base to really do that.
The feature flagging side was much more comfortable to me, because on any engineering team, you have your homegrown feature flagging solution. From all that experience, I was (and the whole team still is) very strongly opinionated about how it should work.
And Larry, you’ve been at Amplitude the longest. How did you join?
Larry: Let me see if I can condense my background.
I spent the first half of my career working at big tech companies. And I came to the conclusion that I no longer wanted to work at big tech companies. So I joined the tiniest company I could find at the time in San Diego, a CDP startup called Tealium, and was there for eight years.
I loved building a CDP. But during that journey, I realized that there were limits to how far I could push it without investing in an analytics core. When I found Amplitude, I was like, “This is the company that solves for analytics. Now I can understand how analytics products are actually built.” And I’ve been here for five years.
I started on the experiment team. Back then, that was just four people, and two of them were founding members of Amplitude, Curtis and Nirmal. I hired Shelley. And during those five years, with the help of Shelley and others, we were able to build Amplitude Experiment from the ground up.
And my role has expanded in the last two years, taking charge of new products like Session Replay and Guides and Surveys.
And now your role has expanded to what was essentially one of your biggest competitors?
Larry: Yeah, it’s a crazy world that we live in now.
I’ve always seen Statsig as a very potent competitor, one that I could never really figure out how to outdo. When we got the call from Vijaye about this opportunity, I was probably the biggest fan of making this decision.
And so far, I’m loving Statsig. I feel like this is a dream opportunity.
Broad strokes, what areas have you all been focused on since the acquisition?
Lew: Mine has been mostly on the data/infra side, like understanding how Statsig’s data pipeline works.
Everybody has very different pipelines. At Amplitude, it’s real-time pipelines. Everything is Kafka. So it’s been interesting seeing how all of these Spark jobs run at Statsig. I’ve done Spark a little bit, but not nearly at this scale. It’s been quite the time trying to wrap my head around everything that’s going on.
There are a lot of experiment details I don’t know yet, but I can help with the engineering of, like, “We’re hitting BigQuery too hard,” or “We need to change the SQL so it’s more efficient.”
As an engineer, it’s really fun to just ship things. I’ve been doing a lot of that. Not anything necessarily huge yet, like just getting APIs for everything, getting MCP, but that’s also shoring up table stakes for AI-native.
Shelley: My team is called Console, and it builds the interfaces for how our customers manage gates, experiments, and all the other entities that Statsig has.
We’re diving into a lot of workflows for customer automations, like using APIs or MCP to manage everything. But also working on the user side, like improving the UIs for how people manage those in the product.
The Statsig platform is very clearly built by developers for developers. I think we can take a lot of the user feedback and make things in the Statsig platform simpler to improve usability. And that aligns with Statsig’s ethos. Like, customer centricity is an Amplitude value, but it’s of even higher importance for Statsig.
That seems like one of the key things Statsig is known for, the focus on customers and their requests.
Shelley: Exactly. We are trying to be iterative in learning from what customers want, what they’re reporting for bugs, what they want for feature requests and enhancements.
It’s a slightly different user base, really focusing now on the engineering persona. But we’re still able to use what we’ve learned on Experiment. I think there’s a lot of shared DNA.
My biggest priority is getting on top of the backlog. Just making sure that customers feel heard, and that we can ship as fast as Statsig did before.
Larry: I’ve been doing a lot with customers too, and honestly, tackling a little bit of everything. In some conversations, I’m the salesperson, explaining why Statsig is the right solution. In others, I’m the product person, making it clear what the road map and vision are going forward.
When I’m wearing my engineering hat, customers might have a list of outstanding issues that they want to go deep on with me, or a list of requests that they want to discuss, or an architectural overview that they want to do with us.
I bring that information back to the team, and we work to ship solutions. Sometimes that’s by diving into the code with the help of Claude. Sometimes it’s finding who’s worked on similar problems in the past and tapping them. Sometimes we brainstorm and debug all together.
Whatever is needed to help the customers, that’s my job.
Sounds like there’s a lot going on! What have you all been most excited about as you’ve dug in?
Lew: One is where I think the growth opportunity is, and why I said yes when Larry asked me to join this effort, which is that Statsig was building out logs, alerts, and traces. When I was on Amplitude Session Replay, I did a ton with those features. I feel like I could build something I love with Statsig. There’s a lot of potential.
The other thing that sticks out to me is the customer focus. I really enjoy just talking to customers directly. With Statsig, we use Unthread, and it connects to all the customer Slacks. I feel like it cuts out the telephone game. If I see there’s a customer issue and I know the resolution, I can just jump in and solve it for them.
That’s when they think you’re a bot?
Lew: Yeah, sometimes. Not all the time!
Shelley, what about you?
Shelley: Something that I always loved, even on Amplitude Experiment, is deeply understanding what people are running experiments on. Like, how are they using our product? How are they making decisions when building their products?
Statsig has different experiment types than what we provide in Amplitude, as well as customers in new verticals. Learning this whole new set of them is really fun for me, diving into their experiment use cases.
Larry, what have you been excited about?
Larry: I think number one, starting with what Statsig is known for, is just how advanced their stats engine is. It’s a very different beast compared to Amplitude Experiment. That’s clear the moment you go into the product and see all of the options that are available to you.
There’s a lot of learning to do there. Especially to meet the enthusiasm of customer data scientists. I don’t always feel comfortable answering their questions yet, but it’s really exciting. The type of customers that have chosen Statsig shows why Statsig has been a clear leader.
But the most exciting thing for me is, in the AI era, there’s a critical need for every engineering team to go really, really fast. Like, if you’ve talked to any engineering team, they’ll say, “I expect our team to go 5x faster, 10x faster, 100x faster.”
To go fast, it implies you need to go safely as well. If you don’t go safely, you’re just checking a bunch of slop into production by 10x-ing your throughput. Inevitably, you’re gonna build lots of tech debt. You’re gonna have lots of issues getting introduced.
So if you think about what actually solves that need, there’s really no solution other than Statsig. It’s the only tool that allows you to go safely while maintaining really fast iteration speed.
Lew: Safety’s the gap that’s missing in the industry. There are metrics and tests that happen before post-merge, but there’s nothing that guarantees safety. You really need someone to be watching a metric or get paged and roll back.
I think with Statsig, there’s a potential of the platform rolling out safely and rolling back safely for you. Like, Stasig built their own observability product internally. Connecting that with flags and experiments would be huge.
Shelley: We’re working on that on the Console side, too, this idea of how to review changes before they go out to your feature gate or your experiment configuration.
In the old world, a lot of this was just automated human review processes, where humans had to look and approve these things. We’re trying to build a more comprehensive platform where these safety features are all supported from AI, MCP.
And then to bring that even further, how does that work now that we have AI agents as part of the review process? Can we make it so that teams work even faster? I think that’s an area where we have a lot of opportunity to build the best workflows for our customers.
Larry: I think not many companies realize this, because a lot of people still see Statsig as an experimentation product. In reality, Statsig has been shifting from an experimentation product to an intelligent feature-gating platform by infusing it with the core elements of experimentation.
That’s the core of what Statsig does today. Literally, the frontier companies of the AI space are all using Statsig for this. That really shows the value that Statsig provides.
This problem of helping engineering teams ship fast and safer is largely unsolved today. I think our opportunity is to figure out the next set of things that we need to do to further unlock it for our customers.