• Cate’s blog
• Cate’s article on servant leadership

Allen: Welcome to It Shipped That Way where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike. Joining us today is Cate Huston with a background in mobile engineering at Google and Automaticc Cate is now the engineering director of Native Apps at DuckDuckGo. Welcome, Cate.

Cate: Hi, Allen. Thanks for having me.

Allen: Thanks for being here and making the time zone shenanigans necessary to do a cross oceanic recording.

Cate: Yeah, it’s a great way to spend a Friday night, hey.

Allen: Party time talking about engineering leadership.

Cate: Exactly, exactly.

Allen: That’s what I do for fun. So we’re going to dig into a bunch of leadership management topics today but first I wanted to give you a chance to orient us, especially the audience. I know about your background but to tell a bit of the story, how do you like to describe your background? What’s the Cate Huston story so far?

Cate: It’s a normal engineering path, degree in computer science, dropped out of a master’s program, went to work at Google, ended up in management.

Allen: Just like that. Snap.

Cate: Yeah, I mean, so actually somebody I know is like, “Oh, I’m looking for a manager for this team in Colombia.” And I was like, “Oh, let’s see if I know anybody.” And then I came back and I was like, “Oh, did you find anybody?” And he was like, “Oh I have if you would move to Colombia.” And I was like of course I would move to Colombia. And that is how I ended up as a not entirely legal migrant in Colombia.

Allen: Okay, well see that is not just like that. You said, “Totally normal story just like everyone else. I just ended up moving to Colombia on the down low to get a leadership position.”

Cate: Well that’s true, that’s true. But I don’t know. I was always pretty… I grew up in the UK and then I went to Canada for grad school. Well I went to Canada to learn to be a ski instructor and then I went to grad school in Canada and then I moved to Australia and then I was nomadic for four years. Now I live in Ireland.

Allen: I love that tidbit about the origin story. So you’ve gone through this path, you’ve worked at Google, you’re in leadership position at Automaticc which is super cool and increasingly cool. Not knowing too much about the business in the background but obviously with all the tumult in social media right now, a lot of people are looking at Automaticc like, “Oh that’s an interesting company.” And then DuckDuckGo is also a super interesting company. I think a lot of people saw them as kind of this hopeless underdog. Like, “You can’t take on Google. You can’t build a search engine that people actually want to use.” And then I feel like I talked to people, more and more and more people are like, “It’s my default.” And I think talked to more and more people where that’s the case for them too. And you’re director of Native Apps there. What does that role look like? What’s the core of that role in your mind?

Cate: Yeah, it’s basically to make sure that the Native Apps team can meet the needs of the organization which have been growing significantly. So there’s been a lot of scaling. There’s been some processes that needed to be updated. I’ve spent a lot of time on our hiring processes both on hiring senior engineers and also most recently director hiring and then just a lot of, I guess, coaching people, just people management stuff and then just projects. Is this project going well? Could it be going better? If I poke at it, will it improve it or will people just get mad at me? So that kind of thing.

Allen: I feel like that’s one of the fundamental questions of leadership is will interfering in this make it better or worse?

Cate: Right. Right. You’re shrouding as manager of some type. But yeah, I think a lot of the work I do tends to be like… I’m a very behind the scenes person which I find really interesting because I’m extremely online personally and then at work I’m so behind the scenes. I don’t know. Very few people know what I do.

Allen: Well I imagine… Well I don’t know, is that an intentional strategy or is that just a personality thing coming through?

Cate: No, it’s kind of weird. But yeah, I just like to keep my online persona separate from my work persona because, I don’t know, I think everybody’s worked with some internet thought leader who was actually an incompetent asshole. Two halves of my life so I just keep them separate. Yeah.

Allen: Yeah. Well I think that’s something that we all learn if you’re an online person, that you learn, eventually meet certain folks that have well outspoken online presences or personalities. And some of them are what this says on the tin and they have the genuine interests and opinions that they express. And other times you interact with that percent real life and you’re like, “Oh actually this is just a character you play on the internet.”

Cate: Exactly. Exactly.

Allen: You’re just doing it for clicks.

Cate: No. I remember somebody, I’m not going to say who it was, but they were talking about somebody who’s really about Manager READMEs and was writing all these posts about Manager READMEs. Don’t get me started on Manager READMEs. Anyway, my friend who had worked with this person was like, “If only he did any of the things in that document.”

Allen: I think everybody sort of collects some of those stories. We’ll try not to get ourselves in too much trouble with that. And it is nice to try and walk the walk that we preach. You’ve already brought up a couple of the topics that I think would be good to dig into and one of them is on hiring. And hiring is something where one of the fun but also daunting things about leveling up as you go from an individual contributor to manager to director of learning, then to hire that next role, that level. And there’s a lot of things that are in common and then there’s some things that are totally different. And you’d mentioned director hiring which is a relatively new thing for me but it’s super fascinating. How do you think about the differences and the similarities? But probably most interestingly, the differences between hiring someone at this sort of director level talent-wise as opposed to more individual contributor or maybe line manager roles?

Cate: I think when you are hiring like an IC or maybe even a line manager, you have something that you know how to do and you’re looking for somebody who can do that. When you hire a director, you have something that you don’t know how to do and you are trying to hire somebody who can do that.

Allen: That is a really great way of summarizing or at least the experiences that I’ve had attempting to do this and the difficulty curve I guess. I suppose that’s possible that you could be hiring and certainly there’s some circumstances where there’s a VP who was the director of X and they’re just trying to replace themselves. But certainly I’ve been in a position that it sounds like you have been in too where it’s like, “Okay, I really know how to do this thing but I need a director to take this piece of it that our needs are exceeding my capabilities or that we just have never had. I don’t have an experience at X.” How does that change how you approach the problem? And what are the pitfalls or mistakes that you maybe have seen happen with that change in mindset?

Cate: I guess the first thing is I think it’s a mistake to think that you know how to do the job of someone you are hiring into a leadership position because especially if you have a bunch of tenure, you have a bunch of organizational context, the things that you do don’t necessarily apply to the person you’re hiring. I love my boss. We have a great relationship but sometimes he’s like, “I would do this.” And I’m like, “Great white male CTO, what am I going to do?” Because this doesn’t necessarily apply. In terms of approaching it generally, I think that for me it’s really important because you have to try and understand somebody’s strengths and how they… I think the best way to do that is to look at their previous experience. So at DuckDuckGo we do a lot of work sample projects, especially for Ics. Like, “Here’s this project and it’s very similar to the kind of core problem that we work on day to day.” And then we evaluate it. But giving a director some kind of hypothetical thing or some kind of toy problem, that wouldn’t provide any kind of useful signal at all, right? I want to know how they operate in a complex situation and I also want to know not just what they do but why they do it. I think often people from large organizations will tell you how they navigate a large bureaucracy but why is that? Why do they do it that way? Is it that’s how you are effective in the large bureaucracy? Or do they have some principles that they’re operating from that they apply in this large bureaucracy? DuckDuckGo, I think the principles are particularly important when it’s a smaller company that operates in frankly a pretty weird way because unless people have a depth of understanding, they can’t adapt their playbooks.

Allen: Yeah. That makes a lot of sense and really is interesting to me because I’m particularly fascinated with companies that are weird because almost always there’s something to learn there. If you’re just like, “Oh, we just use the standard playbook.” So can you tell me a little bit about what makes DuckDuckGo weird other than it’s a search engine trying to compete with Google and it’s called DuckDuckGo which are cool and weird things but as an organization?

Cate: Actually I describe us as a privacy company but I’m just going to leave that topic for somebody else. But as a director, I think one of the things that’s weird about DuckDuckGo is that you don’t just get given, “This is your director.” You can actually get hired at some bigger companies like, “Oh, you’re director. Here is your 100-person team. Here is your admin assistant. Go.” And at DuckDuckGo it’s much more like you have to build your own director. And so I’ve been hiring directors into my team because it just got too big for me and it’s basically like, “Here’s this problem space. There is a director level role here but you are going to need to figure out what that looks like and build it in terms of the different things that we have.” So instead of managers, we have this concept of career advisory which honestly I think is really just the definition of managing a high performer. But there’s a little bit more latitude in it. So you don’t just get given, “Here are your people. You manage them now.” They have to want you to be their career advisor.

Allen: Oh, interesting. So this is that inverse. That hints a little bit of holacracy which I assume it’s not in most ways but there’s a little bit of this. Someone opts into… There’s more agency it sounds like.

Cate: Yeah, there’s a lot of agency. And then we have functional team leads. We have… It’s a regular platform team for example. And then we have what we call objectives which are really product teams. So they’re normally run by a product manager. And so there are places there where this product manager clearly needs an engineering partner. Like, “Go and figure out what that means with this person so that you can deliver on this complex work stream together.”

Allen: Okay. So just to make sure I understand, are you saying that basically people don’t have a manager unless they choose to have a manager? And if so they choose a particular one? Or are you saying people have a manager and then they also have a career advisor as well? Or tell me a little more about the mechanics of that.

Cate: So they have a career advisor that they agree to. So when people join, it’s like, “This is your career advisor.” Especially over time, they get a level of choice in that.

Allen: Okay. So everyone has one and only one or at least one?

Cate: Only one.

Allen: Only one. And I’m keeping an open mind here, who knows? And so they have one career advisor but then as the role of all of a sudden they’re growing and maybe the scope or retention changes or needs, then they’re part of that conversation about who should be your career advisor. And then do you have a hierarchical org chart of these are the career advisors for these career advisors and it’s a chain? Or is it possible that your career advisor is being then career advised by somebody who isn’t even related to the same path? It’s not a tree structure?

Cate: I think in practice most things are trees and it’s pretty normal. My team, it’s a tree except for one person. And my career advisor’s the CTO. So we’re in a pretty normal tree. But I think the point is that it doesn’t have to be a normal tree. And even within that, it’s not necessarily… I have Android developers who are career advising Windows developers for example. And I think the good thing about it is that when you’re in, let’s say a normal organization, your manager is your manager and you get what you get. You don’t like your manager, you have to change your job as well. So you have to go and work on something else or you have to go work somewhere else. But in this structure, sometimes we allocate people based on our best information when they join. And sometimes three to six months later, I look at the situation, I talk to the career advisor and I’m like, “This isn’t actually what’s best for this person. I thought this person needed a really low-key supportive career advisor but actually they need someone who is going to be a little bit more authoritarian and hard driving with them.” It sounds really bad but some people actually really want… You know?

Allen: Certainly I’ve seen that dynamic. Not… you imply something bad about that person but it isn’t at all. It’s where they are at the stage of what they need. And I’ve seen incredible things happen where somebody who didn’t really have a lot of motivation and purpose given somebody who has a little bit more structure and is a little bit more firm with their communication and things like that and then they flourish. So I totally get that.

Cate: Yeah, it’s a better way to put it. And sometimes it’s the model that person needs. If they’re a bit more low key, they’re maybe not pushing back as much as they could or should be. And so when they have a career advisor who’s a bit more assertive to them, they can teach them how to be a bit more assertive in that way too. And so it’s almost like, “Does somebody need the career advisor that’s like simpatico or do they need the career advisor that challenges them?” And you make your guess as people come in but sometimes you’re wrong and then you can change it, without changing really anything about that person’s job.

Allen: It doesn’t sound like then that’s… Or I don’t know. Or I assume that you’re not just having that and totally it’s the individual contributor realizes, “I think I could use somebody who’s a little bit more firm and assertive with me.” It sounds like there’s two different things going on that maybe when people are more junior or maybe starting out in the organization ,you have a little bit more top down. Like, “Hey, I think this is what these people need.” And then maybe when people are getting to the higher levels in the organization or further along in their career that they’re more involved in that conversation.

Cate: Yeah, well we only hire senior plus people. But basically people get what we think is best when they join. And then at some point, you might have a conversation with them which is like, “Is this…” Or they might have that conversation with their career advisor of, “Is this what’s serving you? What do you need right now? What would you benefit from?” I think the reality I find is that people really like their career advisor and they don’t initiate a switch. But sometimes one thing I’ll do is I’ll just come in and be like, “Look, I’m not going to make you do anything. I’m just going to make you think about it.”

Allen: I get that. Every time I hear one of these kind of management or leadership or structural dynamics, my brain just starts going a hundred directions. What are all the interesting consequences that could be like, oh, how did that…. Would that affect the total jerk manager and then everyone wanting to leave their team obviously would get outed faster which is a nice thing when you involve people in conversations about their manager. But one of the things that it makes me think of is this conversation that you and I have had a little bit and I know you’ve written about which is this idea of this servant leadership which obviously is aligned in some ways of what you’re describing. Managers should be incentivized to want their team members to stay on their team or we’re not talking about teams but the career advisors. And that people could maybe leave so then that creates some incentives even more to want to try to make sure that you’re supporting that person and all these sort of things. But you’ve written some to what to me is really insightful things as someone who loves the idea of servant leadership. Yeah, we’re here to support the people. They’re not here for us, we’re here for them, for the people who report to us. But then you’ve written some things about some of the pitfalls with that, maybe educated a little bit by some of the dynamics that you’ve seen at DuckDuckGo. Do you want to tell us a little bit how you coach people to think about that dynamic in between serving your team but not serving, serving them?

Cate: Yeah. It’s like the core thing for me and the idea of servant leadership is you can’t be the servant of people that you have power over. So either you’re pretending you don’t have that power or you’ve given it away.

Allen: Right. Hence making it harder to actually be effective as a leader.

Cate: Exactly. Exactly. So both of those are pitfalls, right? You’ve given away your power. You can no longer do your job. And if you’re pretending you don’t have it, you’re really just gaslighting people. And you’d be like, oh yeah, buddy buddy. But at some point it’s view time or it’s something, you’re going to have to do something and then the truth will come out. Power dynamics are a whole topic in and of themselves but it is your job as a manager to make your team effective. It’s not your job as a manager to make them happy. They’re adults. They’re responsible for their own happiness which doesn’t mean you should torture them. In the management style it’d be a must, that we’re all seeing right now. But also because that does not make your team effective. Yeah, maybe you can torment people into shipping something this week but you can’t torment them into staying and working with you long term. Right?

Allen: Effectiveness requires retention. They must be here to be effective.

Cate: Well otherwise you’re going to spend a lot of time hiring. You’re going to be less effective. Your turnover’s going to be really high. And then similarly, managers who prioritize their team’s happiness over everything else, there are no amount of treats and kudos that is going to make a team that is not shipping, happy.

Allen: I’ve seen that. Do you think the idea of servant leadership is inherently flawed? Or do you think it’s more that you just have to make sure that it does make sense to try to keep the mental model if you’re there to support the team rather than the other way around but that you need to be cognizant of the power dynamic and make sure that you’re prioritizing supporting their effectiveness rather supporting their subjective happiness or what you project maybe their happiness will be today based on they don’t want to fix this annoying bug or something.

Cate: I think that the name of… I think there’s some useful… If you read about servant leadership, you might read something that’s really good or you might read something that’s utter nonsense because the name itself is just problematic because of this power thing. So it’s like, what do you mean by servant leadership? Do you mean that it’s your job to help the team be effective? Do you mean that you’re not seeking out recognition as a leader, stuff like that? Those are all reasonable things but you could call them what they are and not put them into this bucket, right? Because just the name is just this big catchall that people can use to mean really terrible things. They say… Let’s go back to some manager READMEs. I remember reading one and this guy’s like, “I practice servant leadership, blah blah blah, blah, blah, blah, blah.” Buried down in it is this comment of we will have a 30-minute one-on-one every two weeks. If you do not put an agenda there, then the one-on-one is canceled. I’m like, that’s a reasonable thing to do but it doesn’t actually send the message of-

Allen: Different vibe.

Cate: … no, I work for you. It’s like you’re just saying you’re a servant leader because you think it sounds nice. You sound like kind of a despot if I read the rest of your document. And that’s fine. Maybe this guy has a job where he needs to be kind of a despot. But maybe you should just admit that instead of pretending.

Allen: Manager README, “I’m a despot.” I’m-

Cate: Right? I remember giving this manager some feedback once, this team lead some feedback. And I was like, “You’re being pretty authoritarian basically with the team and whatever.” Anyway, what they said back to me was they were like, “I practice servant leadership.” And I was just like, “Oh, that’s me told.”

Allen: You’re being authoritarianly told not to call them authoritarian.

Cate: Exactly, exactly. I’m like… It’s like, well, I must be wrong because you’re practicing this thing that is fundamentally meaningless. Okay, I guess my feedback’s useless then. You do you.

Allen: “Sorry I wasn’t rude because in fact I’m nice so please stop talking.” “Oh, okay, great. Thanks.” “Okay, good to know.”

Cate: Exactly. Exactly, exactly.

Allen: Okay, I love that. And I’m going to kind of turn on that in my background. One of the other things I wanted to get a bit of a read for you or gave a chance to talk about a little is the idea of, and it probably factors well actually to the things that we’ve talked about here, how we measure success. Obviously giant companies larger than yours or mine get more and more lured to the idea of metrics of, okay, what is the team velocity? What is this group’s velocity? How fast are we moving? And we’re seeing a lot of drama in the press about companies that are doing sort of dramatic and maybe questionable things on the idea of we got to move faster. I need higher velocity. How do you think about measuring or even just talking about the effectiveness and pace of work on teams? Is it something that is even worth trying to measure or think about? Or do we just trust the team that if they’re all focused, that we’re just going to assume the pace that they’re working is the right pace? Or how do you think about that?

Cate: I think if you ask anybody how their team is doing, they’re going to tell you that their team is actually good. But it’s much easier to measure progress than state.

Allen: It’s much easier to measure progress than state. Yeah, absolutely.

Cate: So you can tell if a team is improving but you can’t really tell if a team is good. So I’m just like, what if we just didn’t know if any of our teams were good and we just focused on knowing if they were improving or not? And at some point they’ll be good. We won’t know when.

Allen: All right, I’m picking up what you’re putting down. So rather than trying to measure velocity, you’re trying to measure change in velocity which I think is called jerk. Or no, acceleration. You’re trying to measure acceleration. So that’s your kind of mental model. Is that an accurate kind of description of your mental model of it?

Cate: Yeah, because I think when you start talking like, oh, is the team doing well? You’re just having the wrong conversation, right? Because everyone will get defensive and justifying of it. And instead I just like to talk about how can the team do better? How has the team improved? Those are the celebrations, right? Not the… I’m sure you’ve seen those teams that are really… From the outside it’s like this team does not seem to be doing that well but they’re talking about how great they are and patting themselves on the back all the time. That’s why I hate that conversation because all the metrics can be gained. And say story points is our metric, okay? Every story is worth double the points. Now the team’s doing twice as well.

Allen: Yay, we won. We made lots of points go up.

Cate: Good job, good job.

Allen: The graph is going. How do you think then… Or I don’t know, maybe there’s no such thing as this, but how do you think about teams that are at peak performance? Or it’s like there’s no such thing? There’s no team where it’s like they’re doing well enough that a good focus is to try and help them continue to execute that way. Or is it really just if you’re not improving, you’re dying therefore there isn’t really a concept or it’s not worth trying to think about these are the teams that are being most effective? And let’s try to be more like them and maybe less these other teams.

Cate: I think that most effective teams do this. They’re always looking at how they can be doing better and what would be helping them and what’s slowing them down.

Allen: I think that that accurately describes the best teams I’ve ever worked with, what you just said. That the best teams I’ve worked with are the ones that don’t think they’re the best. They’re the ones that are worrying about how to be better. And the ones that think they’re the best teams, are average or less.

Cate: Exactly. Exactly. Because they’re focused on what can be better not on saying that everything is fine. It’s a different mindset.

Allen: Do you think that there’s things we can do as managers or directors, leaders in org to help foster that mindset of growth and acceleration and improvement rather than a mindset of trying to benchmark, okay, well what’s the velocity of this team or what’s the velocity of this product, and are these people being too slow or that kind of thing?

Cate: Yeah, the thing I like to use there is the idea of experiments fade because I don’t want to be the person on the team’s tail every week being like, how can you be better? How can you be better? Just going to piss everyone off. So I’m just like, how do you think you can be better? What could we try? And I think often people are afraid to suggest things in case it’s wrong. And so I like to talk about experiments. What experiments are we going to try to see if this will be better? Let’s experiment with the release train. Let’s experiment with a daily text-based standup. Let’s experiment with the things that we think might improve things and see if they actually work.

Allen: Yeah, I love that because there’s a dynamic that I imagine you’ve probably seen too that I see where we’ll have whatever process retros or debriefs or whatever it is your habit that your team is looking back on some time period and saying, “Okay, what are the things that went well and what are the things that could we do better?” And one of the things that tends to burn people out on some teams with those retros is that there’s certain types of problems that, at least to leadership or some of the senior people on the team, feel like, it’s just part of software. Like, “Oh people don’t respond to my poll request immediately. It takes a non-zero amount of time for my PRs to get reviewed.” And so then people are like, “I think it should be even faster.” And you’ll start to get stereotypically the more senior people on the team will be like, “It’s just kind of a thing. It takes a non-zero amount of time for people to review poll requests. You should probably just stop complaining about it, please.” And so then someone’s bringing something up in a retro that’s a thing that they think could be better. And there’s other people who are saying, “I don’t think it can be better or it’s not worth trying to make better.” And then it discourages them from giving feedback. And so I love that mental model that you have there of experiments as it’s like, “Okay, well yeah. Maybe we might not be able to make it better but maybe we can.” And it seems to me giving that person or org a chance to have more experiments to try to make it better and then see if it fails or not, would give people a little more satisfaction than just a senior person saying, “One day to review a poll request is pretty good. Please stop complaining.”

Cate: Totally. But the other thing I like to foster along with that is get people to agree on the problem because the number one complaint from engineers trying to do any kind of process change is like, “I proposed this thing and people told me ‘no.’” And I’m like the solution is not interesting. You get people to agree on the problem, then the solution will be obvious or boring or someone will come up with something that you haven’t even thought of. But the point where people are at when somebody in that situation is at, it’s like they see some kind of problem on the team, they think it could be better and they propose a solution. And then an argument starts about the solution and then they come back and they’re like, “Why won’t people do this thing? It’s such a good idea.” And I’m like, “Because you had the wrong conversation. These people have not noticed this problem that you’ve noticed. So until you get them on the same page with that, your arguments are pointless.”

Allen: And then if you get them on the same page, then a totally different solution comes out or maybe the same solution. But if a totally different solution comes out, then awesome. Assuming you really are actually caring about this underlying problem and you don’t just have a hobby horse that you wish we could be riding.

Cate: Exactly, exactly. Totally. And then I think it is the value that you are providing is really not the solution that you’re proposing. I don’t care. Nobody cares. What we care about is that this problem is now better than it was before. And so it doesn’t matter if you proposed the solution or you take somebody else’s solution or some kind of mixture of both, the fact that you took the problem and drove it through to resolution, that’s what’s valuable.

Allen: How do you think then of this common advice that you’ll hear, there’s people who will say, “When you’re talking to a manager or a group or whatever, don’t come with problems. Come with solutions. Don’t just come to me and say, ‘Oh, our poll requests are too slow.’ Come in and say, ‘Well how about we consider this or whatever.’” Do you think that that’s flawed advice or is it just incomplete advice?

Cate: I think it’s terrible. But people try to do this to me sometimes. They come to me with some kind of solution and I’m like, “Why do you think this is a good idea?” I didn’t… All the way back to the beginning, they have to explain all of it. But yeah, I think if you are somebody in a leadership position saying that, then you are only going to hear about the problems that people think they can solve.

Allen: Mm-hmm. Yeah, that’s a good way of putting it. And I’ve seen that dynamic before. Do you think that there is value though in this mental model that some organizations try to promote which is encouraging this sort of bottom up thinking where people come, ideally people flagging problems even if they don’t know the solution? The building’s literally on fire. It’s like, “Okay well what are you going to do about it man?” Ideally people are proposing or bringing up problems even if they don’t have a solution. But they’re also trying to encourage people to feel comfortable to make proposals and practice that loop rather than falling into… Or I don’t know. Maybe there are certainly are merits to the top down, sort of come to us with problems and then leadership will help you find solutions. But do you think there is merit to try to build a culture where the solutions are also coming from the bottom up and we’re teaching people at lower and lower levels of the org to be able to think about the whole problem to solution chain?

Cate: Yeah, I just see the solution and the empowerment as distinct things. You come with a problem… You come with a solution but you’re not empowered to implement that solution. Like that wasn’t… What have you done? Most problems in engineering have a pretty standard set of solutions that we deploy. Similarly, just because somebody comes with a problem, doesn’t mean that they don’t feel empowered to develop the solution. And this is where you couldn’t coach people into increasing their impact by helping them think through it. So honestly, if somebody has a solution, that’s fine. I’m not saying you could never come to me with a solution. I’m saying you better have a problem for your solution and I’ll want to hear about it and then my job is to empower that person to get other people bought into that problem and to have team buy into whatever solution emerges. I do think part of what drives that thinking is that people don’t want to listen to complaints.

Allen: It’s not as fun as some of the other things you could be doing.

Cate: I’m natively British so complaining a national pastime. So I just have no problem with people complaining to me. I’m like sometimes the question I ask in one-on-ones is I was like, “If I made you complain about one thing, what would it be?”

Allen: Yeah, it can be hard. I mean for Canadian, our team is mostly Canadian. And so getting people to complain about things is like come on. There has to be… They say you’re not supposed to force people to give you critical feedback but it’s just like, come on, you got to criticize something. It’s like, well maybe occasionally, sometimes every once in a while you talk a little bit more in a meeting than maybe you really have to. But it’s okay because… I’m like, okay, all right. I’ve extracted this undergrade duress.

Cate: Exactly. I think the thing about people who will complain to you, whether you have to make them complain to you or they come and complain, solutionizing is a form of complaining. It’s just a polite form of complaining that’s acceptable in Canada. Someone’s come up with some kind of solution because they think something could be better. That is great energy to harness towards improvement. And the kind of complaining that I really don’t like is when people complain to tear things down. So it’s like you can complain because something’s out of your control or you can complain because you want it to be better but you’re not totally sure how. Those are great. But toxic people just complain to make things worse.

Allen: Yeah. They just want to see the world burn.

Cate: Right? Exactly. Or they believe the world is already burning and that everything would be better if everybody agreed with them.

Allen: Don’t you understand? Nothing can ever be good. Software is always terrible. No process will ever help anything. We should just all stop trying. Why don’t you all understand?

Cate: Exactly. Exactly.

Allen: Speaking of everything is burning. One last thing I wanted to run by you because we have a shared background leading mobile app teams and so I’m legally obligated to ask you about cross-platform technologies because this is the thing that everybody wants to talk to me about. Native development, react native, and how do different technologies compare? So I know you specialize on the native side. Most of the work that I’ve done is on the native side as well, even though we’ve done a bunch of cross-platform stuff. How do you think about that, the opportunity of cross-platform technologies or potentially the menace of cross platform technologies depending on your mindset?

Cate: I just have to find it really hilarious when people bring that topic to me now I’m like, oh, you think we can build a web browser and react native? No. That one can’t be done. Yeah. So I guess let’s talk about DuckDuckGo specifically and then more broadly. So we work in this problem space where we build these privacy preserving browsers. And one of the core decisions that we’ve made is we use the web view component that’s available on the platform. And this is in fact completely distinct on each of the platforms. There’s… Even, I think, between Mac OS and iOS, it’s not technically the same but I think it’s close enough that we manage to share a lot of codes. But Android versus iOS totally different. And so that means that we have two places where we can share code. So we can share code at the very top of the stack. So we can inject in JavaScript and we can share code at the very bottom of the stack. So we can have something that’s like in C++ with no dependencies. But anything in the middle is actually just really hard to share because the web view component works differently. And actually the complexity is not really in the code. It’s in the problem, the testing, the edge cases, the breakage and all the rest of it which I think to take more broadly is sharing code works where the value compared to the overhead is worth it.

Allen: Yeah, I mean that’s the fundamental discussion and debate that I think that happens on every… It’s especially difficult on medium sized teams. Really small teams often it’s obvious. They either just go the technology they already know or they’re so small that there’s only one approach that could work. And then really, really large teams, often they have the budget that’s like, well, we can go native and it has a bunch of advantages for our problem space. Or maybe it’s obvious to them. Maybe they’re large enough like, oh, we’re going to just build our own custom cross platform framework or whatever it is. If you have a hundred thousand people in your company, you can just kind of do whatever you want. But in the medium size teams, often you have the debate about exactly what you said. What is the point where the trade off is worth it? And there’s a bunch of factors that go into that. I mean, I find your argument about why for DuckDuckGo, it’s not very compelling, I find that compelling. I’m a little biased towards that. I do often do like the native solutions for things. I think it’s an interesting thing to build in our minds as people who do sometimes need to think about these tools is what are the trade-offs and the times where any given tool whether it’s crossed platform tools or something else, gives us a big win to help us understand are we in that state as opposed to the thing that a lot of people want to have the conversation is like, no, no, no but what’s the right way to build all apps? Is everything going to… Is native going to die and everything’s going to become cross platform? Is cross platform going to crash and burn and everything’s going to become native again? What’s going to win? I don’t know. I find the idea of those trade-offs or when are the big wins for one or the other a lot more interesting.

Cate: No, I totally agree with you. I don’t think either’s going to win or die. Right? It depends, to your point exactly, on your circumstance. We actually put React Native in the WordPress apps. And this was a huge argument for a long time. And I remember somebody was like, “Oh, if you have React Native and this menu changes, then you don’t need to rebuild it.” And I’m like, we don’t need to rebuild it if it’s the menu’s configured on the server and we download it. Building a table view is just really not the big problem that we’re having. Or the ordering of that table view especially, it’s not the big problem we’re having. But when it came to the new block-based editor, then the decision became more worth it because the complexity was so high. But the cost was also huge. And I think this is one of the things that drives native teams nuts from web developers is they’re like, it’s like they think the component was the work, right? But actually getting that component in and working and the overhead of having it on your build system and all the rest of it, that’s a lot of work. Building a table view or a list view on advert, this is just not hard. It is not hard. You don’t gain anything by importing your table view from React Native, adding 10 minutes to your build time every time, and then dealing with a breakage every month. That is a net loss.

Allen: I’ve heard people pitch using React Native just for a setting screen because they’re like, “Well, it’s not going to be as polished but then it’s the same across both platforms. And then when we add an item to this table view, then we won’t have to do it on both and they’ll be consistent.” And it’s like, what a huge sledgehammer to fix the easiest problem in your entire project.

Cate: Exactly. Exactly. But we have some shared C++ code, for example, and it’s a blue filter. That thing is… The code is very stable but it’s very complicated. You don’t want to deal with it going wrong and the overhead that it adds to the build is totally worth it. The JavaScript stuff, I think… And I mean this is one of the things that becomes the chicken and the egg is we add a bit of JavaScript, adds a bunch of hassle, and we’re like, “Oh, did we really get anything yet?” And so it wasn’t until we’d added quite a little bit of it that’s like, okay, finally we’re actually getting enough value from this. But the ongoing cost of handling it is much higher than I think the people who push for these cross platform or hybrid solutions tend to acknowledge.

Allen: I heard on the internet that it’s half the cost if it’s cross platform because you don’t have to write it twice. It’s just half, right? Isn’t it just that simple?

Cate: Exactly. But then the other thing is when it breaks, you end up debugging at one level of indirection.

Allen: No, you’re not supposed to talk about that. It’s half the cost. You just write it once and then it just works. Bugs only happen on one platform. I have… Love this conversation. I feel like we could probably talk for another hour. So I want to really thank you for making the time. How do people find out more about your work and how do people find you on the internet?

Cate: Cate.blog.

Allen: Cate.blog. That’s Cate with a C and a wonderful domain name. Thanks for making the time. It Shipped That Way is brought to you by Steamclock software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. And that’s it for today. You can give us feedback or rate the show by going to ItShipped.FM or at It Shipped FM on Twitter if Twitter still exists when this episode comes out. Until next time, keep shipping.