# Duplication, ownership, and 'not owning' as a feature

- **Episode:** [189](https://agents.truthliesandwork.com/episodes/189.md) (2025-04-17)
- **Type:** interview
- **Tags:** ownership, duplication, organizational-design
- **Time:** 13:25–26:15 (start 805s)
- **Listen:** [https://truthliesandwork.com/189?t=805](https://truthliesandwork.com/189?t=805)

---

[13:25] Al Elliott: As in Roman Empire?
[13:26] James Hawkins: Uh, this is 15th century. Um, but it was sort of how come all these like tiny little European countries dominate the entire world, even though they're so small? Like, they don't have as many resources and stuff. And the book's kind of making the argument that there's chaos in Europe where people, you know, there's always like warring going on and it leads to someone inventing the Like gunpowder, and then suddenly you have this massive advantage. And now one small country can have an empire that spans the world kind of thing. So having a little bit of chaos in an appropriate dose can lead to a greater outcome than the grandiose vision you have in your head as a founder. Because I'm not like Steve Jobs or something
[14:04] Al Elliott: You've already said Apple wouldn't, that your way wouldn't work necessarily at Apple when they have to be pixel perfect, when they're just, they're obsessed by design and stuff. But let's talk about something like, let's say Buffer. So you, you are something like Buffer where you've got one product. Would you, if you were in charge of that, do you, would you still break out into small teams? Even you would?
[14:24] James Hawkins: Yeah, I would split the product conceptually into different like use cases, for example, or I still think you can get much greater productivity if you're able to pull off small teams versus having like an engineering org of like 100 people or something. And then like a bunch of product managers in a different Silo. But the way I'd approach that if I were Buffer would be like, okay, we'll have a team who focus on like the activation flow into the product, for example, like a growth team. I would have a team working on like maybe like the editing experience. I have another team that work on like API connections to systems that it publishes to. So I would probably try, I would work pretty hard, I think, to try and consider each of these things semi-separately
[15:00] Al Elliott: Yeah
[15:00] James Hawkins: Because I'd also argue that I don't think Buffer is a product that anyone uses because of its slick design. Like it basically just lets you post content across lots of different places pretty easily. But it's not like, oh, it's like the inspiring aesthetic beauty of its UX is the reason I adopted it. I would advocate for that because I think what you'd end up with is cool. Now you've got 2 or 3 people working on something rather than 100 people kind of like probably doing the same thing. I think there's just this effect in engineering where it's like the first few people working on an idea, could go so much further. Like, it's so ridiculously disproportionately far compared to like the 50th, the 51st person, the 100th person you add to a team that, because of accountability, basically, and freedom and not having to get committees and stuff. So yeah, I would still advocate for breaking what might look like a single product company into multiple products so that you can have better ownership everywhere from your engineering team
[15:55] Al Elliott: You just mentioned duplication there. Now, this, I think, would be one of my biggest problems is I've got, let's say that I've got 6 teams, each between 2 and 6 people in it, and they're all working on different, either different contexts of one product or different products. I'd be worried about 2 things. First of all, are they working on the same problem and are we wasting resources? And secondly, even if they are, how are they sharing the knowledge between the teams?
[16:21] James Hawkins: I think there's actually 2 distinct problems there. I think on the, Duplicate effort is one of the downside risks. But I think it's kind of like saying, oh, if I buy a Porsche, there's no point because a bird might poo on it, for example. Where it's like, well, just wipe it off and keep going. Overall, you have a Porsche. And it feels a little bit like that to me. Okay, cool. Let's take 10 steps forward and then one to the side and one backwards by accident. But net, we're probably up 9 steps compared to where we would've been had we still been doing the pre-meeting for the pre-meeting for the meeting to plan the thing. I think that it is one of the potential downsides. I would argue it works, is less likely to occur, I think, in a remote organization where there's a written culture. Like, we're very transparent and people can just see what every single team is working on. And so that's like one way that information bubbles around as we're getting bigger. Like, we have about 27 teams, I think, at the moment, something like that. There is now a ton of, there's like so much written stuff happening every day that There's probably a little bit too much to keep on top of. I think the second, but there are a couple of other places. So for example, in our all hands, because we prioritize like velocity and shipping basically, and because it's the primary thing we're good at and winning on, we do like a demo section every single all hands to make a point of like, hey, show off what you worked on last week. So there's just like a couple of little bits like that that can just bubble to the surface, bigger projects that are going on. Um, so people do generally catch this stuff. Like, it's been really unusual. There's only been like a couple of times where we've sort of built the same thing twice, but it's been so, such a small problem. It's just not been a huge deal basically. Or like a worst case, maybe like, and I think as again, if you're like a team lead or you're in the exec team, like you should also be keeping an eye out for this kind of stuff. Like a lot of the interaction I'll have with teams, um, is like, oh, just so you know, like this other team is working on something kind of similar. Like maybe just go talk to them
[18:10] Al Elliott: Yeah
[18:11] James Hawkins: And figure out if maybe one or the other of you should build it, but not both of you, or if you want to pair on it for a bit or whatever. On the second, on your second question or the second point, I think you're making around like, what if like one team learns something, how do you spread? Um, uh, this is something we're still trying to get better at. I think there's been 2 areas that we're discovering for this. One has been infrastructure. We have a platform team for infrastructure. Um, and very recently and very topically, like AI stuff is its own beast in terms of how it gets built. And like, you know, I would imagine pretty much every company in software at least is building with AI. And we've got kind of one, we now have a kind of a platform AI team and they have much deeper expertise on how to build things with AI, what's kind of possible and what the infra should look like, how to build it and so on. If any of the other teams want to build AI-based functionality, like, hey, I want to build like natural language to a chart of a data visualization, one of the AI people will move to the, will go to like live in the product analytics team for a sprint, 3 sprints, whatever. And they will pair with one of that team so that the other team is owning the functionality still, but they've been able to like piggyback on the expertise of an AI-oriented engineer. The point being that when the AI person then goes back to their home base, maybe in like a month or 2 months or 2 weeks, whatever it is, The team are left still able to run kind of independently because there's not maybe like a permanent need for like an AI specialist in a product team. If you actually have an expert come in and do it with them over the course of like 2 weeks or 4 weeks, you might be able to save yourself 6 months of engineering work going in the wrong direction or whatever. So being quite willing in the platform teams to like send, if it is kind of a more of a platform type thing, using people to like hop into another team temporarily can work quite well. So we will very frequently move, we'll move people around these teams. to reflect the nature of the work that needs to happen, but we will aim to distribute the knowledge of a platform team out into these teams through this kind of missionary approach. So that's what we've— I don't think we've totally nailed this. Like, this is kind of where we've gotten to after like a few years doing this. I still don't think it's perfect, but that kind of approach seems to be the right way. We do a couple other bits. Like, we have a brown bag session once every 2 weeks for our engineers. It's totally optional, where an engineer will just talk about something they've learned. Like, I've been working on scalability. Here's all the stuff I've learned. Um, uh, this is very kind of freeform. So those are the kind of 2 ways that we've approached this so far
[20:59] Al Elliott: We both use behavioral science to help people do better at work
[21:08] Al Elliott: And you're not going to say which. Fel, host of Nudge, UK's number 1 marketing podcast. It's brought to you— we need to do this in 3s—
[21:22] midroll (Phil Agnew, Nudge): Seamless
[21:23] Al Elliott: Seamless. Tell us about your latest episode, Phil
[21:45] Al Elliott: It is
[22:00] midroll (Phil Agnew, Nudge): It can
[22:04] midroll (Phil Agnew, Nudge): I am
[22:08] Leanne Elliott: But come back
[22:09] Al Elliott: Yeah, come back
[22:09] midroll (Phil Agnew, Nudge): Definitely come back because Nudge isn't as good as this. So come back
[22:12] Al Elliott: I'll cut that out
[22:14] James Hawkins: Keep that in
[22:18] Leanne Elliott: Welcome back. Let's get straight back into it
[22:20] Al Elliott: Well, so we've got here now, what I like about this is that you're sort of clearly outlining that you've got small teams, they have ownership, uh, you have secondments between teams
[22:29] James Hawkins: Yeah
[22:29] Al Elliott: Um, I think the question I would be having as a manager, I'm going to come on to managers in a second, as a manager or an owner of this company, we'd be like, well, is there going to be some friction if someone is seconded from one team to another? Is Does that, is that different for developers or engineers?
[22:46] James Hawkins: I think this would be very easy to get wrong if you want to move people around frequently. Um, because it, and also when you're forming, like we're scaling quite fast. Like I think this year we're, um, uh, going to go from, I think about 80 people to 190 people, something like that. And I think the, um, so really, really often, like every week, I would say a team is getting split. in half to form 2 teams, for example. And then each team has a team lead. So you could argue it could be pretty contentious because like, oh, who's the boss of the new team? Like, how come it's not me, for example? And so we have just embraced, my co-founder's Dutch, and we've just embraced like full Dutch directness on this stuff. So I think traditionally, if you're like moving people around or you're like splitting teams up or forming new teams, I think the very conventional way to do this is you kind of like, as an exec, you've created the idea already. You already know it's going to happen. And then you basically do politics. You convince every— you use one-on-ones to convince everyone this is a good idea. Then you make the change. So there are no surprises. Uh, and, but then you look back and you're like, I've basically just spent like 7 hours making this change. Um, and it's taken me a week and a half and it's creating effectively a culture of politics, I would argue. Um, like convincing people of an idea that I already know is going to happen. So, um, the way we do this is in Slack, we will put a slightly over-the-top message with like a bunch of like warning bells and axe emojis and just be like, I'm proposing that we split this team in half. And I think this person should be the new boss of the new team. Um, and they should take this person, this person with them. Um, this is a zero context, no warning note. Um, if anyone has any feedback or disagrees with this change, let me know. Otherwise, let's make this change today. And then we just make the change and no one ever objects to it. It's been super, it just feels much more honest and direct. And this is now happening so much, it's kind of no longer a big deal anymore. But yeah, the first time we did it, it felt kind of brave, but now I'm like, wow, this just means it takes like 10 minutes to make a team change. And we don't pay, the other thing is we don't pay managers differently to people doing individual work. work and we almost downplay, I would say we almost have a culture of making fun of management, but like kind of, we really downplay the role of manager and we try and centralize a lot of traditional management work. So we don't kind of, like a lot of the time, actually one of the biggest challenges is not everyone fighting to be the manager, it's people fighting to not be the manager, which is great from our perspective. Again, the kind of people we like hiring as managers, we can go into this if you like, is people that kind of reluctant managers, I often think are the best kind, at least in engineering, in small engineering-oriented teams, probably with very direct. totally transparent about these changes. And we make them kind of when we actually want to make them versus trying to get buy-in. We just don't try and get buy-in from the organization culturally. We've just gone, hey, we're going to make loads of changes. We can spend loads of time convincing everyone they're a good idea, or we can just ask for, in the same way that I would trust a small team to ship whatever they want, I'm asking the small team to trust that when we make team changes, we have thought about this quite hard. And you have, like, tell us if you think they're dumb. But almost invariably, because there's quite a lot of philosophy around when we'll have small teams, like, hey, if we've got 2 products in a team, that should be 2 teams. Or if the team's getting past 6 people, that should be 2 teams. Because people are kind of bought in already to the handbook and the philosophy that we have, it's been really smooth to make these changes much quicker. And it just feels kind of funny compared to, it feels a little bit cult-like, I think, compared to like how a normal company would approach this stuff