How a Frontier Team Can Help Your Company Keep Up With AI

Dan Shipper (0:00)

You need a frontier team, here's why.

Every single person in your company is caught in this dilemma. Do I get my work done, or do I stay up to date with Ai and figure out what all these new tools and workflows mean for what work I should do? That's just crazy, it's so hard to figure out. Every single company is struggling with this right now.

Because, I mean, on the one hand, you could ignore the frontier, and that'll probably work for a little while until you get disrupted by some agent-native version of your product that you didn't see coming. Or you can keep up with the frontier and just chase shiny objects and never build anything that lasts. The reason why you need a frontier team is it separates things out. So you get this nice separation of concerns where you're both keeping up with what's going on on the frontier and you're actually getting your work done. And I had my co-host, Natalia, welcome Natalia.

Natalia Quintero (0:52)

Hey, Dan, good to be here.

Dan Shipper (0:53)

Who is our head of enterprise AI adoption. So I wanted to come in and do a little bit of digging into our frontier team. So we've been running the frontier team at Every for I guess a couple of months now, and it has been kind of transformative. And I think Natalia is one of the best people to come in and take a peek and be like, what are we actually doing?

Natalia Quintero (1:16)

So actually, I might turn the tables a little bit to you because it was your idea to have a frontier team.

Dan Shipper (1:22)

Yeah, I mean, yeah, the frontier team, I think, has been a huge unlock. And it's because of this separation that I've been talking about. I think there's so many people at Every, like me, who just love playing with new things. And that's super important. But if that's all you're doing, then you're not going to make progress as a business. You actually do need to go execute on products and services, things that people can rely on. And it felt like we needed to choose one or the other, either just constantly be playing with new stuff or make a product that we just build once and then we add features to and we support forever.

And the Frontier team was in a sort of an attempt to say, okay, what if we take all the people like me who love all the new stuff and we just unleash us to just run experiments? And at the low end, the experiments are just, they're just really good content. They just teach us something interesting and they become good tweets or YouTube videos or anything like that. And then on the high end, they get pushed up from the frontier into the products that we build into the services that we offer without the rest of the company feeling like they always have to be paying attention to every single model that drops in every single new experiment that we're running. So I felt like it's allowed me and the other people on the frontier team, the space to just figure out what the future looks like without forcing that on the rest of the company until it's actually ready for them to pay attention to it.

Natalia Quintero (2:42)

Now, one of the things that you seem to have figured out pretty early in the formation of the frontier team is that you wanted to have both pirates and architects. Can you describe what that is?

Dan Shipper (2:53)

I think there's two archetypes that work really well together, pirates and architects. Pirates are people like me who are just like, I just want to go really fast and I'm going to do stuff that's, it's going to be a little bit sloppy, but I'm going to try like a billion things in the space of a couple of days. I'm going to figure out what's useful, but it's going to be a mess. Architects are people who are really good at being like, there's a whole big, messy thing.

What would it look like to compress it a little bit and form it into a shape that actually works, that we can actually use? Because what we try to do on the Frontier Team is, we're experimenting with lots of stuff. Most of that stuff gets thrown out, and some of it ends up getting pushed into the rest of the team to see if the rest of the team likes it. At that point, there's a point right before we do that, where an architect becomes really useful to come in and say, this is messy, we can't actually maintain this, and it wouldn't work for these five different ways for the people internally at the company, and helps turn it into a system that we can actually understand and build on, instead of just being a one-off, vibe-coded project.