Today's guest is Dan Pupius, CEO and co-founder of Range. Dan cares deeply about creating products that make healthy and sustainable workplaces a common occurrence. We talk in depth about designing constraints and opinions into products with the long term in mind.
Today's guest is Dan Pupius, CEO and co-founder of Range. Dan cares deeply about creating products that make healthy and sustainable workplaces a common occurrence. We talk in depth about designing constraints and opinions into products with the long term in mind.
Thank you to long time sponsor and friends of the show Linode for sponsoring today's episode!
Simplify your cloud infrastructure with Linode’s Linux virtual machines and develop, deploy, and scale your modern applications faster and easier.
Listeners of Developer Tea can now enjoy $100 in free credit! You can find all the details at linode.com/developertea.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Hey everyone, welcome to Developer Tea. In today's episode, we continue our discussion with Dan Pupias. If you missed out on the first episode, I highly encourage you to go back and listen to it. We lay out a lot of our discussion on the psychology of the workplace and how range fits into that psychology. I recommend you go back and listen to that before you listen to this episode. I'm very excited to do this discussion with Dan, and I'm looking forward to so many interviews that we have already lined up on the schedule. If you don't want to miss out on those interviews coming up, I encourage you to subscribe in whatever podcasting app you're listening to this episode with right now. Let's get straight into the interview with Dan Pupias. Yeah, that's the psychology of... A working team, organizational psychology is exponentially complex, right? Because we have individual psychology, and all of those individuals get mixed into a group, and there's so many variables that you can't really approach it the same way that you would a pathological-type study of an individual. You almost have to... Approach it from an observational perspective. What are teams doing that is working? And try to back your way into why, right? The understanding of those dynamics. Why does it work that way from a kind of a principles position, evaluating those teams? Yeah, I mean, you use the word complex, and the definition of complex is probabilistic, and that you don't have a full picture of the system. And by the nature of humans, like we work with a bunch of humans, like we don't understand everything that's going on. People show up to work with stress from home, or maybe they're just hungry, or maybe they're worried about a project, or they don't have the right skills. So there's a huge amount of information that isn't available to us. So we are... And then you amplify that by the number of people involved, and it's just like very exponential, like you say. Whereas most of our management practices, were designed during the Industrial Revolution, where they were building complicated systems. So there are big factories with many moving pieces, or 2000 rail workers. But they understood the full picture, and they worked very hard to sort of like simplify the labor, so that people were interchangeable, and it didn't matter as much about the unit of work. So in the information age, that type of management, just doesn't work. And we need to have people be creative and innovative. Yet we're still using these management practices that assume that systems are complicated and knowable. So that was one of the things I was really interested in, is what would a management system or an organizational system look like if you acknowledge that it is unknowable? So it's much more about sensing instead of predicting. And instead of controlling, it's like empowering and aligning. It just kind of fundamentally shifts your mindset. Yeah, I wonder if people, even those who are practicing some of those management tactics, if they realize the etymology of them, kind of the, why did we have eight hours a day and that kind of thing? And whether those things are still being trained and taught as best practices, in I assume, in management schools and that kind of thing, to reduce variability with the, I guess the panacea of management being, the ability to automate everything, right? That's the prompt, perhaps the false promise of reducing all of that variability and making everybody replaceable. But I wonder, I think we're just ignoring the upside of not worrying about reducing that variability, right? And allowing the variability to be part of the energy of the team. Part of what makes a team particularly good is allowing for that wide expression. Yeah, I think part of the problem is that we don't differentiate the types of work. And so there's like simple labor, which is reducible and probably on a long timeframe will be automatable. But then there's complex labor, which is much more like the creative industries. So arts, sciences, programming, designing, all the creative aspects or services end up being in that complex realm. And those systems have emerged over the last few decades and become the predominant form of work. But yeah, we're managing it like simple labor. And one of the things that like I realized that made my head hurt and made me want to learn more, was like, why do we structure organizations in hierarchies? So we have the engineering hierarchy and the product hierarchy and the design hierarchy, and that doesn't reflect at all how we work. We have a group of people who are working on a project. We have engineers, product people and designers, occasionally marketers, come in. So the way we're actually working is not represented by the ontology of the organization. So we're trying to manage this system that isn't actually how the work is getting done. So if we go back to first principles and start from where the work is happening, how are these people collaborating? How is the team working? Who is playing the game? How do we structure that work? And what do they need to be successful? And then back out of that question, you start building very different organizational systems. The organizational hierarchy changes. It's more networked. You start thinking about performance management differently. You think about communication differently. So that's how I got into this. It's just thinking about how work happens on a daily basis. Yeah. Yeah. It seems that a lot of our systems are lagging behind while other things move much faster and there is a disparity. And that brings me to something that you said earlier. You said there's a big opportunity here and you'd rather talk about that. And I'm curious, you know, there's there's a couple of different kind of groups of people that have different kinds of opportunities. And I'll kind of give you the groups that I'm thinking of. One is the individual contributors, the engineers who are actually working day to day on products. The second is people who are building products like Range and people who are responsible for building kind of work culture products. And then the final group is people like me, engineering managers who are responsible for cultivating the environment of work for those ICs that I mentioned already. So what do you see as the opportunity for for those groups of people? I mean, broadly for all groups, I think it's it's about making work better. And so much of our lives are spent at work. And it's kind of sad that it's such a bad experience for so many people. So there is like an ethical and moral reason for making work better. And I do maybe naively think that if we can make people's work experiences better than that carries over into other aspects of the world. And if you're not as exhausted and stressed after a day of work, then you'll come home and be a better father, for instance, or that you'll have a better perspective on the world and be more altruistic because you're not, you know, catering to your base needs as much. So I do think there's some moral reasons for making work better. And that's like the ultimate opportunity. And then I do also think that long term, that's how you make more enduring businesses and companies. So it's not purely altruistic. It's it has to be. It has to be a balance. And so that's that's the the main opportunity is to make people feel more connected to what they're spending so much of their life doing. So focus on personal growth, personal development. And gain the benefit of it all, like feeling an emotional connection to the impact of their work. Because, you know, 40 hours a week is a lot. So if you're going to spend that much time, you know, it would be good to be good that you have. You're feeling some. It just feels it should feel more rewarding, I think. Yeah. Yeah. And, you know, I imagine that if. You know, let's say we have. Three engineers on a team and two of them begin to be more emotionally vulnerable on that team. But the third will likely see that if we. So there are ways to even if you're you know, your business processes haven't totally switched over to this, whatever you want to call it, more mindful way of working or human centric. You can still begin to communicate in ways that are more human centric. You can. Yeah. At the same time, you may have toension your evolution and evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution And the idea here is not that there are never any reasons to speak privately with somebody. Of course there are. But most of the time, we default to communicating in these channels that are not public out of some incorrect understanding of our culture or some fear-driven understanding of our culture. We communicate something to, let's say, two or three people because we're afraid that if other people see it, it's going to be criticized or it's going to send the wrong message or something like that. And if you do enough of this, if everybody in the company is doing this, then those fears that you are sending the messages because of become real. They start to actually surface. And so I'm interested in the idea. That there are some of these heuristics. And I wonder if you have any more specific advice like that. Like principles? Yeah. Something that I can say, okay, very simply, in any situation, this can apply. Yeah. I mean, there's a little bit of a contradiction, which is that a lot of these solutions and principles have to be context-specific. Yeah. There are no one-size-fits-all answers. But I think there are some guiding principles that are useful, which is the default to transparency. There should be a good reason to keep something private and force people to think about that. Create moments of safe vulnerability. So the vulnerability is contagious. And it does compound. But the vulnerability is what leads to trust and what leads to belonging and psychological safety. So that's important. And even if it's as much as asking people to say how they're feeling at the start of a meeting or play a game where you get to laugh and show some emotions, even that is the type of vulnerability we're talking about. It doesn't mean you have to open up about your darkest secrets from childhood. That's not what we're asking. Like, because that's not what we're asking. That would be invasive. And then I guess the other piece would be to really focus on the cadence of communication. So sprints are really popular in tech. And I think of sprints as being generally a cadence of work and output. But I think what's more important is to have the cadence of communication because then it becomes ritualistic. And it's these rituals of how you go off, do some work, and come back together that make you really feel like you're rowing in the same direction or rowing on the same team. And humans are incredibly ritualistic. Throughout the ages, people would have regular meals. And you have, like, Wednesday is when we go do X, Y, Z. And Sunday is when we go to church. And three times a year, we have these big feasts. And all those rituals serve a purpose. And a lot of that purpose is around creating a belonging and a sense of community. So as you're thinking about work, think about the cadence of communication. So we do two-week cycles. Some teams do that as the work sprints. Other teams work on, like, four, six-week work cycle work sprints. But we have the cycle of communication where every two weeks we come together, we have our recap. At the start of the cycle, we have a kickoff meeting. And then throughout the cycle, we have these touch points. And really building that rhythm and that drumbeat of how you interact with each other, it both normalizes communication. It reduces stress and anxiety and also just, like, creates this backbone of belonging. And so that's what we're trying to do. Yes. As an engineering manager, I know that these cadences are so important to be able to elicit, for example, feedback. And that the feedback may take some time. The cadence actually has to kind of be in place for useful feedback to flow. I think there's another interesting aspect of this that happens between different layers. So, for example, if you're one of the managers of the organization, particularly we were talking about hierarchy earlier, your kind of cadence, your individual cadence, especially if you're in a different kind of hierarchical level from someone else, is going to be different from theirs. So, if you're an engineer on a team, you're likely to have a very similar cadence to another engineer on the same team. But that cadence is going to be different from someone as close to you as your manager. Right? Because you're not the same person. Right? Because your manager is going to have their own meetings and their own concerns and their own kind of incentives, et cetera. And so what feels like a very important meeting to one person may not feel like a very important meeting to another person. Right? So this is something that I guess a piece of advice that I have for managers, which is try to understand that your perception of the team, the team that you're working with, is going to be different. Right? Right. Right. Right. Right. Right.. Right.. to think about this is kind of like almost like visualize the network and i think about like organizational distance and also like the number of edges so if you have one one-on-one every two weeks that one-on-one is going to be really high stakes whereas if you're a manager and you have like i know some managers have crazy number of reports like 14 one-on-ones over two weeks like just by definition your attention is going to be split more ways so so having empathy for how other people fit in this system of work and and what their relationships are is really important and once you have once you start to like visualize this you can then start to think about where are their opportunities or deficiencies um like maybe this person that only has a one-on-one every two weeks but and doesn't have any other like interactions with people on a human level or learning work work meetings maybe they're going to get disengaged and feel disconnected from the organization so how do we solve that need and bring people together um to have that human connection and then and then the other aspect is that the k the cadence of the organization has to cater for different bandwidths of communication so if you're a director and you're three levels removed from the team your bandwidth needs to be much lower than if you're a pm um to an eng team like the bandwidth has to be really high so then you have to cater your communication to the bandwidth so the stand-up that teams do day-to-day or the um the slack channels or whatever that's a high bandwidth a channel which makes sense for a team but doesn't make sense for two teams across the organization or people up and down the organization so you have to design communication protocols that um are more like contextually appropriate for the those bandwidth channels i'm not sure if that's too like intellectual or like over the top but it helps helps think about the the organization as a system and then you can start putting your practice in place that take into account all the different parties and how they fit together we'll get right back to our interview with dan pupius right after we talk about today's sponsor linode today's episode is sponsored by linode with linode you can simplify your infrastructure and cut your cloud bills in half with their linux virtual machines you can develop deploy and scale your modern applications faster and easier and you can do it with a hundred dollars in free credit for listeners of developer t whether you're developing a personal project managing larger workloads etc you deserve simple affordable and accessible cloud computing solutions no matter where on that scale you land linode has data centers around the world with the same simple and consistent pricing regardless of location you can choose a data center that is closest to you you can choose one that's closest to your customers or users it's all so flexible you can also receive 24 human support that means every day of the year with no tears no handoffs you don't have to be paying them a ton of money in other words to be treated well to be treated like a customer right regardless of your plan size so you can choose shared and dedicated compute instances or you can use your hundred dollars in credit on s3 compatible object storage managed kubernetes and more this is worth it just to try things out and have a little sand box you have nothing to lose here if it runs on linux it runs on linode head over to linode.com slash developer t and click on the create free account button to get started thanks again to for sponsoring today's episode of developer t yeah the problems uh are not necessarily incredibly complex to solve and they're not necessarily incredibly complex to solve and they're not necessarily incredibly complex to solve and they're not necessarily incredibly complex to solve and they're not necessarily incredibly complex to solve but i do think it's it's much more about empathy than it is about anything else it's about understanding that these um different layers of organization you know this doesn't require a huge algorithm to solve i guess is what i'm trying to say right this is very much a human problem and much of it can be solved with kind of adopting these heuristics of put yourself in their position right one thing you could do is uh open a a uh uh! a tab uh on your google calendar and turn off everybody's calendar but somebody who reports to you and just kind of feel you know get the feeling of their schedule what does their schedule feel like and there's not really a easy way to put that into you know we're talking about emotions here right this is a very difficult thing to pro to put a perfect process around so if you can understand how somebody else might feel uh and to your point you know some of this relies on some transparency if we have blocks in our calendar that just say busy that's a very different feeling from lunch with my children yeah right yeah totally if i understand that hey if i'm asking you to to cut into that busy block that you have it's very different if it's lunch with your children i probably am not going to ask that yeah uh that that seems like a much more um you know personal and and you know i'm not going to ask that because they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and they may have signed off on their calendar and two one-on-ones and a cycle recap, that seems like a pretty healthy meeting load for a Friday for an engineer. And I see that she's like her main focus for the day. But if I looked at that and saw that she was in like six hours of meetings, like planning meetings and brainstorms, I would then be able to know that she's not going to get much progress made on that coding work that she's got. So I wouldn't then need to bug her or like feel micromanaging about the status. So I think, yeah, visibility and like context of like what people are doing is super critical. And too many of the work tools purely focus on like commits or tasks. And that's not the full picture of the person. So we have to take into the interviews and all these collaboration meetings that are essential. Yeah, I've heard it described as glue work. I can't remember who it was. I'll give credit probably in the notes. But the idea that especially as you kind of move up the chain, so to speak, as you're responsible for more and more scope of work, that a lot of what you do is stitching and bringing things together. And interviews are an example of that. Yeah, totally. And then it can also be, it can also get, the visibility can also be important for coaching people. So I've definitely had situations where someone's productivity was suffering and they just didn't seem to be able to achieve what we thought was appropriate of their role. And with limited visibility into what they're doing day to day, you don't have the empathy or the understanding for why that is. And when you dig in, you realize that they're doing all this extra work that they think is important and may have some organizational importance, but isn't there, and that's the key line of work. And that becomes the problem. Or maybe they're just not very good at defending their calendar. And they've been invited to all these meetings and they don't really need to be there, but they don't feel like they have a position to push back. So at that point, you get some visibility into what their week looks like and you can coach them on, like, does this work really need to happen? Is it critical that you could do this? Could someone else do it? Or like, are these meetings actually essential? And can you defrag your calendar to give you more focus time? So, yeah. So I think often we have performance, performance problems that are related to, like these systemic effects that can be corrected once you have like a good picture of what's actually going on. Yeah. I love that visual of defrag, imagining my calendar just being kind of shrunk down to these blocks. I did that exercise with someone recently on our team to help them get focus time. And we actually have this weekly email that we send out. And it has a meeting load calculation. And so it's like, how many hours were you in meetings? But then also, this is kind of non-intuitive, but I find it fun to include, which is a focus quotient. So the focus quotient is like, how much focus time do you have? And you get points for blocks of free time that are more than a certain amount. I think it's an hour because anything less than that, it's just like dead time. So then you can figure out, like, how focused was your week? How efficient was your calendar packed? Because you can imagine eight hours of meetings could be horrendous, or it could be relatively efficient. Yes. Yeah, absolutely. I mean, again, this goes back to what we were talking about before, where we treat our time as these kind of easily programmable blocks, almost like memory on a computer. But there's changeover. There's so much more. There's so much more. And we could extend that metaphor, I'm sure, to make it work with computers. But we're not computers. We don't work that way. We need time, for example, sitting out in the sunlight, because we need vitamin D. That changes the way we think. And that's not really, we can't really reflect that. Putting sunbathing on our work calendar seems wrong for some reason, but it's absolutely part of our machinery. And so how do we integrate that? I think it starts with exactly what you're saying, with . . . Yeah. So it's kind of reviewing those calendars. I mean, the other thing is we're all different as well. We're not the same. And if you look at circadian rhythms, I'm sure people have heard about the lark versus the owl. And I hate the 9 to 5, primarily because I am not effective during that schedule. So for my whole career, I felt that that was an oppressive time structure. I'd much rather start working around 11, take a break in the afternoon, and then work late into the evening. And I think that's the way I feel. And I think that's the way I feel. And I think that's the way I feel. And I think that's the way I feel. And I think that's the way I feel. At the same time, evolution brings evolution brings work where you have to have creative thinking so i would often when i worked at google i would often go to the gym at 11 o'clock and then that would actually unlock things in my mind like just you know doing weights or running or swimming and then i'd come back to my desk and have all of a sudden solve this problem that i otherwise spent three hours like banging my head against the wall to try and solve so i think as we can if we can start breaking down these these artificial structures and create work patterns that allow people to be more flexible then we can people can start to sort of design their work habits around their own you know logistical and energy needs i mean the logistic is interesting as well like i i every day at four o'clock i pick up my daughter from school so it has to be acceptable for me to to be out of work for an hour in the afternoon obviously i'm a ceo so i can make the rules but if i was you know if i was an engineer working at a big company would i be would i be getting dinged on my performance review for being absent during the afternoon every day right yeah and and strangely you know being a good father is uh antithetical somehow to being a good engineer right and that's that seems wrong um yeah and it would it seems that the the stress that you would have of not being able to be there to pick up your daughter would be worse on your work performance right but it begin again the we go back to that complexity problem where how do you calculate that impact there's not enough you know we don't have enough context to be able to do that right so i think it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's it's which is we hand over the keys and we say, look, we're going to develop trust rather than systems. We're going to develop trust in you and we're going to have systems of accountability, but they're not going to be based on following these specific perfect rules. Instead, we're going to say, hey, here's the keys. Here's the power. You are the person that is kind of responsible for making these objectives happen. We're just here to help you. That's the job of the manager. And I think that you say, hey, you know what? The thing that's going to help me meet this objective is if I can be a good father and a good engineer in the same day. They don't have to be at odds with each other. Yeah. People often talk of work-life balance. I think balance is a nice metaphor. But often people don't talk about work-life balance. Often it's like work-life tension. And instead of thinking of a weighing scale that balances both sides, it's really like a string that you're stretching in both directions. And that tension is painful and you feel torn because you want to go and be a good father and pick your daughter up from school. But you also want to be a good employee and a good teammate. And you feel the tension in the other direction. And that's totally how you end up feeling stressed and anxious. And that's not how you're going to do. You're going to do your best work and how you're going to be the best father as well. Yeah. Yeah. Oh, I could talk about this stuff all day, Dan. I really, really could. Me too. We're approaching well over our time, actually, at this point. But I do want to give... You've got the powers of my arms and eyes. No, that's all right. I do want to give you a chance to kind of give some blanket advice, 30 seconds of advice, to engineers. And I think that people who are listening... This may also be not just engineers, but product managers and that kind of thing. What advice would you give them, regardless of their background, regardless of the experience, if you just had 30 seconds to give advice? Yeah, I wrote this down before we talked. And interestingly, it's relevant to some of the themes we discussed. And what I wrote was that the craft is important. But don't fall into the trap of engineering for the sake of engineering. Focus on the outcomes and the impact of the work and the human needs that your work is solving. And if you can tie your daily work to that external impact, I think you'll both do better work and it'll be more rewarding. And yeah, that's the basic impact. I could also go... Or the basic advice. I could also go on and extend that, but that's the short version. Sure. And if you want to give the 45 seconds... Feel free. Yeah. I mean, what then follows from this is that often we think we're building pyramids that are going to be around for 2,000 years. And we put our soul into this artifact. But that is obviously not true. Or it shouldn't be true. And really, the purpose of our work is to create an outcome for people and to serve a need. And if the code and the bits don't continue serving that need, then they shouldn't exist anymore. So I prefer to think of coding as building a sandcastle on a beach. And the most beautiful sandcastle will be in the wet sand near the ocean. But then it's also going to get knocked down. And then you rebuild it again. So don't worry about building something forever. I think just focus on the need that you're serving. Yeah. Wow. Oh, that metaphor is going to be in my mind as we close out here. Dan, thank you so much. Thank you so much for joining me on Developer Tea. And I'd love to send people to learn more about Range and perhaps more about your work and your thoughts. Where can I send them? Yeah. So www.range.co. We have a blog. You can go there. And writing.pupius.co.uk is my personal site. And yeah, happy to offer a discount or like an extended free trial to any of your listeners. You can just hit. Hit us up on support or use the code developer tea. Oh, awesome. That's a surprise. That's awesome. Thank you so much, Dan, for joining me and for providing that to listeners of the show. Cool. Yeah. Thanks for having me. It's great fun to chat. Another huge thank you to Dan Pupias for joining me on today's episode of Developer Tea. If you want to learn more about Range, head over to range.co. With Range, you can make great teamwork way less. Work. Thank you to today's sponsor, Linode. Head over to linode.com slash developer team. Make sure you click on the create free account button to get that $100 worth of free credit. Thank you to Linode for providing that to our listeners. Thanks so much for listening to this show. If you enjoyed this episode, then you will almost certainly enjoy talking about it with us. Us being the community of developer tea listeners and myself in the developer tea discord community. Head over to developer tea.com. We'll see you next time. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.! Thank you.