Design Better · Product & Design · October 2026
Asked what makes smaller design teams stronger than bigger ones, Hunt starts with lower communication overhead and the ease of holding a shared understanding. Once a team scales up, he says, you have to do a lot of work around the work just to tell people what the work is.
really struggle to answer this because the first part of your statement is something that I've done very intentionally. I've sought out opportunities that felt like they would be good conditions under which to do good work. I've been very intentional in kind of my evaluation and like what I choose to invest in. And also the things that I say no to or don't engage with those conditions, you're like, oh, you've been very lucky. I mean, I do feel very lucky and fortunate. But what that means is I haven't really stepped into something where I'm either surprised that design is undervalued or appreciated. Like I usually have a pretty clear eyes on what I'm going into, or where it isn't and I had to really wrestle with it. Now, what's interesting is maybe grab as an example was a little different. It really wanted design. It definitely needed it. It was willing to fund it. But I don't think that organizationally it knew what it meant to value it or put it to work well. You know, it's an interesting thing to be like, oh, we've allocated budget. We've got a plan. I think this is important. And it's another to almost like metabolize that. Yeah. You're like, I'll take the food, but am I like taking the nutrients? So maybe that gets closer to your question. I think that working examples of things and strong partnerships speak better than anything else than trying to have some compelling story or pitch or like shape their perception through communication means. I'd rather like shape it through the visceral reaction to something being very good. And I think those things are either successful case studies or working partnerships and relationships that are like really valuable. So you end up getting people to speak on your behalf. Rather than saying like, hey, we need design to do this thing. Do you have someone else who's trusted, influential? It says, hey, I've been working closely with Brandy and his team and it's working this way and it's good. We should do more of that. I would look for opportunities to create that kind of momentum or those kind of relationships like ground up more so than to try to like deliver it from the top or something. What
makes smaller teams stronger than bigger teams? I
think number one is lower communication overhead. So much gets lost in translation and trying to traverse just the layers of an organization, even if everyone's great. It's just the mechanics of it that make that challenging. But then there's a bunch of other stuff that comes in. You know, every person has another set of interests and motivations and challenges and conflicts and things. The other is I think it's easier to hold shared understanding. You can do more of the work itself rather than the work around the work. Once you start to get to like sort of scaled up things, you got to do a lot of work around the work to even tell people what the work is. We have extremely talented people. I have found that they have low tolerance and low patience for bullshit for the work around the work. We should just say the thing, agree on the thing and do the thing, go. When you start to get more people, working that way is harder. Not only people on a design team, you know, cross-functional and things like that. It's good to have those small team experience and then be like, okay, how do we protect this energy, even if we do need to grow or have bigger teams or whatever. But I definitely have a preference for small over big after doing many permutations of both. I
think you maybe used the word talent density to describe that. How do you hire for that or set up the right conditions for hiring for that kind of talent density? I
mean, one is about clarity of intent and being really clear about that, meaning this team will be smaller than one might expect by historical reference points or outside reference. That is intentional. And that works. There's the bad version of this, which is the team's too small, doesn't have enough bandwidth. They get pushed to kind of the delivery end of a timeline of a project workflow. And you end up in this production engine mode. And that's kind of like a fail state. The other version, I think the better version, this is very much like the notion version. They say actually the constrained bandwidth is a forcing function for prioritization. And therefore, the talent dense team, in this case, like talent dense design team in particular, has a, relative to many other things, an outsized influence on what we do by virtue of being the scarce resource that has critical participation both at the beginning and throughout the making of things. We can only chip as many things as designers can deeply participate in. You know, there's just a natural tendency to want to have more and entropy and all the noise. But back to the other point we talked about, talent dense reinforces the other aspects of the small team mechanics. So you kind of got to get the flywheel going in that direction. And then I think it works. This plays then into like hiring and talent and stuff as well, because the people with a similar mindset see that and they're like, yes, please. So again, the flywheel kind of moves in that direction. Put it in contrast. You know, there's another version of building and growing a team that almost looks like it's education. It's almost. like this is a uplifting talent development bring less experienced youthful energy early career often in larger numbers up and you have mentoring education career progress etc by design and that can be done well you can have like a hierarchy that you could imagine the shape of can totally work and i think we've seen very successful organizations do good jobs of that enough nice legacies but what happens then is there's a lot of work around the work to make that work well you know so there's your real like trade-offs there and when you kind of assume that your team operates in a way without needing those things in the same explicit way look you're not going to come here and get some like training and career path this is not about what level will you get to we don't talk about like titles or levels internally on this team you're here to be on the team and like make stuff happen we want to compensate you fairly for doing that when we do great work we're all going to win together like let's go this is about building stuff you know i think you can really like sell that idea and that vision and then do it i mean that's the other important part is you're like the other conditions around the team work such that that's true meaning like the product organization at notion the engineering organization have been around this approach to doing the design practice and are for the most part very willing collaborators and accepting of that approach if you were to have this isolated only in like a pocket of the organization then try to interface with other people it becomes very frictionful because it's not the default way you know it's not entirely unique to notion but i wouldn't argue that it's somewhat rare the idea of talent density is like no you know people latch on to these terms and circulate them around i'm sure you can find you know 50 job descriptions today for some role that's open and they would say we're a talent dense team which i think they just mean they want to have people who are good and the team small you know but i just described a bunch of other stuff about those conditions that make it properly dense
when you have a talented small very capable team like that that's empowered what are the top reasons why people leave