Varun Mohan: preference

Transcript context

…Yeah. Yeah. Oh my god. Okay. I have a few more questions just about how you think and operate at Codeium. So you guys are kind of at the forefront of how product teams are going to operate. You're seeing the future every day. And so I'm curious if there's ways you guys have structured your teams, engineers, product design that might be different from how other companies are doing it or have tried stuff that has worked really well or tried stuff that's a huge disaster? One interesting decision that we kind of have for core engineering is that we don't have pure product managers for the core engineering side of the company. And by the way, that's purely because we build for developers and our product is built by developers. So I think the intuition from our own developers is hopefully valuable. If not, we might be hiring the wrong type of people. So I think our developers are, in some sense, flexing to be more product conventional product managers. Now on the other hand, if we were building something that looked more like Uber or the persona was very different and we didn't ourselves understand it, I think the organization wouldn't look the way it looks. For the enterprise side of the company, because we do work with a lot of large enterprises where the requirements are not something that our engineers would automatically understand, I don't think our engineers wake up and they're like, "We need FedRAMP." This is probably something that a lot of customers come to us with and tell us. We have people that flex in this product strategy role that understand what the customer wants and understands the technical capabilities that we have to best build a product that would help them at scale. So I think we have an interesting organization in this regard, but mostly I would say because we are a developer-based product, I would say that's true. And then also kind of like what you said for the engineering team itself, the team structure is, it's fairly flat. We try to go with two pizza teams, teams that are fairly small just because I think the problem is when a team gets too big, the person leading the team is no longer able to get in the weeds of the technology itself. And I think in a space that's moving this quickly, I think it's dangerous to have leaders that don't understand the technology deeply and are not building. It's very, very dangerous because there's too much armchair quarterbacking. And so I think that's maybe one other decision we made. And then teams are very, very flexible. So if we decide something is a new priority, we're very quick to change the way a team looks. And it's very centrally planned in this regard. The two pizza team concept, I saw a tweet long ago where someone from India, was like, there's always talk about two pizza teams, but pizzas in India are much smaller. And so the teams end up being smaller and they're like, "Why can't we build as much of these teams in the US?"…

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