Developer Tea

Dan Pupius, CEO and Co-Founder of Range, Part One

Episode Summary

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. Don't miss the next episode - subscribe today!

Episode Notes

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. Don't miss the next episode - subscribe today!

✨ Sponsor: Square

Square's Terminal API makes payments easy, whether in person, in-app, or both. Process payments on every platform imaginable. Get started today at https://developertea.com/square

📮 Ask a Question

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/contact.

If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.

🧡 Leave a Review

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.

Episode Transcription

Hey everyone, welcome to today's episode of Developer Tea. My name is Jonathan Cutrell. In today's episode, we have a discussion with a founder and CEO, Dan Pupius, created range to help the team's work better together. Now before I lose you on that, it really is what Dan cares about. He wants teams to work better together and he wants to create psychologically safe environments and he has been hands on designing this product to help teams do just that. And range is a very simple application at the time of the recording of this episode, but as we discuss in the episode, range is driven more by purpose than it is by specific features. I'm excited to talk with Dan, so let's get straight into the interview with Dan Pupius. Dan, welcome to Developer Tea. Hi. I'm excited to have you on the show and I want to kick off this episode with a question that sometimes I leave until the end. It's one of the two main questions that I like to ask at the end, but I think you might have some really interesting answers to these questions. So the first question I want to ask you is, what do you wish more people would ask you about? Yeah, when you told me you were going to ask this, I actually kind of struggled because I'm often just curious to talk about whatever people are interested in. I think the answer would be is like the human side of engineering and thinking about the human systems and the organization design. I think that's super fascinating and is often more challenging than the technical aspects of the work. I'm going to dig in on this because I agree with you and I think the specifics of how this plays out is really interesting. We're going to dig into it in just a second, but first I want to take a minute and let you introduce yourself. I guess we jumped right over that. Can you tell listeners who you are and a little bit about range? Yeah, so my name is Dan Puyas, co-founder and CEO of range. We started range a few years ago with the goal of helping teams work better together. We believe that there needs to be a balance between well-being and productivity and we want organizations to aspire to create these environments where everyone feels empowered and engaged. We do actually feel that software has a role to play in that since software facilitates so many of the work processes. We started with asynchronous communication as a way of providing foundation for teamwork. Today range is core as a check-in tool. It's a simple status update that people do usually daily. They show their plan for the day and what they've got done, but also how they're feeling. It's a little bit like a stand-up, but we integrate with all the tools that you use. It's really easy, it integrates with your workflow, and then also creates a lot more transparency into the work stream. That's it today, and we use it to teams like Twitter and Airbnb, and these to keep stay connected and know what's happening across the team. I love the way you describe your product as what it is today, because it does two things. One, it lets people know that, hey, we didn't set out with this grand vision to create a stand-up thing. That's what you've discovered over time is an effective tool. Also, you leave space to change it in the future. You might write about that. Totally. You can't boil the ocean, and it's a big mission. We want to help facilitate all work processes in a way that actually makes work more engaging and pushes authority and decision-making out to the edges of the organization. We needed to start somewhere, so we started with this check-in, a bit like a virtual stand-up, and the reason we liked that was it was a regular habit. It was a behavior that people were already doing that we could pick you back on. It is actually the intersection of work, it's about what you've done and what you're working on, but then also the relationships between the team. It was an opportunity to bridge that gap between the productivity and the team effectiveness. I love the idea that our tools that we use every day, which developers are very well known for loving our tooling, and for also hating our tooling, but that's a different story. I'm curious, what do you see as, I guess, I'm just very interested in this idea of making our tooling one step more human? What do you see as some of the major downfalls of developer tooling, or maybe not just limited to developers necessarily, but product engineering teams? The tooling that we use, what are the major themes of problems that you see in that industry right now? That's a big question. I'd rather talk about the opportunity versus the problems, but I guess some of the problems are not thinking around how the software gets used or the implications. You can imagine a productivity tool that tracks what people are working on. It sounds good in theory, but then it ends off being a surveillance tool which actually creates an environment that's not psychologically safe. You can think about these unintended consequences. The positive spin, I would say, is that Churchill said that we build the buildings there after they build us. I think it's the same for software. We build the software, but then the software changes how we behave and how we interact with people. We have to think about software development intentionally about how people are going to use it and how people are going to relate to each other. There's an anecdote from my time at Google that I've mentioned a few times around code of you. I worked on this library, JavaScript library, that was used across the company to start with the internal code of you tool, just had your LDAP name. I didn't even show your full name, it was just some arbitrary string. I'd get a code of view and I'd often have this visceral hit of anger and frustration as soon as the code of view dropped. If I did the code of view, I'd end up being pretty harsh and aggressive and I got some feedback that I was scary to send code of views to. I realized that if I went to the team directory and looked at people's profile photo and what team they worked on and what their name, then I would empathize more with them as a human and then I'd come back to the code of view and be much more reasonable in my relation with you and my review feedback. That's the role software has to play is to can humanize the recipient and it can help you give empathy into the people you're communicating with and the others in the system. If you don't have that mentality of the outset, you can end up creating systems that can create anxiety and create tension between people while they don't really need to exist. This is such an interesting concept to me because I think I've encountered so many software engineers who when they think about tooling, they think about it purely as a means to an end. This isn't just engineers by the way, but engineers seem to have a particular lean in this direction because so much of what we deal with as engineers is trying to get behind the pretty layers and into more the core. I think we often think about it as a means to an end, but actually when you look at the behaviors, it's much more like a framing device. We have some bit of information that needs to be framed and how it gets framed, the context that it's in, what kind of meta information is included can totally change what you perceive. I think you just, Enneke, you just gave is a perfect example of this. It's the same information at the core, right? The code didn't change when you went and looked at the picture, the directory, but your perception of the code was now contextualized a little bit differently. I wonder, what do you think of this concept of technology or tooling as a frame rather than purely as a tool? Yeah, totally agree. I see software as architecture and architecture shapes our behavior. If you think about driving as an analogy, your goal is to get from A to B and the end is being at B, but how you get there is very critical and the architecture shapes you driving behavior. If you have speed bumps or road signs that will change how you drive, and if you remove line markings, it's been shown that people will slow down or if you make the curve, the street, cuddled that will change driving behavior. The means are as important as the ends because it actually shapes how the journey occurs. That can actually change where you end off as well. I think the software is very similar. You have to think about the process as well as the outcome. Yeah, this is such an interesting point you make because I actually just read a book called Chatter. It just came out not too long ago. In the book, one of the things they discuss is the effect of our environment on our well-being in ways that we wouldn't necessarily intuitively expect. Of course, for example, being around green spaces. This is a very well-studied effect and unfortunately not very well known in common culture, but green spaces can have a pretty dramatic effect on your well-being and on your cognition and a whole host of other things, biomarkers, etc. What you're saying to me, and I was just thinking as you were saying it, the A to B, the destination didn't necessarily change, but you did. The person on the journey changed and perhaps the people that are on the other end of that will change as well. It seems like a lot of our jobs as software engineering managers is to build environments rather than software. To build an environment where good software can be grown very similar to cultivating a garden. Do you see the role of the manager to be similar to that? Totally. I've used the gardener analogy before. I think to tie this back to one of your previous comments is that there really aren't ends. There are only means. Often, we don't really know where exactly we want to end up. We know if we're a gardener, we don't know exactly what the tree is going to look like. We just know that we want a Japanese maple that looks pretty and has blooms in the summer. We cultivate it and set the environment for it to grow and for it to be successful. I think that's the same with teams. We have a vision or an idea about the destination, but we don't really know where it is. It's very much about the journey and the journey becomes exploratory. Then, there's stretching the analogy a little bit, but making sure that everyone who is on the team and who is working towards that destination, that you get their perspectives and that they're able to contribute as much as they can. That was one of the realizations I had working with Evan Medium was that he's a big product of visionary, but he didn't have an exact picture of what he wanted to be built. He had a feeling of what it would be like if we succeeded. Then, we had to build an organization which helped him explore the path to that vision and to realize what the destination really was versus setting a line in the sun that we have to walk towards. When you said that you wanted a Japanese maple, in my head, I imagine that you said that they immediately translated that to, well, actually what you want is the feeling of looking at a Japanese maple. There could be many things that could get you there. I think often the biggest mistake that I see both in individual contributors, but also in other managers, is that they'll look at a request for a Japanese maple and instead of abstracting upward to what you want is the feeling of looking at the Japanese maple, they'll go down even further and they'll say, well, okay, so we want this specific type of Japanese maple and we need this specific kind of soil and we need these specific lighting conditions. It continues to add more and more in position to the work. That creates this kind of system of inflexibility whereas if you were to abstract upward as a manager, you're building inflexibility to the process because there's many pathways rather than honing in on only a singular pathway. I think the other thing is that especially when you're talking about customers and product is that they ask for something that they think solves their needs. You have to dig a layer underneath and they're like, what is the need that they actually have and then how might you solve that? Often, they don't have the best idea of what would actually serve them. I think it was Henry Ford which was people who would ask for a faster horse. They didn't ask for a car. You have to get underneath the request and really empathize with their needs. I want to ask you a question on this because I've been thinking a lot about it lately and I talk to my colleagues, I talk to my family even, my wife is a product owner herself and I continue to kind of push this same point which is you ask about the underlying need. You say, okay, you're saying you want this thing but what is it that you want to do with this thing or what is it that you need out of it? You can continue with that chain of, but why do you want that? You want the sales tools so that you can increase your throughput and you want to increase your throughput because you believe it's going to get increased your revenue. There is a point where you can ask questions that will get back to fundamental human needs. I'm curious about in your experience, where do you stop on that chain? Do you go all the way to that human need or do you say, okay, we're going to draw the line here because we can't really meet everything. We have to choose our layer of abstraction. I mean, I don't have a great perfect answer. I think it's a judgment call. If you think about Maslow's work and everyone knows about the hierarchy of needs, there is actual books he doesn't talk about them as being a strict hierarchy. If needs aren't satisfied, if a lower level needs aren't satisfied, then you can't hope to achieve the high level needs. So in the organizational context, if people don't feel psychologically safe or don't have some of their basic emotional and psychological needs taken care of, then they're never going to be able to take risks or perform to their four capabilities. So I think it's definitely tricky and it is a judgment call. Then I think you have to also look at, is this system wide or is this individual? I think you start just answering the question or asking the question of what do these people need and then digging as deep as you can? In the context of range, we think about that a lot, which is that we're building what you described as a stand-up tool and people. I think when we look at the stand-up tool, we look at what people need to be effective. We've really drilled it down to three fundamental pillars, which is transparency, purpose, and belonging. So knowledge is power and in the regressive organizations, information is hidden in order to consolidate power. But often it's not explicitly hidden, it's just not publicly available or it's not in a format that you can use the access. So if we can create more transparency around what's happening in the organization and artifacts that are being produced like documents and designs and decks, then people have more knowledge and then they have more context and then they're able to better make decisions themselves. And then if you make decisions to yourself, you're empowered. Whereas if you don't have that information, then you have to rely on other people. So transparency is one of the things we think about in the context of range. And then purpose is, you know, burnout is a big topic at the moment, but one of the biggest causes of burnout is not really understanding how your work fits into the big in picture. So if you can help, if someone can understand on a day to day basis that this work is important, even if it feels repetitive, then that can really help them feel more engaged in their work. And then the final piece is belonging and that's the precursor to psychological safety. So micro moments of vulnerability help you trust the people around you. Once you trust people, you feel a sense of belonging and then that belonging is what creates the environment of psychological safety and then you can take risks and push yourself and challenge yourself in ways that wouldn't be possible if you didn't have that sense of safety. Yeah. You mentioned something so interesting a moment ago about how it's not necessarily hidden, but it's not visible either. It's this idea that it's almost accidentally obscured. Yeah. Yeah, totally. It's often, it's not intentional, but then say that you got, you started hearing about a project that was going on and you didn't know about it and if you were not safe, like if you were in a psychologically safe environment, you would just say, hey, what's going on with this project? But if you were psychologically safe, you'd be like, oh, is there a reason that I'm not being told about this project? And maybe they don't trust me or maybe I'm not seen as important and you start writing these stories and then that compounds and that makes you feel less safe. And then that, then you show up in meetings differently. So if you can work in the open and provide a lot of transparency in all the work that's happening in the organization, then a lot of these anxieties can be calmed. We'll get right back to my interview with Dan Pupius right after we talk about today's sponsor, Square. Unless you've been living under a rock or you don't take payments online, then you've probably heard about Square. In fact, you've probably used Square, even if you didn't know it. Square builds the Square terminal. It's an all-in-one credit card device that has a 5.5-inch corner to corner touchscreen that's super easy to disinfect, which, as it turns out, is pretty important right now. It operates wirelessly with a long battery life and a built-in thermal printer for safe distanced payments. And most importantly, to you probably, it syncs seamlessly with your app via the terminal API to accept Apple Pay, Google Pay, and other NFC payment methods plus MacStripe and chip cards for a smooth checkout experience. Apple API is also compatible with pretty much anything you are probably working on right now. For example, it's very easy to integrate with basically every mobile platform, like iOS, Android, Flutter, React Native, or Windows applications. And Square has your back. With Square, if you build with the terminal API, you can take advantage of Square's end encryption, dispute management, and fraud detection. Select your app to the all-in-one payments device that merchants love with a simple-resty API. Head over to developertea.com slash square. That's developertea.com slash square. Thanks again to Square for sponsoring today's episode of Developer Tea. Yes, yes, yes. I want to talk a little bit more. I want to dig in on this subject because I think the idea of having this in your framing is as psychologically safe or psychologically unsafe environments, I think there's also some human bias that we bring to the table, the negativity bias, where if there is a void, we're going to tend to fill it with something with the worst possible thing, right? Or at least a suboptimal thing. In this case, you didn't know about the project, and so the natural belief may not be extreme, it may not be the worst possible thing. But the natural way to fill in the blank might be there's a reason that I don't know about it, and it's because of a shortcoming that I have. I mean, I think it comes down to trust. And trust has a half-life. It degrades. So when you're looking at groups, you have to have these renewals, these belonging cues that make you remember that you're all on the same team and that you're not going to attack each other and steal each other's food, and it goes back to very basic instincts from early in the evolutionary history. So this again ties to good work practices, where if you can create these micro moments of vulnerability every day, then you've basically renewing the belonging cues that create trust. And then you're less likely to write those stories. Yeah. And those stories are so often implicit, their beliefs that we almost don't even realize that we have. Would you agree with that? Yeah, I think it's survival instincts. So I think it comes down to some very base, base evolutionary needs. And the strangers are risky. And what we're talking about is that in a work environment, we lose the perspective that we're all on the same team and that we're on the same group and we're marching towards the same goal. And it can become combative and conflict can be not healthy. Healthy conflict is dialectic of perspectives. Unhealthy conflict, yes, can easily slip into the picture. What I find so fascinating about this discussion that we're having right now, if anybody who's listening to this, myself included, has gone to any kind of therapy, particularly if you've ever gone through anything like CBT, cognitive behavioral therapy. These are the kinds of things that are discussed, the idea that we catastrophize, for example. But most of the time, the prescription is to think through and try to kind of judge from the outside looking in, imagine that you're an impartial third party looking at your own scenario. But I think the issue that we face is we can't ask people to approach their work with that level of intentional self-awareness without also meeting them where they are. In other words, creating the environment like they're saying, building or tooling in a way that respects that underlying survival instinct and tries to design an environment that doesn't fall prey to these baser, unproductive instincts. Yeah, totally. Yeah, it's not an individual problem, it's a systems problem. Yeah, it's absolutely about the environment and making it so people can show up. I mean, slightly related, but one of the things that's been very influential for me is the work of Robert Keegan of Harvard Business School and cognitive development levels. Him and Lisa Lehi did a bunch of research into adult cognitive development and identified these milestones, which have people make meaning. And over a course of a day, you're fluctuating between these different levels. It's not like a purely linear progression. But the base level is just instinctual behavior. So if you're out on the street and you get attacked by a rubber, you're going to have an instinctual response. And that is contextually appropriate and healthy. But you don't want that instinctual response in the workplace because that leads to behavior that is just not appropriate. The next level up is a very egocentric view of the world, where it's very right and wrong and black and white. And that's why you start to think that these people might be out to get you or their hiding information. And it's a very mis-centric view of the world. And then the level above that is, your mind literally makes meaning through the group dynamic. So it's a socialized self. And you think about yourself in the context of the group. And that's why you have these sort of more egalitarian feelings and altruism. And that's, if you're at the pub with a group of friends, you're going to be in that level, the socialized level. So if you can create that environment at work, that's just a much stronger foundation to have creative discourse. Whereas if everyone's in these lower levels of either the egocentric self or the instinctive self, they're going to be very reactive and not thinking through things from a kind of like a group. What's best for the group? Yeah, that is. So I wonder when you're saying that, that this kind of the highest functioning self is one that's in a social atmosphere or a social, kind of the social identity group identity. There's actually levels above that, which, oh, go ahead. So the level is above, actually, when you then detach, your ego then detaches from the group. And you think more institutionally. So the group, the socialized mind has a bunch of strengths, but it can also, it has some downfalls, like group think or being in group out group. The next level is where you think much more institutionally. And it's a very interesting progression and it's been very useful for me in sort of analyzing and diagnosing organizational behaviors. Can you give an example of the institutional thinking? How might that play out in a workplace? So honestly, that's where the most creativity happens and that's where you can avoid some of the downfalls of the in group out group. And you think it's sort of from a perspective that's slightly decoupled and depersonalized. So you don't think of, are the marketing team are idiots? Because they're not doing XYZ or the infrastructure team are letting us down. You think more of the system and the perspectives and that's where empathy occurs and understanding these needs of different groups. The Robert Keegan talks about that as the institutional self versus the socialized self. Very interesting. I wonder if there's two questions that come to mind when you describe these different selves or kind of the layers of identity. The first question that comes to mind is, do you think there's a time or do you think it's possible for that institutional kind of detached self to get confused with the egocentric self, especially if you're aware of this framework. I can imagine that happening. And the second question that comes to mind is, is there, it seems that there might be a suppression of individualism or because you're kind of graduating beyond that egocentrism, how does that kind of combine with respect for our individual differences and that kind of mindset? Yeah, I mean, that kind of what you're talking about there at the end, that's the definition of moving into the institutional space where it's where you have a very clear sense of identity, but in relation to others. I see. So if you think about, do you think about the support for them rather than antagonism? Yeah, whereas think of football supporters, their identity is so tightly linked to the group. And a lot of bad things can happen without you know, it's where the football violence occurred back in the UK and people get, I remember being in Manchester and there's like red shirts, blue shirts and you know, you hate the people in the other side because it's like so closely linked to the group. So yeah, so moving into these high levels is that you have this sort of sense of self-authorship and self-identity, but in relation to groups and the broader system. Ah, that makes sense. So I think that yeah, when we talk about going back to the environment, we want to create an environment which is defaults to this socialised mindset where people feel like they're all in the same group and on the same team that they don't have to worry about threats and like othering. But then that creates the foundation for jumping into these higher cognitive states where you can have healthy conflict and you can integrate people's perspectives and be more creative. Yeah, yeah, this, so this makes me kind of go back to range and wonder, you know, how, what are some practical things that you've done in designing building this software that integrates some of these philosophies that we've been talking about? I mean, a lot of this stuff is very much, I imagine, nuanced and small decisions can have cascading effects. I'm curious. So, you know, you know, you know, are particularly proud of or were really intentional decisions on your part? Yeah, at this stage, it seems simple and there's a few other products that are doing, and now doing some of the things, but we, every day with your check-in, which is again, like a bit like a stand-up, we ask a team building question, and then when you, and you share your mood, and a few years ago, people would be, I don't understand why you do that. Like, there's just focus on the work, but it actually ends off being really, really impactful. So, showing your mood as an emoji, and then, red, yellow, green, traffic light, is this moment of personal introspection where you're actually trying to, like, how am I actually feeling? And too often, people don't have that moment. So, choosing it is interesting. And then when you share it, there's actually some like, depersonalization in the sharing, where you can share this emoji, which actually might seem silly, but it's less risky than the start of a meeting saying, I'm really tired because my daughter wasn't sleeping, or I'm feeling really anxious today, because I've got so many things on my plate. So, you can just use a grimace emoji, or like a sleep emoji, and it actually makes it much easier to share how you're doing. And then, the rest of your team have that perspective. And we often hear from customers where they, you know, you have a manager or a teammate who didn't know that someone on their team was struggling. But this emoji then allows you to have a conversation. So instead of saying, like, why are you tired, or like, why, what you've seen stressed, what's going on, you can say, like, hey, what's the story behind the grimacing emoji? Or, like, is there anything, like, I noticed you were yellow today, is there anything I can do to help? And it actually, it makes it feel less judgmental and more safe. So, that's like one of the things that we did early on, which many people thought was silly, but has been surprisingly impactful for both our own team and our customers. Yeah, I've, this is a practice that I, in a totally different way, have implemented on in my one-on-ones as well as in our stand-ups as much as I can. And the way that we practice it is, is similarly very definitive and normalizing. I ask for a kind of a one to seven. You know, how are you doing where seven is the best possible? And then one is you're doing quite awful. And what I've found is the number becomes important for a couple of reasons. One, it forces people to take what is otherwise a non-quantitative internal feeling and try to balance it and figure out all things considered. And so, this can actually, I've seen it actually help improve people's myths just on its own, because they say, internally, I can kind of see the wheels turning and I've done it for myself as well, where I had, you know, somebody cut me off in traffic and we know this from research that small, bad things can have a disproportionately negative effect on your day, on high, on your mood. But then I'd start to take into account how I'm doing in other areas and once I assign something to it, when I say, okay, you know, I really have to try to do it. I try to assign a real number to this. I realize that I'm actually doing better than I thought I was and it's kind of this weird observational sense that I get that I otherwise wouldn't have had, that I just kind of, I'm feeling my feelings otherwise, but now I'm kind of observing my feelings. Yeah, and it's always happening because somebody's saying, what number are you? Yeah, it's essentially a mindful of this exercise where you check in with yourself and you get out of autopilot and we're so often we're not conscious of how we're feeling or how our body is or the tension and all that then affects how we communicate with each other and how we collaborate. So if you can bring some self awareness to how you're actually feeling and what tension you're carrying and then that can actually calm some of the transferences as the psychological terms, the transferences that are coming from those like feelings. So yeah, it's very, very, very important. Hmm. I'm curious what got you interested in this deeply psychology-based understanding of product? Was there a moment in time or was there an experience that you had or a book that you read or something where you said, wow, this is really the core of what I care about. Yeah, yes. So I did this. So I got really interested in how teams work as the starting point and rethinking management structures to really help people feel empowered and not be more like these sports teams where everyone is playing in everything's dynamic and in the moment you're not being directed by someone. So everyone feels like part of the game and that got me into, I think, about the conditions and like group dynamics and that led to the psychology and then it was a leadership training program that I was a part of that really opened my eyes and it kind of just answered a bunch of questions around like how people behave and why things unfold in really just like eye-opening way. So that was like the, and I got really interested in that and this, and that was, that lead to the concept of psychological transference and then I read a bunch about that and how therapists use it in the therapeutic process and it's just like a really interesting empathy exercise and trying to, like, the meaning of communication is so much of it is subverbal and so much of it is actually the, is interpreted by the recipient and that dynamic is just like super fascinating and then you can see when it goes wrong, it kind of just like snowballs and all these reasonable, seemingly reasonable people are making rash decisions and behaving really inappropriately. So just like understanding the dynamics it became just very interesting to me. Thanks so much for listening to today's episode. My interview with Dan Pupius. Thank you again to today's sponsor Square, head over to developertea.com slash square to get started with the terminal API. If you don't want to miss out on the second part of my interview with Dan, head over to whatever podcasting I've been currently using just open your phone or your computer or whatever and subscribe in that app. That way you don't miss out on future episodes and if you want to join the Developer Tea discord which is a group of developers like you and myself all chatting in discord which is a fantastic platform by the way. Over to developertea.com slash discord you can join there. Thanks so much for listening and until next time, enjoy your tea.