High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / recommendation

Published · transcript-backed

Jay Baxter: recommendation

27 Feb 2025 Lenny's Podcast An inside look at X’s Community Notes | Keith Coleman (VP of Product) and Jay Baxter (ML Lead)

“I think one other thing that's key is when you are forced to have such a small team, well, this is important anyways, but deleting code is more important than writing it a lot of the time. So I think so often maybe due to promotion incentives or just regular human tendency, engineers have a tendency to add these little incremental wins that actually add more of a long-term maintenance cost than is clear, because you just run a little one month A-B test, you see this significant win and you don't realize the maintenance burden you just added to your team for the rest of eternity until you turn the thing off.”

— Jay Baxter

Source trail

Everything needed to verify it.

Speaker
Jay Baxter
Attribution
Verified speaker
Claim type
recommendation
Recorded
27 Feb 2025
Publisher
Lenny's Podcast

Transcript context

…Yeah. Exactly. They don't really necessarily want to help you or they're busy. Here, you're like, "Hey, guys, we need to do this thing with that other system you work on." And they're like, "Great! Here's the code. Here are the docs. Send us the fab if you have any questions, and we'll get it in." And it's just the thing, you can just jump in and get it done. And that kind of collaborative effort, like the sense of shared ownership, I think from my experience came from or was a result of the shrinking of the team down to people who wanted to be there and work together to build this thing. So I think that's been a really positive impact. It's not always easy. Certainly, a lot of people have a lot of responsibilities, but they're here because they're up for it. Yeah. I think one other thing that's key is when you are forced to have such a small team, well, this is important anyways, but deleting code is more important than writing it a lot of the time. So I think so often maybe due to promotion incentives or just regular human tendency, engineers have a tendency to add these little incremental wins that actually add more of a long-term maintenance cost than is clear, because you just run a little one month A-B test, you see this significant win and you don't realize the maintenance burden you just added to your team for the rest of eternity until you turn the thing off. So I think there's a lot to be gained and you get forced to do this, by the way, when you have such a small team. It's just auditing parts of your system and deleting the things where the maintenance cost is worse than the gains. So I think we did have to do this across the company after the big layoffs, and systems are leaner now and they can be worked on by fewer numbers of people. That's an amazing point. I remember Elon's being like, "Here, we have to throw away the whole thing. We have to re-architect everything. It's stupid the way it's built." And it sounds like that actually worked.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence