Decagon accepts coordination costs to preserve speed

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

1. 13:15

   And then the next one, the just get it done, decisive action and speed over prolonged deliberation and planning. How do you ensure, because speed has a trade-off, right? So speed obviously is an attribute that all of us aspire to in business, but at the same time, like speed can also mean thoughtless execution, sloppiness to cut corners, to just get it done fast. How do you kind of strike that balance?

2. 13:38

   So I think the trade-off for us has been speed on one hand versus coordination on the other, right so in terms of quality we've been able to maintain the quality bar by ensuring that hey when you ship something out when you roll out a new process it meets the quality bar but coordination is something that can suffer right because if you have two teams building the exact same thing in slightly different ways then you know it's hard to coordinate if everyone is building it out in two days and that's actually just a tax that we have decided to accept right it's not it's not a perfect trade-off you have to give somewhere and we gave for speed and the reason i think this is more true today is actually because the pace of building has changed so quickly with ai right in the old world when development took a lot longer and you know if you say okay i'm going to

3. 14:28

   scope out this feature and it's going to take me two weeks to build there's kind of some inherent coordination time in there right because it's going to take two weeks to build so during that two weeks, you have time for everyone else to coordinate what people are building. But now, instead of two weeks, if it's two days, there isn't that much time for coordination. And we knew that one of these had to give. And so we were more okay with the coordination piece giving in because we think if you're building fast enough, yes, if you have two teams that turned out to be building in slightly different ways, we're moving so fast anyway that we can fix that on the back end when it actually becomes a problem. Actually, it's an interesting point, like the trade-offs.

4. 15:05

   So you have these definitive cultural elements that you really want to adhere to. Some of that is informed by your past experiences, maybe for both you and Jesse. You mentioned one, coordination is something you're willing to give. Are there other aspects that you guys came in thinking, hey, these things get talked about a lot, but we are okay giving up on those a little bit for the sake of these four?

5. 15:28

   Coordination is definitely the biggest one. The other big one is probably productization quickly, by which I mean our general philosophy as a company, because we sell primarily to enterprises, was making sure that whatever we built worked exactly for the company as though it were built just for them. Right. And this is something that people generally are like, hey, don't do this because it's going to be very, very, very difficult to scale if everything is built bespoke.

6. 16:00

   right and so the difficult decision for us was how do we make something feel very bespoke and scalable at the same time so what we did was in the early days and this is now the very early days we actually built basically bespoke in a completely unscalable way because we figured once we get big enough we will figure out how to productize now that we are much bigger the way that we productize is not by saying hey we're going to build the standard thing and everybody should be able to kind of get to that, but rather to say, we're going to build the kind of right configuration points so that you can configure the product to suit you exactly, right? And that last mile of configuration, now we have AI agents, right? This is what they're very good at. So as an end customer, you can get something that fits you perfectly, but in a scalable way. Now, the problem that this

7. 16:50

   causes is now when you're building out a new thing, there is a risk of you overfitting to a customer because, again, our philosophy is it should fit you perfectly. And then if three people want three different things, you figure out the right configuration points. And again, that's a trade-off, right? Sometimes you're right. We will overbuild. We will build in a somewhat custom way that isn't scalable. But again, the assumption that we're making is, hey, once this becomes a problem, we will figure out the right configuration points and rebuild if necessary. Was some of this