• Dennis on Twitter
• Get Unblocked

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, and today’s interview is with Dennis Pilarinos. Dennis is founder and CEO of Unblocked, and was previously founder and CEO of Buddybuild, has also been a director at Apple, Amazon, and Microsoft. Welcome, Dennis.

Dennis: Thanks so much. Thanks so much for having me, Allen. I’m looking forward to it.

Allen: I’ve been excited to have you on the show since it started. You’ve been on my list of people because we have such great conversations about teams, cultures, products, all the things that the show is about. And I am very confident we will run out of time and still have more fun stuff to talk about.

Dennis: We’ll see.

Allen: And so today I want to try to focus our conversation on a lot of things you’ve learned a lot about, engineering, culture, leadership and products. And you have really, in my mind, a really unique perspective, having built multiple startups, Buddybuild and now Unblocked, but also worked at some very, very large companies, the top tier in terms of size of tech companies. And so you have this broad set of context that a lot of people don’t have. People often grow up in their careers with just one lens that they can talk about, culture and teams and all that kind of stuff. So I’d love to dig into that. But first, how do you like to summarize your story up to the point where you founded Buddybuild? And then we’ll take the story from there.

Dennis: Sure. So grew up in the Vancouver area, went to school at Simon Fraser University and did two degrees, one in computer science, one in business. I’m a self-described… well, most people would describe me as impatient, and I’m very, very self-aware enough to recognize that I’m a very mediocre developer. And so when I tried to build software, I always felt it frustrating. I’m like, “Why does it have to be this hard?” And so I went into building developer tools, I think, with that predisposition and that mindset. And so when I was at Microsoft, I worked on the client side libraries, the .NET Framework for a while. And then I thought there was going to be transition to this cloud-based type computing, and so spearheaded the effort of one of the earliest people to think about building a developer API in the cloud. And that became Azure. So we went from a direct connect internet with a machine, I think it was an HP Compact machine, and a handful of early adopters who we were under some other code name, all the way to geographically distributed data centers around the world. And that became Azure. To give you a sense for how long ago that was, that was when this book selling company called Amazon started a beta of the services called S3 and EC2, so it was a while ago. They just launched the betas. We just kicked off this project. So I spent a lot of time thinking about developer tools there. One of the things that I think I learned very early in my career is you really have to optimize for the people that you work with. And so a lot of the folks that I worked with had left Microsoft and gone to other opportunities. And so my time came. I actually moved to San Francisco for a year, was recruited by AWS to start the office here in Vancouver. So did that and had obviously some experience with cloud and I had a passion for mobile and web. And so they asked me to build the Silk web browser that ships both now… the original intent was for the Fire phone, which lasted for about, I don’t know, 27 days or something. And then for the Kindle Fire devices as well. So it’s a cloud-powered web browser, and that’s what got me up into Buddybuild.

Allen: Awesome. And I like that idea of you have to optimize for the people who you work with, which when you first said that, I thought you meant you have to contort yourself to deal with the people who are around who you’re working with, but you meant the other way around. Find people who you want to work with and find a way to work with great people, which…

Dennis: Yeah, yeah.

Allen: I feel that a hundred percent. Founded Buddybuild, which I was very lucky to have some of the early experiences with that product. It solved a problem that we had as a mobile development team getting builds of our apps onto people’s phones and even our own phones and running CI and all of that stuff just sucked and tended to really get not prioritized on teams like ours, especially at that time. You came in and you founded this business, Buddybuild, from idea to group success to huge growth to acquisition in three year pace, which I guess fits with your self-description as impatient.

Dennis: That’s true.

Allen: It was not a, “Oh, let’s plant a seed.” And then a decade later it’s like, “Oh yeah, we’re starting to get some growth now.” It’s just like, “Let’s go.” Which is well suited I think, to something that’s building for mobile in the early, heady, rapid growth days of that space. But so let’s dig in a little bit into that process of you building that business and then how that’s reflected in on how now you’re building Unblocked, which is relatively recently launched. At a product and engineering level, do you have any kind of framing or mental model you use for a playbook? Some people are very organized and say, “Well, this is my playbook. I think here are the three things about when I’m building a business,” or is it very organic? I know you’re a very product and people oriented person. Is it organic to the problem at hand?

Dennis: I think it’s a super good question. I think so certainly for Buddybuild, it’s a business that we founded as a consequence of our own experience. And so we’d wrapped up this time at Amazon and wanted to get reacclimated with the iOS ecosystem, and I was building a very simple application with a couple of friends, and the application, I just wanted to be able to push a commit, have it build, get deployed to my device. And it was insanely difficult to get that to happen. And so when I talked to a bunch of friends through how they did that, they’re like, “No, no, this is the status quo. This is the way it should work.” And I was like, “That’s crazy to me.” And so I guess that’s that intolerance for mediocrity or this pain that you have to feel as a developer. I was like, “Why does it have to be so hard to do this?” And it’s easy to look back and say, “Obviously we needed a mobile optimized CI solution.” But when we started the company, it had a similar vision to that and we weren’t clear which part of the overall vision would really resonate with people. So it really did get anchored with CI because that was probably the most acute pain point for most teams, and then obviously automating the deployment process as well, making that super simple. So what’s our playbook? I mean, I think from its inception, the playbook is what really sucks? Why is this so hard? And is it because I’m doing it wrong? Because that happens all the time and there is actually an optimized better way of doing things. Or is there something that’s actually systemically broken? Should there be a solution in this space? And so that’s the very first part of the… I don’t know. I don’t know if I have a formal playbook that I could open up and publish or what-have-you. But I think the first thing is I feel it’s really important if you can viscerally feel the frustration of the inefficiencies, I think is the way it is. One of our co-workers, he didn’t work with us at Buddybuild. He’s at Unblocked. He’s one of the only people who hasn’t worked with us at Buddybuild. And so him and I had worked together a long, long time ago and he said to me one of the things that he observed is that I actually feel frustrated and irritated by the software that we build. It actually physically manifests itself and I get frustrated, and that’s how we learn to rough off rough edges or explore new directions or things of that nature. So I think feeling it is probably one of the most important things, I would say, from my experience.

Allen: And that makes a lot of sense and that comes through in the software. Something that you mentioned, which I’m interested to dig into a little, is you are looking, and I think a lot of people in our audience are looking at potential product areas to explore, whether it’s part of a large company or they’re founding something or whatever it is. And often a question comes up when you say, “Okay, the status quo sucks.” And if you are a product minded person, you’re probably hopefully have some skill at looking at an experience and seeing, “Okay, there’s some bad things about this experience, it’s not as good as I imagine it could be.” But often when you start digging into something and you do interviews, you talk to customers, you build an understanding of how other products in that space operate, you start to realize the systemic problems, you can call those. Like, “Oh, is this systemically broken?” And I had evaluated the product space that Buddybuild was in, and I think some people might evaluate the same way with some of the problems that you’re now facing building Unblocked, that there’s inherently difficult things about it. So in the case of Buddybuild, it’s like, “Well, part of why our tool chains sucks for this is because Xcode is constantly changing. It’s constantly breaking and Apple doesn’t really have APIs for a bunch of stuff, and Apple maybe doesn’t even want you doing these things. And a new Xcode version could just break something subtly that no one would even understand. There’s no real error message for it.” And I saw that… especially I think seeing this story has reframed the way I think about this kind of problem a lot, but at that time I told you infamously, “Oh, Dennis, this is too hard. You don’t want to build this. Xcode could just break your stuff. It’s going to be really unpleasant. You’re going to have a bad time. You don’t want to build this.” And instead of being discouraged, I saw you get energized by that. So how do you think about building things with a systemically or fundamentally difficult aspect to them? Is that something that you seek out or is this like, “Well, I’m on this mission and if it’s hard then it’s just going to be hard, and if it was easy then great,” or how do you think about that?

Dennis: Yeah. I’m flattered. I actually remember that conversation that we had was at a Starbucks on Water Street in Vancouver, and I was in awe that I get to have some opportunity to spend time with you. You’re a prolific person in the community. And so I was really flattered to be like, “Hey, we’re thinking about building this thing.” And your feedback was like, “Oh, I don’t know, this seems pretty hard.” And I was like, “You’re right.” I was energized by it. I do get energized by problems that are hard. I think all the easy problems have been solved. So when I think of a hard problem, it was like, “Great. When we solve this, what that does is becomes inherently a moat.” And so some problems are hard because they require a lot of patience or they require a lot of manpower. Some problems are hard because they just require a certain kind of insight or technological breakthrough, what-have-you. Most problems are a combination of both, is what it comes down to. And so for Buddybuild, I don’t know, maybe it’s oversimplifying it, but to me I’m like, “It’s just software. There should be a way to do it. There’s very few things that are actually impossible. It’s just a matter of time.” And so I don’t know, I’m just very… I guess I get focused on thinking about it that way. I’m just like, “Yeah, whatever, it’ll be hard. We’ll figure it out and we’ll move on.”

Allen: Here’s a story I tell myself, and you tell me how true this is. But that pairs well though with something that I saw with Buddybuild, and I assume you’re doing the same thing with Unblocked, is as you’re building the product, especially in the early stages, a very high willingness to talk to customers in a support context. So when I was an early user of Buddybuild and it’s like, “Oh, Xcode randomly barfing on whatever, some error app bundle, something something,” I would text you or email you and I’d be like, “Hey, there’s this thing.” And you’d be like, “Oh, well put it into the intercom chat.” And I was like, “Oh yeah, the little chat bubble in the corner that every web app has, but that if you actually try to interact with it, it wastes your time?” You’re like, “No, no, no. Interact with it.” And so I would and I would get a real human, not just any human, not a support human in some other time zone, but one of the developers who actually knows what Xcode is and can check if the new version just came out yesterday. And sure enough, it did. And sure enough, that caused the problem. And so it trained me as an early customer to when you are hitting up against the edges of the fundamentally hard problems, communicate with your product team in a loop to give them that feedback of, “Hey, it’s working or it’s not working, or here are the edges of it.” And then for me as a customer, if it had been a fully automated… you say it’s just software, but it was very much, at least at that time, software and humans. If it was just software and it errored out and then there’s not really much you can do about it other than try to troubleshoot some remote system that has a Mac Mini running Xcode that you don’t even understand how it’s configured, we would just give it up on it. But do you see that as a fundamental strategy, or again, is that one of those, “We just kind of ended up doing that?” Was it incidental or fundamental I guess is my question?

Dennis: No, it’s fundamental. I think that’s actually super important. Even in the very last days of Buddybuild, I would still get up quite early in the morning and spend probably an hour, hour and a half on the front lines doing intercom support, answering emails, getting into our discussion forums or what-have-you. I think it’s just fundamentally important. At the very beginning of these projects, basically you’re testing a thesis. You’re like, “I have this problem. I have an experiment that I want to run.” And I think your opinion for how you should solve that problem is the software that you build. And so opinions are all nice and wonderful, but that’s within your view or perspective of the world. When you go and show it to someone and then they tell you, “Yeah, that works except for X, Y and Z things,” then there becomes a little bit of the art and science can mix together where you have to figure out which those things are important. But if you don’t actually talk to people and have the thick skin to be able to take some of the sometimes painful feedback, then you’re not really improving. Really in the essence, the experiment has failed and because that’s not working for that person and you’re not willing to adjust it to accommodate for its success. Now you can say, “Well, I’m happy with the experiment failing because that’s actually not the right person I want to build it for.” But if you accept that that is the right customer profile, then you need to take that feedback and iterate on it. Layers of people or layers of systems or what-have-you between that feedback and the people who build the software I think is basically your first step to building software that lacks any kind of empathy. We’ll see how Unblocked does what-have-you, but in my wildest aspirations, it helps people in a material way and I’m still doing tech support. I still do it today. I answer almost every single question that comes through intercom or a LinkedIn message or what-have-you, and I’ll reply to all of them.

Allen: Yeah, I love that. That’s one of those things that I’ve talked to a lot of people who have a mental model like, “Hey, you’re a founder and you have to be solely focused. And so you got to make sure there aren’t distractions and there aren’t interruptions and you have to make sure you have a support team. Okay, we have a product, let’s hire customer support people.” And the default mental model, and maybe this is just me being a bit out of date and maybe this is a better known thing that I could have learned from talking to more founders or something, but I definitely have gotten the sense that there’s a bit of a default mindset of like, “Oh, you want to send those tickets all off into a ticketing system as opposed to get this to the senior product people in real time.”

Dennis: I can’t remember. It was in university or at some point I read an article where, and I don’t know if they still do it or not, but Nordstrom executives have to spend some non-trivial amount of time selling shoes on the floor. They are actually people… you really have to appreciate every aspect of the business. I’ve always respected, I think, leaders who…. it’s not scalable for if you’re running a 1,000 or 5,000 or 10,000 person company for you to necessarily spend a huge amount of time doing customer support across all of these product lines, so on and so forth. But you better be talking to people who are actually buying the stuff that certainly you care about because otherwise, I don’t know how you rationalize or how you reconcile what your thesis is with reality, and so you’re not really solving any problem at that point.

Allen: Yeah, that’s interesting. So how do you reconcile the pressures… or maybe this is just a fundamental discipline of a founder thing. How do you reconcile the pressures that having these inbound support requests coming and put on you and your team mentally when they come from… as you kind of hinted at, sometimes they come from people that aren’t really ever going to be customers that you’re going to financially benefit from serving?

Dennis: Yeah, so I think there’s two parts of that question. One is, is there a financial payoff to that investment that you’re going to make? And the other is, is this actually the right person whatsoever? For Buddybuild, in the very early stage, we were actually talking to UX designers and product managers to be like, “Hey, look, we have this easy way to get a build onto your phone and then you could take a screenshot and circle the area and provide some feedback to the engineering team.” And so over time we realized that that wasn’t an acute pain point, and so we stopped talking to those people and when they would come into the door to be like, “Hey, I’m a product manager who’s thinking about that scenario,” we didn’t spend a lot of time with that. We would support them or what-have-you, but that’s not the people that we knew that we could solve the biggest pain point for. So how do we do this now in Unblocked? We’re still very early on and we’re still narrowing in exactly who that person is. I think the real tension comes understanding if this person’s going to be able to contribute financially to the success of the company at some point, is going to be a paying customer, that’s one interesting thing. The other thing is to what degree do you take the feedback that they provided to you and prioritize it relative to the other things on the road map? Is this something that you drop everything for and immediately go and help them? How do you accurately assess, is this a problem specifically for Allen, or is it for Allen and Dennis and 3,000 other people?

Allen: Yeah. Related to that thread in terms of taking in product… and the reason I’m asking you about this, this is something I’ve seen you do really well, so I feel like… I like learning about how you think about it and I think it’s useful to other people. How do you think about going in when you’re trying to get feedback on a product? So you give a demo, you’re showing somebody something, either they’re driving or ideally they’re driving or maybe you’re driving, but ideally they’re exploring this product and I’ve seen you what I would label as expertly steer me to give you very honest, clear feedback, which is something that I’ve seen a lot of people fail at. Is there any kind of mental models or tricks or habits you use to try and get that honesty and rawness from people when you’re trying to get product feedback?

Dennis: I don’t know that it’s anything that I do deliberately. There’s no meta conversation I’m having to be like, “Okay, I’m going to ask these questions and Allen will be honest with me.” I don’t know if there’s a deliberate thing. I think it’s just I am quite earnest. I think about it very pragmatically. It is, “Here’s what we think it’s solving.” Most developers tend to have pretty strong opinions, and so I’d be like, “Does this solve the problem for you?” It’s like, “No, you didn’t think about X, Y and Z things.” And so I think maybe as a consequence of the nature of the problem space, we tend to get pretty direct feedback, but I don’t know that I’m consciously aware of it. Hopefully, my goal is to be empathetic and come across in earnest, very curious about if this thing would actually work for you. And if it does, great, but I’m genuinely more interested if it doesn’t. I am hyper focused on the critical feedback or the things where we’re deficient. If it’s working, I’m like, “Oh, great, great, that part of the experiment works fine, fine. Let’s go figure out why it doesn’t work over here.”

Allen: Yeah, that makes sense and that’s an interesting… I love that explanation even though it may be slightly less useful as like, “Oh, here’s the trick I use,” but what it points to is if being and adopting wholly, being fundamentally curious and inquisitive about the deficiencies and the problems in your product, which you’re wired naturally for, I think my weakness that I think I’ve been growing out of over the years is that I’m wired to want to polish everything and make everything perfect. And I think I grew up with a little bit too much pride in the software I would make, which had some good outcomes that I would make these really nice things, but then of course I would want something and then you can make a really beautiful thing nobody pays for and that helps nobody and you really accomplish nothing and you’re not a business anymore. And so that’s something that I think I saw in you when you would seek feedback from the products, but it contrasts to a lot of the other… I’ve talked to a lot of startups over the years trying to ask me for feedback and often I guess I got the sense that not everybody really wants to hear how bad it is and where the real pain points are. They’re going into those conversations probably unconsciously looking for validation, and you go into this conversations looking for me to poke holes in and criticize.

Dennis: Yeah, you’re actually particularly good at it. Every time I prepare… I have relatively thick skin, but I have to put on another layer when I send it to you. But I appreciate it because if I can get to that level of polish, I know it’s quite commendable. It is definitely one of the things where I think I’m just wired to really understand how people work and why the thing that we’re hopefully helping you solve doesn’t work. That’s the thing I’m super focused on or fascinated by. Again, it’s an opinion that’s really formulated or manifested within this software, and so if my opinion is wrong, I’d love to understand, have a conversation about it. Let’s learn and see how we can improve it.

Allen: I love it. So you’ve used some of these various mental models and approaches for building Buddybuild over three years, built this product from the idea in the coffee shop of, “Why is this so hard?” to the team of… how big did the team end up getting at its peak?

Dennis: I want to say sixty-ish people, maybe a little bit more.

Allen: Which is pretty good for zero to 60 in three years. Acquired by Apple, that went how it went. Now you’re on doing your next venture which you recently launched, which is Unblocked. I’ll give you sort of an opportunity to describe Unblocked briefly in your own words, and then I’d be curious to know what things you have taken from Buddybuild that you’re maybe doing differently versus what things you’ve doubled down on in terms of culture, engineering habits, and all this stuff.

Dennis: Sure. So Unblocked at the highest level, what we’re trying to do is contextualize a code base with all the information that exists in places that you talk about your code so that you can get answers for things that otherwise block you from making progress. So if you think about it, if you’re thinking about fixing a bug or implementing a new feature, a lot of the times, you might not necessarily know how the application was built or why it works a certain way. I said the other day, I think to a couple of friends, I’m like, “I see a lot of these demos where they say file new project, and there’s very few times that you actually get to do file new project. You’re almost always inheriting a code base that’s been around for a long time,” and so the hard part isn’t necessarily writing the code to implement the feature or fix the bug. Where you spend a lot of your time is trying to understand all the context as to why the application works the way it does, who the best person is to talk to, when these changes were introduced, and contextualize it so that you can make those changes. And so that’s what Unblocked basically tries to do is give you a way to get that information in a very natural way, either by asking questions or being in the IDE and actually seeing information that’s specific to the files that you’re looking at.

Allen: Yeah, I love that description and I love that in your description you followed what I strongly encourage people as best practice, which is you didn’t mention AI at all.

Dennis: Yeah, I don’t know. It’s so strange to me. The AI stuff is… again, I’m a very pragmatic person. I can’t imagine running around the streets saying, “Guess what, everyone? I use DynamoDB. DynamoDB is the database that I use. My company’s inherently worth way more money because I use DynamoDB.” It’s a technology. You know what I mean?

Allen: Yes. Your users don’t care what technology solves the problem.

Dennis: Now, I think it is… to its credit. I think there’s a lot of froth around the AI stuff these days, but to the degree that you can replicate human behavior with software, I think you find pretty good outcomes. And so I think there’s a very natural way that people work. If you and I were working on a team and I had a question, I’d probably send you a Slack message or tap you on the shoulder and ask you that question. That’s insane if you think about the lack of efficiency there, because if you’re in the middle of something, your context is now gone. I think we’ve all experienced being interrupted while we have something complicated in our head. It’s also painful for me because I have to wait for you to get back to me. So I was like, “Well, that question behavior is definitely the way that I think most people learn. How do we get answers based on that question?” And so this AI wave is actually really, really good at replicating that behavior. And so that’s what we’re trying to build ultimately as the cornerstone. Now, if that could have been done with a fancy Postgres hybrid search with some other… sure we would’ve done that too. But this technology seems to unlock this very natural workflow, but it’s not an AI, it’s the underlying technology that makes the workflow possible. No one cares. No one should care.

Allen: Right. I love it, and I’ll continue to celebrate when I see companies building things with AI that describe themselves in context of the user value and the problem and not any technology they’re using to build it. So you’re building Unblocked and you’re live now and people can sign up and my sense is I’m sure it’s still, as you mentioned, still evolving, but especially medium to larger software teams disproportionately will benefit from this sort of latent knowledge of the code base. If you have a large code base, you’re probably going to get more out of it than if it’s an indie developer wrote it all themselves probably does not have a lot of times they get blocked on someone else, obviously. And so you’re building this business that is in some ways shares a lot of the shape of a business. As to Buddybuild, there’s a bunch of the same team, definitely. But then also you’re building things for developers. You’re helping people solve problems in their software development workflows, and you have a couple of fundamentally hard problems that are associated with that. What, if anything, have you taken from your experience at Buddybuild and then you’re now doing differently with Unblocked about how you’re approaching the team building, culture, habits, process? Or is it all just like, “Yeah, let’s do that again and keep tweaking as we go?”

Dennis: Yeah, I think it’s easy to figure out things that you did wrong because those are the ones that leave the most scars. So you just look back at your body and be like, “Ooh, that really hurts. How do we make sure we don’t do that again?” We’re still a small team. Some of those things we won’t actually really appreciate until we grow the team besides the core team that did build Buddybuild. So Unblocked, there’s 11 of us. 10 of the 11 have worked together for the better part of a decade, so it is very much the same team. We have our cultural predispositions and so I’m sure there’s a bunch of blind spots we’re not going to realize until the team’s like 20 or 50 or a hundred people or what-have-you, if we’re so lucky. Pragmatically, some of the things that we’ve done differently, I did a very, very bad job of celebrating wins. It was inception to acquisition in three years, but felt like 12 because I worked 70 to 80 hour Works weeks. I remember after selling the company on a Saturday, getting out of the shower and being like, “What do people do on Saturdays if they don’t go into the office?” I’d been so conditioned to that point. We crossed our first million dollars in annual recurring revenue and it’s a pretty monumental thing to say, “Hey, we have this thesis, here’s an opinion,” and now people are giving us a million dollars a year in perpetuity and people are telling their friends and all I was thinking about is, “Yeah, but here are all the things that are wrong.” And so it was really important that we actually take the time to celebrate some of these wins, memorialize it in many ways. And so I try to be a little bit more deliberate in celebrating that with the team. I certainly set slightly different boundaries for myself. I don’t work on Saturdays, typically. I try to stay away from a lot of digital devices on Saturdays, and I just shifted that to Sundays, but the idea is that… but yeah, it’s one of those things where I heard it a million times is, this is a marathon, not a sprint, it’s a marathon, not a sprint. And my internal response is sometimes if I didn’t vocalize it’s like, “Why can’t you run a marathon at a sprint pace?” You know what I mean? I was like, “Let’s just see if you can,” and you can, but man, you’re really beat up at the end of it for sure.

Allen: It has a high cost. It is one of those things I see a lot of people in a lot of contexts to say, “Well, we’re going to do this at all costs.” Then you find out what the all costs were and then it’s like, “Hmmm.”

Dennis: Yeah, exactly.

Allen: Well, it’s good to hear that you’re working less than 80 hours a week now.

Dennis: Yeah.

Allen: Or at least you’ve strongly implied that, and it sounds like I think it makes a lot of sense obviously when you’re at 11 person team, you can probably have almost any cultural set of cultural practices and if you have a team that’s done that for a long time, you can probably be effective. I’d be curious though, to zoom in with the time that we have left into the topic of building teams and building cultures and product cultures, given the perspective that you have. You’ve started these startups, you’ve worked at Apple, Amazon, Microsoft, and these large companies that have their own quite different cultures in some ways, but then also probably I would imagine from your perspective some similar good and bad ways of looking about things from being the size that they are. So I’d be curious to try a little bit of a… I don’t want to say quick fire round, but just loop through a few topics and see if you have any thoughts on things that you’ve learned, things that you find work particularly well in small versus large teams, or that you find… lessons learned. You’ve told me before that you have no recurring meetings except your daily standup in the morning, and then the one you and I have for coffee.

Dennis: That’s right.

Allen: Do you feel like that’s a quirk of you and the team that you’ve built around you that you can get away with that? Is this a philosophical thing? Do you think everyone else is just maybe misguided in having as many recurring meetings, as probably most of the people in this listening have more than one recurring meeting a week?

Dennis: So I think there’s obviously a point in time we’re relatively small. Things are well-defined, we don’t need a lot of communication paths or what-have-you. We’re all sitting in the same room, we can get stuff done. But I think it’s an interesting exercise. If you are a person who has a lot of recurring meetings, when you go on vacation or you step away from those meetings, did you actually miss anything? And if you haven’t, then you probably should stop going. They probably don’t need to exist. I think meetings are really, really good to solve a problem for a very specific point in time, but at infinitum seems unnecessary. We’ll have, let’s say, a quarterly board meeting. Completely reasonable, solving a specific problem over a long period of time. But you know what I mean? It changes every time. A weekly one-on-one standup meeting? I suspect if that’s happening, it’s probably because of a performance issue that needs to be addressed, right? I don’t know of something that needs to be met every single day Tuesday at 2:00. I’m sure there’s lots of counter examples, but for me, what’s that expression? The meeting will grow to fill the time allotted to it or what-have-you. And so I don’t like necessarily having these conversations. I think one of the best things that we do in our meetings is we start off every conversation by saying, “What’s the problem that we’re trying to solve?” And if it starts to deviate from that problem, we snap back to that specific problem. Once that problem is solved, go back and solve it.

Allen: When you were in these larger organizations… and to say larger organizations is an understatement because it’s literally more than a thousand times larger than the team that you’re on right now.

Dennis: Yeah.

Allen: Were you able to effectively scale back on having those recurring meetings? Because a lot of the large companies, I don’t know exactly, but of course every large company is a quilt of a whole bunch of different subcultures rather than just one monolith the way that people maybe think about it, but a lot of companies will have soft rules, which is like, “Oh, you should have some recurring one-on-one with your direct reports.” Andy Grove would say it’s a fireable offense if you don’t have a recurring one-on-one with all your direct reports. Were you able to get away with at least having within your team saying, “Okay, well our team has minimal to almost no recurring meetings,” and it’s just the recurring meetings are the ones that are outside our org, or once you’re at that scale that maybe the recurring meetings do fulfill a necessary evil to keep everybody aligned in terms of communication and coordination and habits?

Dennis: One-on-one meetings with direct reports, that’s actually something that I believe solves a real problem. I want to make sure that that person is feeling good about their job, they know what to prioritize, they have an opportunity for us to connect. That seems super reasonable. If there’s other ways that that information can be conveyed and it’s not 30 minutes or 60 minutes every week, then I don’t know why you wouldn’t explore that. Again, I think there’s also this weird social predisposition where people feel like if they are invited to a meeting, that they need to attend it, even if it’s not helpful. As recently as yesterday, one of the engineers on the team was trying to get something done. He’s like, “I’m not going to attend this thing because I really want to focus on that.” And he was kind of sheepish about it. And I was like, “Absolutely, yes, a hundred percent. You should absolutely do that.” I was the one who called the meeting, we’re trying to solve these series of problems. He’s like, “This isn’t what I think I should be spending my time on.” And I’m like, “Yeah, you’re absolutely right. So go work on that thing. We’ll figure out this and loop you in if we need to.”

Allen: Yeah, I think that’s probably not controversial… or maybe it is, but I don’t think it’s controversial you should try to build a culture where people feel like they should nope out of meetings.

Dennis: I don’t think it’s controversial. I think it’s really hard to do. You know what I mean? If you have a regular staff meeting and you’re just like, “This is not an effective use of my time,” and you don’t show up to that staff meeting, well what signals does that send to the other people?

Allen: Yeah.

Dennis: “You guys are wasting my time,” right? So how do you balance those two things? How do you actually say, “Hey, this isn’t super helpful.” So you can either realign or try to fix the trajectory of the meeting, or you can be seen as an ass and you’re just not showing up anymore. And so usually it’s approach one and then approach two if it doesn’t work.

Allen: Yeah. Okay. I like that. I always enjoy any interesting mental model that people have for challenging the quantity of meetings, because so many of my discontinuities where my job or my effectiveness or my life got better is when the number of meetings I had decreased.

Dennis: Yeah, yeah.

Allen: So I’m always looking for new crowbars.

Dennis: For sure.

Allen: How do you think about the term product management?

Dennis: That’s such an open-ended question. “I like the term product management. What do you think of the term product management?” That seems like a good term. Yeah, I like that.

Allen: Let’s manage some products.

Dennis: Yeah, yeah. Those products won’t manage themselves.

Allen: Yeah. The reason I ask is, the sense I get is that in orgs large and small, it’s one of the roles with the highest variance in how it operates and the impact it has in different organizations, even within a company. And so most teams the size of 11, a founder-led startups, don’t have a product manager title, and that’s pretty standard. I know that’s the case at Buddybuild. Something that I find interesting is talking to founders who have gone through an acquisition loop or they have worked at large companies. I hear widely varying opinions about the the ideal role and the value that product management as a function, people whose formal title is product management think of themselves as having a career and product management bring. I hear some people take an argument that it’s like, “Oh, it’s the backbone of an organization,” and that having people who have a founder mindset that have a vision for a product in a lot of ways or can be really effective as product managers is almost like the founders of the subproducts within an org. And then I’ve heard arguments that modern product management is mostly just a scheme or a scam and that really, it’s an excuse for ceremony and that engineers should be the ones owning the spec and actually talking to the customers, and if you’re answering enough intercom messages, you wouldn’t need product managers. And then everything kind of in between. So I was wondering whether or not you have any thoughts or feelings on that role and how we build our teams and cultures around that, because it’s one of the levers. I think, that when you’re building a product and engineering an org, there’s a lot of consideration, I guess a lot of latitude, in how you build and organize your product management function.

Dennis: So to me, I saw product management and program management, sometimes those terms are used interchangeably at Microsoft, Amazon, and Apple in different incantations. I think the success scenario is, and I’ve seen it across those organizations, almost irrespective of what the name of that role is is someone who is very clear as to what’s the problem that people are trying to solve? Not how it should be implemented, but what it should do, what the relative priorities are, and then when things get confusing, provide clarity around that relative to what the priorities are and what it should do. I find the failure scenarios are people who are just effectively running a process like, “Okay, let’s go through the bugs,” and have no understanding of what the bugs are. I think we used to call them checkbox PMs, so they would just check the items on the list and provide really very little value to the actual evolution of the product or what-have-you. So to me, yeah, I think you call them as little founders, I’ve heard of them as mini CEOs, but I think people who can provide clarity as to what we’re trying to build, why we’re trying to build it, and what order it should be done, that’s an incredible product manager. That’s a really hard thing to do though, because you generally need to have some deep domain experience in certainly two of those three things. Could you take a product manager who’s, I don’t know, focused on, I don’t know, choose something arbitrarily like payments and stick them into dev tools and say, “This person can be productive?” Or e-commerce and go into dev tools? That might be able to give one or maybe two of those things. But unless you actually feel the pain or you’ve spent a lot of time building software, it’s probably going to be hard for you to really empathize with what should be built. I also find one of the third rails that product managers touch is they tell engineers how something should actually go and get implemented. Most engineers, that is the… building software is both an art and a science, and so when someone tells you what paintbrush to pick up, which paint, and how to apply it onto the canvas, I don’t know. It doesn’t feel like that’s a very satisfying job, especially if they’re wrong.

Allen: Yeah.

Dennis: So yeah, I don’t know. I think to your question, should you have engineers answering intercom? I think there is definitely value in someone who sits in between an engineering organization and a whole bunch of customer feedback, can synthesize it, knows based on what we’re trying to accomplish what needs to be done, can relatively prioritize it, and then help the engineering team go define and implement that such that the customers are happy.

Allen: One thing, and I think I can guess what your answer to this is going to be, but we’ve mentioned that you do daily standups and that’s part of your development process ceremony that you do at Unblocked, and I assume that you also did that at Buddybuild. Are there any other habits or ceremonies or process things that you feel like hold water, pay for themselves in terms of the effort, or is that the one heartbeat?

Dennis: I think there’s many processes. We do start with every meeting by saying, “What’s the problem we’re trying to solve?” And that’s a variant, honestly, of what Amazon I think still does, which is before every meeting gets kicked off, they have printed out piece of paper or they read some short document to help align everyone as to what this conversation is going to be about. That’s one of those mini processes that we do. On the feel good, nice side, it is nice to, on a sunny day in Vancouver, which exists, to go out as a team and decompress for a little bit, sit in a patio somewhere or something to that end. In terms of the day-to-day engineering processes, the other one is like, “Yeah, what are you going to do?” And then the more valuable one is when something didn’t work, you took longer than you expected or something failed, those post-mortems are insanely important. Making the same mistake twice is just almost unforgivable in my mind. There’s no excuse for it. If you’ve identified it and then you do it again, why?

Allen: Do you call them post-mortems or debriefs or retros or… not that it matters what you call them.

Dennis: Yeah, I don’t know. I don’t know if I can use that language on a podcast. But some variant of that, yeah.

Allen: Okay.

Dennis: Some variant of that, yeah.

Allen: I love it. What are the biggest, if you can think of any, biggest weaknesses or gaps that you’ve seen at large companies that make them potentially vulnerable to competition from startups and more nimble, smaller companies?

Dennis: Oh yeah. Lots of gaps.

Allen: Yeah, I know. That’s why I figured you’d have an answer to this.

Dennis: What’s the difference between a big company and a small company? One of the biggest differences, I should say, is at a big company you get a hundred percent or near a hundred percent distribution the moment you talk about it. At time equals zero, you ship that product, there’s tens of millions of people or hundreds of millions of people using it. At a startup, what you get is zero distribution, and you have to beg and plead, and hopefully someone will use it and maybe tell a couple of friends and it slowly starts to build a flywheel. But what we have to do is you have thousands of people that you need to coordinate in order to get that system built. Whereas in a startup, you can probably build that exact same system… well, I know definitively you can build that exact same system with far less people. I think one of the advantages of being in a small company is that you get to have a spectrum of responsibility and can really build compelling things very, very, very quickly, and then you have to take on the onus of highlighting or making sure the world knows about it. Whereas if you’re a big company, and often… I don’t know honestly, just maybe a handful of examples, but overwhelmingly the software that most big companies ship is not particularly compelling. Often, it looks a lot like other software that smaller companies have shipped, and so… I don’t know. I prefer to be in small companies or small groups of people that are empowered to ship high quality software or software that people love as opposed to a really big company where you make a whole bunch of people feel, “Meh.

Allen: But you can do it at scale on day one.

Dennis: Yeah. Yeah.

Allen: Awesome. Well, thanks, Dennis. This has been awesome. I know we could talk and we will talk for hours more overtime, but for today, that is our show. Where can people go more to find out about more about you and your work?

Dennis: getunblocked.com is certainly the URL that you can go and learn about the company. We want people to get Unblocked, so we like that domain. If you want, my last name is long, but it’s @dennispilarinos on Twitter, you can reach me there, or you can just email me dennis@getunblocked.com. Like I said, as long as you’re not trying to sell me something I don’t need, I reply to every email and I’ve always done that as far as I remember. If I haven’t, then let me know. Thank you so much for having me. Like I said, I still hold you as one of those people that I deeply respect their perspectives and opinions, and so I’m very flattered to be on the show. Thanks for asking me.

Allen: Well, thanks Dennis. You’re too kind. Same to you. Thanks for being on the show. 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. That’s it for today. You can give us feedback, follow us on social media, or rate the show by going to itshipped.fm/contact. Until next time, keep shipping.