Duck Tales: How we use mental models and operational defaults to improve decision making (Ep.39)

In this episode, Beah (Chief Product Officer) and Marc (VP, Engineering) discuss how we create, communicate, and challenge operational defaults to make better decisions at speed.

If you have feedback on Duck Tales, or episode ideas, email us at [email protected].

Disclaimers: (1) The audio, video (above), and transcript (below) are unedited and may contain minor inaccuracies or transcription errors. (2) This website is operated by Substack. This is their privacy policy.

Beah: Hello and welcome to Duck Tales, where we go behind the scenes at DuckDuckGo and discuss the stories, the technology, and the people who help build privacy tools for everyone. In each episode, you’ll hear from employees about our vision, product updates, engineering, or approach to AI. Today, you are going to hear about how we work, I guess, or one facet of how we work, which is using operational defaults and I have with me Marc, who is going to who I’m going to interview about operational defaults. Marc, do you wanna introduce yourself?

Marc: Yeah. Marc, I’m on the engineering team at DuckDuckGo.

Beah: Okay. That’s about all you need to know. and I’m Beah, I’m on the product team if if you haven’t seen me before. okay, cool. Well let’s jump in. What even is an operational default?

Marc: Yeah. Yeah, so defaults are I would say a deceptively simple concept. at at DuckDuckGo we’re always trying to leverage mental models to help us move more quickly and think more clearly and and things of that nature. in that context, the default effect is seen as a negative, right? And and I think we’ve all seen that in apps and in different places. Here we’re trying to leverage the the upside of that, where we’re basically taking any decision that you can make ahead of time that generally is true or has a right answer eighty percent of the time, we’re gonna call that a default. for that other twenty percent, we wanna leave room for our folks to be able to make exceptions, ideally very thoughtful exceptions.

Beah: When you say default is a negative in the app, you mean like, you know, if you get an Android phone and the default browser is Chrome and the default search engine is Google and it’s really hard for another player like DuckDuckGo to to break through th those defaults. Is that right? Yeah. Okay.

Marc: yeah, exactly. There’s there’s in Gabe’s book of mental models there’s the default effect and again it’s generally negative, but like I said, in this case we’re trying to use defaults as as something that we can leverage to help us go quicker.

Beah: Yeah, yeah. So how is that how is it different than a rule?

Marc: I mean it’s conceptually the same thing. I think rules are just more binary, right? Like this is something you do or you don’t do pretty much all the time. Where here we’re saying that these are things that are generally true. Like I said, eighty percent of the time is just the number that we made up. and that allows people to potentially make faster decisions. but we also want to include encourage people to think about what they’re doing and not just go on autopilot. And I think that’s the danger of catching something as a rule is that yeah, people will just kind of blindly follow it by default.

Beah: Yeah, yeah. I think that distinction is super important. Like, first of all, there are a lot of things where rules just have exceptions and therefore they’re not really good rules, you know? like you have to be pretty sure that there has to be a really good reason to make something a rule because it’s going to fit different situations differently. And yeah, it’s like once it becomes a rule, people like lose power to do anything differently, so they don’t think about it, they don’t feel empowered, and like with a default, there’s still a burden of judgment because you can overturn the default and choose a different path. but the idea, I think, would you care would you say this is a fair characterization is like A, don’t spend brain power thinking about like reinventing the wheel or thinking about something that doesn’t really warrant brain power, like there’s a good default, and B you know just to n to nudge people in the direction of the best average answer, you know.

Marc: Yeah, right. It’s leveraging decisions that we’ve deliberated over in the past and you know have come to a good decision on. and exactly what you said. We don’t want folks reinventing the wheel. That said, we do want I mean, we hire really smart people at DuckDuckGo and we wanna, you know, leverage and celebrate that. So yeah, everybody’s encouraged to challenge the norm, so to speak, or you know, pre existing defaults. And in fact that’s a big big part of this. whole concept is coming back and challenging these at times. But yeah, th they’re, you know, i in a lot of cases it’s it would just be wasted effort to be rethinking this from scratch. And as much as there are some that are that are rule or that you know might make better rules because they are more binary, there are others that really don’t make great defaults either. we had a decent example where it was like, yeah, there is something that was true, say fifty percent of the time. I don’t remember what the actual number was, but it just didn’t make a great default. I honestly don’t remember what it is, but yeah, d just to say that not everything c falls into that framework framework.

Beah: Yeah, that that’s a good segue. Yeah. T t give me some examples of things that we do think are good operational defaults or that we treat as such.

Marc: Sure, yeah. I mean we have a bunch I you know, one of the things that’s so powerful about this is that I think we all do this all the time. so for example at DuckDuckGo we try to prioritize quick wins, which I guess the other thing I should say about defaults is that they are somewhat self evident, like to the point where that’s why I said they’re kind of deceptively simple because there are things that you don’t necessarily feel like you should have to put a lot of time into, a a lot of thought into. But quick wins are one where, you know, we at the company we’ve been, you know, trying to push people toward that. Right. Like the idea of a quick win is something that is relatively low effort but has high impact. And I mean you would saying it out loud, you would say, of course that’s something we should prioritize. But I think it’s also important to acknowledge that people don’t think that way. instinctually in a lot of cases. They wanna sometimes they want to work on, you know, the hardest thing or what they see as the most impact when, yeah, maybe less would do. so that’s one. one of my favorite ones, and I think a lot of people at this company would agree is we do no meetings on Wednesdays. so that’s a very simple one that, yeah, you we we don’t I I I w wouldn’t call it a rule, whereas we don’t you know, you can have a meeting on a Wednesday and sometimes you have to, especially as if it’s with somebody external. But generally you shouldn’t be scheduling meetings on Wednesdays.

Beah: See, that’s interesting because I would have called that one a rule. We I specifically I would have called the rule no

Marc: I mean

Beah: If you want to hop on real time and talk to somebody internally about something as it comes up, fine. If you have like an external call, we’ve also accepted that. But I I try to enforce that one as a rule because I think that one, if it’s a default, people just don’t observe it. They break it way too much. That’s my opinion.

Marc: Well, I yeah, but I think you just gave a few exceptions that are good, right? Like I I’m not gonna necessarily schedule something ahead of time, but I will yeah, reach out to somebody and say, Hey, it would be quicker if we talked about this ad hoc. So maybe I mean, yeah, maybe it’s splitting hairs, but

Beah: Yeah, it’s interesting though, because I think of those as part of as like the rule is constrained. So I guess making a rule is is safer the more you constrain it. And you could you could arguably ha tackle one operational problem and either make a highly constrained rule that has exceptions and carve outs or a broader default and maybe sometimes both at the same time. So yeah, okay. All right, that’s a good one. give me you got another example.

Marc: Yeah, fair enough. Sure. Sure. Yeah, I I can give you another one. so this one we came up with recently and that’s working incrementally, which again, you would say and when I say work incrementally, I basically mean you know we’re we’re trying to ship smaller features more frequently or even larger features and smaller increments. you’re going back and you’re you know, making sure that you’re on the right track, etc. Which again sounds like obviously that’s something that you would want to do. But anyone who’s ever collaborated with anyone on anything, I think would would realize that, yeah, that’s I don’t think that’s a human default, right? Like I think we all, you know, want to have a task, go build whatever we’re supposed to build, and then show the awesome thing that we did. And yeah, that’s I think that’s a good instinct to have. But there are many cases where if you misunderstood something initially or new information pops up, yeah, it’s super important to make sure that you’re raising that up and collaborating with others on

Beah: Mm-hmm. So you s you said that we made that one recently. Like what does it mean to make an operational default? How do we codify or communicate these?

Marc: Yeah, that’s a great question. And I don’t think we’ve actually figured that out yet. We have a lot of defaults across the company. This one was was communicated to to several objectives. but yeah, it’s not I would say it’s written down, but it’s not there’s no like internal glossary or internal directory of of defaults or anything like that. It’s basically just a reminder for folks. And again, it seems like it’s something that you should obviously do, but I think it’s important to remind people of these things.

Beah: Yeah, so like we basically we write things down in the form of like messages and or or really I mean anyway, but and I think that can happen maybe one thing that’s worth saying is that that that can happen at different levels of the organization. Like sometimes you have a group of five people working on an objective and they might adopt their own defaults or ways of operating. And then on the other hand, once something once we like believe something to be

Marc: Sure.

Beah: Sorry, I don’t know if listeners can hear that, but my dog is drinking some water right now. So we’ll see if that comes through. you know, once we’re really confident in something and that it’s like broadly applicable across the organization, then we might communicate it at like a higher level and codify it a little bit more more strongly as a default.

Marc: Yeah, and that’s kind of where that’s kind of where we are with this right now. We’ve communicated it to a couple of objectives. You know, objectives end up having their own culture, intentionally or otherwise, and this is yeah, an attempt to kind of test it on a smaller care scale before we start communicating it more broadly. and I I have one other I can give. This one’s much more engineering centric, but so we’re all working on AI quite a bit these days.

Beah: Yeah. Okay. Yeah.

Marc: And I think anybody that’s ever worked with, well, anybody that’s ever used AI will tell you that or has observed that you don’t get the same answer twice, right? It’s it’s you know so-called non-deterministic output. so in order for us to build products leveraging AI, it’s really important that we have evaluations up front, right? That you start with, you know, say a list of if I have question why. or sorry, question X, I’m gonna get answer Y, or at least something in the general with the general gist of of answer y. and yeah, because you can’t always super accurately predict what’s gonna come out, it’s really important that before we start building something, you know, you you have this eval or evaluation data set so that you know when you’re doing a good job or or when you’re when you’re not. I think that one honestly that one’s fairly close to a rule in my book, in terms of the engineering expectations we have, but there are definitely cases where it, you know, it doesn’t make sense or it’s too much effort to start there.

Beah: Yeah. And so like because that’s a default, even if people most people kind of think it’s a best practice, codifying it as a default means that if somebody decides not to do it, they might get the question, why? Are you sure? And they have to like defend basically if you don’t use a default, you have to have a good answer.

Marc: Yeah, that’s exactly right. Yes, you have to have yeah, there’s there’s we encourage people to make exceptions, but it’s gotta be well reasoned.

Beah: Up there. Yeah. Yeah. Yeah, yeah. Cool. Can you think of any defaults that we’ve adopted as an organization or on a team and then like decided were the wrong default and changed them?

Marc: Yeah, I thought about this one a bit. I I can’t think of one where we actually decided this was the wrong default. But I can there there are several that we have you know, potentially evolved over time, and that continue to evolve. The one and and yeah, this one is also super engineering specific. But the one that that comes to mind is, you know, initially all of our back end engineers were the default for all of them was to use Perl for our back-end services, the Perl programming language. But we made exceptions there, you know, because no language is the right tool for every job. So, you know, if we were developing something that Perl just wasn’t the right tool for, we gave people the space to make a case to not use it. That and that was true for a number of years. I think now I wouldn’t call that a default anymore. I don’t think that that that is the starting place for most folks, like when we’re developing a new a new service. so maybe that’s one that as you would either say is evolved or or maybe retired is a better way to put it. But yeah, I I can’t think of one where I think we were actually outright wrong, but definitely new information and things come in and we change them.

Beah: Mm. Yeah. One that kinda one that comes to mind to me that maybe went from having a not really having defined a default intentionally, but let kind of the flow of the stream define itself was we we, you know, as some listeners may know, our company is organized into a a bunch of objectives, like teams working towards some important goal for the company. And those objectives are expected to hold what we call an assessment every so often to kind of like redefine the strategy in the roadmap. And we I think f for the first maybe f few years I was here, we didn’t have an explicit expectation on how often that happened, but I think the sort of adopted default was a pretty long period, like maybe on average, I don’t know, five months, six months. something like that and then at some point we what’s that?

Marc: Yeah, when you felt like it was important. I said when you felt like it was important, it was very I think very subjective.

Beah: Yeah. Well and it was like easy to procrastinate if you were leading an objective, you know, like ‘cause it felt like a time like a thing you’d have to put time into and put yourself out there. And so it just kind of was like getting long. But in reality we observed that when people ran assessments more often, we had better roadmaps and better decision making and, you know, sort of less leaving the track without, you know, the help to get back on the track and

Marc: Yeah.

Beah: And so at some point we I think maybe said like let’s default to every eight weeks and then we maybe t brought that back to six. Right now it’s it’s six weeks is the default. and I think that’s been a nice improvement to make that explicit.

Marc: It’s actually a it’s a good example of working incrementally over a you know, different horiz time horizon. But yeah, for sure.

Beah: Yeah. Cool. Anything else you want to add, Marc, before we wrap this?

Marc: I don’t think so. I think again, I feel like I have to keep saying that a lot of these are self evident because it just sounds so obvious in a lot of cases, but it is yeah, I think I think it leads to better results and and hopefully we’re gonna see that very soon in these objectives that where we’ve introduced it and yeah, r really important to challenge them as well.

Beah: Yeah, there’s probably a lot of obvious things that people don’t do on the regular because of some cognitive, you know, glitch or habit or, you know, your predictably irrational behavior. So yeah, just making it explicit I think can be powerful. Cool. All right. Well, thank you, Marc, and see you around.

Marc: Yeah, yeah. Yeah, thanks.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit insideduckduckgo.substack.com