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 Develop a Tea. In today's episode we continue our discussion with Dan Pupius. 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 and you encourage you to subscribe and whatever pie-cassing app you're listening to, this episode with right now. Let's get straight into the interview with Dan Pupius. Yeah, that's the psychology of a working team. Organizational psychology is exponentially complex 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, you know, pathological type study of an individual. You almost have to approach it from an observational perspective. What are teams doing that is working and you know, 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 and 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 have the right skills. 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 industrial revolution where they were building complicated systems so that there are big factories with many moving pieces or 2,000 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. Yeah, we're still using these management practices that assume that systems are complicated and knowable. So that was one of the things that I was really interested in is that what would the 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. They just fundamentally shift your mindset. Yeah, I wonder if people, even those who are practicing some of those management tactics if they realize the etymology of them, the 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 panacea of management being the ability to automate everything. Right? That's the, 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. And allowing the variability to be part of the, 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. So there's like simple labor, which is, which is reducible and probably on a long time frame 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 you, and you know, that's, that those systems have emerged over the last few decades and become the form of work. Yeah, we're managing it like simple labor. And one of the things that like I realized that like made my head hurt and maybe want to learn more is like, why do we structure organizations in hierarchies? So we have to engineering hierarchy and then 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. But 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 like start from where the work is happening, like, how are these people collaborating? How is the team working? Who is in, you know, who is playing the game? How do we structure that work? And then 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 is more networked. You start thinking about performance management differently. You think about communication differently. So that's what, that's how I got into this. It's just thinking about like 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 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 I see is that I mentioned already. So what do you see as the opportunity for those groups of people? I mean broadly for all groups, I think it's about making work better. And so much of our lives are spent at work. 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 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. And so that's the altruistic, it has to be a balance. So that's 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 all that feeling and emotional connection to the impact of their work. Because 40 hours a week is a lot. So if you're understanding that much time, it should feel more rewarding I think. Yeah, yeah. I imagine that if, let's say we have three engineers on a team and two of them begin to be more emotionally vulnerable on that team, that the third will likely see that. And 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, a more mindful way of working or human centric, you can still begin to communicate in ways that are more human centric. You can begin to surface things or simple heuristics, for example, I've seen these work well. If you make a channel in, let's say Slack or something, you have to have a very good reason to explicitly make it private. Right? So there should be something like almost a legal reason. Very similarly, if you're sending a direct message, there should be a very good reason that it's not going in a public channel. And the idea here is not that there are never any reasons to speak privately with somebody. Of course there are, right? But most of the time we default to communicating in these channels that are not public out of some incorrect understanding of our culture, right? 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 this, 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, and 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. I mean, like principles. Yeah, something that I could say, okay, this, very simply in any situation this can apply. Yeah, I mean, there's a little bit of a contradiction, which is that like a lot of these solutions and principles have to be context specific. And around no one's high spits all, like 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 I'm forced people to think about that. Create moments of safe vulnerability. And it is, it does compound that 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. And that is the type of vulnerability we're talking to. It doesn't mean you have to open up about your darkest secrets from childhood. 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 if like sprints as being generally a cadence of work and output, 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 to do some work and come back together that make you really feel like you're growing in the same direction or all in the same team. And humans are incredibly ritualistic. Throughout the ages, people would have regular meals and you have Wednesdays when we go through X, Y, Z and Sundays when we go to church. Three times a year we have these big feasts. And all those rituals serve the purpose and a lot of that purpose is around like creating a belonging in 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 or 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 kick off meeting. And then throughout the cycle, we have these touch points. And really building that rhythm and that drum beat 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. 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 be in place for useful feedback to flow. I think there's another interesting aspect of this that happens between different layers of the organization, particularly we were talking about hierarchy earlier, your cadence, your individual cadence, especially if you're in a different hierarchy 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. Because your manager is going to have their own meetings and their own concerns and their own incentives, etc. And so what feels like a very important meeting to one person may not feel like a very important meeting to another person. 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 your one-on-ones or your perception of your team's stand-ups is going to be fundamentally different from your team's perception. And you have to develop empathy to understand that they really care a lot, probably. There's very little downside to you caring a lot about your one-on-ones. There is a lot of downside to you treating them flippantly. And this is using with stand-ups. I think it's really important that the way I start to think about this is almost like visualise the network and I think about organizational distance and also the number of edges. So if you have 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, I know, some managers have crazy number of reports, like 14-one-on-ones over two weeks. Just by definition, your attention is going to be split more ways. So having empathy for how other people fit in this system of work and what their relationships are is really important. And once you start to visualise this, you can then start to think about where are their opportunities or deficiencies. Maybe this person only has a one-on-one every two weeks but doesn't have any other interactions with people on a human level, only 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 to have that human connection? And then the other aspect is that the cadence of the organization has to cater for different bandwidths of communication. So if you're a director and your three levels removed from the team, your bandwidth needs to be much lower than if you're a PM to an edge team like the bandwidth has to be really high. So then you have to cater your communication to the bandwidth. So the stand-up teams do day-to-day or the stack channels or whatever. That's a high bandwidth 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 then you have to design communication protocols that are more like contextually appropriate for those bandwidth channels. And much of that's too like intellectual or like over-the-top. It helps think about 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 new view 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 $100 in free credit for listeners of Developer Teawhether 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, 7, 365 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 $100 in credit on S3 compatible object storage, managed Kubernetes and more. This is worth it just to try things out and have a little sandbox. You have nothing to lose here. If it runs on Linux, it runs on Linode. Head over to linode.com slash Developer Tea and click on the create free account button to get started. This is Ginalino for sponsoring today's episode of Developer Tea. Yeah, the problems are not necessarily incredibly complex to solve, but I do think it's much more about empathy than it is about anything else. It's about understanding that these different layers of organization, this doesn't require a huge algorithm to solve, I guess, is what I'm trying to say. This is very much a human problem and much of it can be solved with adopting these heuristics of, put yourself in their position. One thing you could do is open a tab on your Google calendar and turn off everybody's calendar but somebody who reports to you and just kind of feel, get the feeling of their schedule. What does their schedule feel like? There's not really an easy way to put that into, we're talking about emotions here, right? This is a very difficult thing to put a perfect process around. If you can understand how somebody else might feel and to your point, 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, totally. If I understand that, hey, if I'm asking you 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. That seems like a much more personal and intimate thing for me to ask for. Totally. This is part of what we're trying to solve with range is that situation awareness and the passive sensing of what people are up to and how people are doing. If I bring up, like, Steph on my team, she's an engineer. I see her plan for today and she has two one-on-ones in a cycle recap. This 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. If I looked at that and saw that she was in like six hours of meetings, 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. I wouldn't then need to bug her or feel micromanaging about the status. I think yeah, visibility and context of what people are doing is super critical and too many of the work tools purely focus on commits or tasks and that's not the full picture of the person. We have to take into the interviews and all these collaboration meetings that get essential. Yeah, I've heard it described as glue work. Probably in the notes, but the idea that especially as you move up the chain, so to speak, as you're responsible for 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. It can also get the visibility can also be important for coaching people. 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. With limited visibility into what they're doing today, you don't have the empathy or understanding for why that is. They think it's important and may have some organizational importance but isn't the key line of work and that becomes the problem? Maybe they're 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. At that point, you get some visibility into what their week looks like and you can coach them on. The work really need to happen is it critical that you could do this, could someone else do it or are these meetings actually essential and can you defrag your calendar to give you more focus time? I think often we have performance problems related to these systemic effects that can be corrected once you have a good picture of what's actually going on. I love that visual of defrag, imagining my calendar just being shrunk down to these. Yeah, it's blocked. I did 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 how many hours were you in meetings? Also, it's kind of not intuitive but I find it fun to include which is a focus quotient. The focus quotient is 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 is just dead time. Then you can figure out 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 relative to the efficient? Yes. Yeah, absolutely. Again, this goes back to what we were talking about before where we treat our time as these easily programmable blocks, almost like memory on a computer but there's change over. 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 reviewing those calendars. The other things were all different as well, we're not the same and if you look at circadian rhythms, I'm sure people have heard about the lock versus the owl and I hate the 9-5 primarily because I am not effective during that schedule. For my whole career I felt that was an oppressive time structure and I'd much rather start working around 11, take a break in the afternoon and then work late into the evening and in some organizations that's not socially acceptable because working in the evening is frowned upon and not being at your desk at 9 a.m. is frowned upon as well. The 9-5 again goes back to manufacturing. It doesn't have any practical utility for knowledge work where you have to have creative thinking. So I would often, when I went to Google I would often go to the gym at 11 o'clock and then that would actually unlock things in my mind like just doing weights or running or swimming and then I'd come back to my desk and have all of a sudden have solved this problem that otherwise spent three hours like banging my head against the wall to try and solve. So I think if we can start breaking down these artificial structures and create work patterns that allow people to be more flexible, then people can start to design their work habits around their own logistical and energy needs. Well the statistic is interesting as well, every day at 4 o'clock I pick up my daughter from school so it has to be acceptable for me 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 an engineer working at a big company would I be getting dinged on my performance review for being absent during the afternoon every day? Right, and strangely being a good father is antithetical somehow to being a good engineer. That seems wrong and it seems that 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. But again we go back to that complexity problem where how do you calculate that impact? There's not enough, we don't have enough context to be able to calculate it and so I think what you were saying in the beginning 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 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 what the thing that's going to help me meet the subjectivist 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, we often talk of work life balance. I think balance is a nice metaphor but often it's like work life tension and instead of thinking of a weighing scale that balances both sides it's really a string that you're stretching in both directions. That tension is painful and you feel torn because you want to go and be a good father and pick your daughter off in school but you also want to be a good employee and a good teammate and you feel the tension in the other direction. That's totally how you're enough feeling stressed and anxious and that's not how 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 good. We're approaching well over our time actually at this point but I do want to give some of my own sannos. 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've discussed and why 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. That could also go on 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 second version 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 2000 years and we put our soul into this artifact but that is obviously not true and it shouldn't be true and really the purpose of our work is to create an outcome for people into server 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 you know building a sand castle on a beach and the most beautiful sand castle 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 like focus on like 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 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 dovdovdovrange.co. We have a blog that you can go there and writing.ppias.co.uk is my personal site and yeah happy to offer discount or like an extended free trial if you're listening, just hit a sub-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 in for providing that to listeners of the show. Cool. Yeah, thanks for having me. It was a great fun to chat. Another huge thank you to Dan Pupius 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. HevertoLinode.com slash Developer Tea. 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 Tealisteners and myself in the Developer Tea Discord community. Head over to developertea.com slash discord to sign up for that today. Thanks so much for listening to this episode. If you don't want to miss out on future episodes, subscribe and whatever podcasting app you're currently using. And until next time, enjoy your tea.