In today's interview with Aaron Upright, cofounder of Zenhub, we talk about being forgiving to ourselves as developers.
Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up.
A new season was released on July 14th, in which Author Clive Thompson joins host Saron Yitbarek to share his insights from over 200 interviews with coders for his latest book.
This 3-episode mini-season will cover: the many paths to a coding career, where coders work, and what coders expect from each other.
Head on over to the podcast platform of your choice to listen and subscribe for free to Command Line Heroes.
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.
you know, as a developer, no matter where you are in your career, I don't think that you should ever just accept that this is the way we do things because it's been done that way in the past. And I say that as a founder, because a lot of the things that I did in the very early days of, of, you know, building and, and, you know, creating process are not things that we really intended to scale. It was things that really worked in that period of time for the people that we had in the room. And again, if, you know, if that's just kind of the way that things are done and now everyone's doing things in that way, and no one's really questioning that fact of, could we do this in a more efficient way? Or could this be done in a faster way? Or could we do this with less people or with less process or less overhead than that progress? And that change never really happens within the company. And you just kind of become this, this, you know, I guess for lack of better terms, you don't really evolve as a company and just kind of stay very static, I think, to where you kind of started. And everyone just kind of thinks in very much the same way. And no one's really focused on, how do we, how do we do more with less or make things more efficient? So I think documentation is a huge part of that too, because it really does help people understand why you took certain decisions. But also it can be, you know, provide evidence for maybe a lack of framework around things where people would otherwise just accept it, but say, Hey, maybe there's a better opportunity to actually do this. It doesn't look like that much thought was actually put into designing this particular process or figuring this particular framework out. You know, maybe it's time for us to think about this or change how we think about this because there's a better way of doing things. You just heard the end of the first part of my interview with Aaron Upright, co-founder of ZenHub. ZenHub is project management software that is directly in GitHub. It is a browser extension. On these episodes, we talk about project management from a very high level. And in this episode, we talk about being forgiving to ourselves, amongst other things. So I highly recommend that you go back and listen to the first part before you get into this part. My name is Jonathan Cottrell, and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. On today's episode, we have Aaron Upright, co-founder of ZenHub. Let's get straight into the interview with Aaron Upright. You know, if we were to take a big zoom out view of 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 as if we are reliably creating that data rather than by happenstance. And the truth of the matter is when you change really anything about a team, you can have drastically different outputs. You can have totally random inputs that cause completely different outputs, right? There's so many things that can happen as a result of even the simplest changes, even the simplest circumstances. Somebody gets sick, for example, right? These are things that don't happen in the same way with machines. And yet, we evaluate humans very often mechanistically. And what we could do instead is take a step back and say, okay, we're going to allow for variability and we're going to look at the long tail. We're going to try to optimize based on the data, but we know that it's going to vary. We're going to expect it to vary. This is a much healthier way. And it keeps you from overtuning on those responses and jerking your process all over the board. And instead, focus on how can we create the healthiest place, the healthiest environment for our developers to work in, and then kind of sit back, right? Let things kind of grow, wax and wane. They're going to increase, they're going to decrease. They're going to decrease, they're going to decrease, some weeks are going to be better than others. And we have to be forgiving in those environments. Yeah, for sure. I couldn't agree more. And there's this concept that a lot of what estimation ties back to around velocity, which effectively you can think about is how many story points or how much can you accomplish over a given time period. And I talked a little bit about our sprint process being two weeks, but the idea is to have a relative understanding of how much work a team can take on over that time, where that gets to be a really, really tricky metric, though, is where people use that not to help decide how much work should be brought into the next set of sprints, or how much we can take on as a team. But that starts to be an anchor point to measure productivity. We should know that velocity is going to change, like you said, from sprint to sprint, because people could be out sick, people could be dealing with personal things in their lives and just less productive. I mean, all of us are going through right now a pretty shared experience around this whole COVID thing where we're all working in very, very different environments and different setups that we typically haven't had before. Velocity by design, I think, is going to fluctuate from sprint to sprint and iteration to iteration. And it's more about knowing relatively how much we can do and having that relative understanding and saying, hey, if we didn't hit the 60 points that we typically hit for the sprint, something has gone wrong and we need to look for people to blame and for factors that within our control or beyond our control contributed to that and address them. It's a relative anchor, and I think one of the cool things about velocity is, yeah, maybe you have a sprint where instead of getting 60 points done, you've got 50 points worth of work done. But on the other side of that, there's always those sprints where maybe you got 70 story points worth of work done where the perfect conditions kind of just came together to create this amazing working dynamic over those two weeks and people were uber productive and in the zone and really into what they were working on and we got a lot done. That variability happens all the time. And so again, I think if teams are using that metric, like you said, it's going to fluctuate from sprint to sprint to iteration to iteration. And so I think it's going to fluctuate from sprint to iteration to iteration to iteration to iteration to iteration to Like you said, it's not about holding them accountable to that specific number of points, but using that as kind of a framework or a reference for how much we should be taking on over time, knowing though that that is oftentimes not always going to be the case. And there's things that are going to happen in our lives and things that are going to happen in our working lives that kind of prevent us from doing that. So this is maybe a slight tangent, but I think one of the most powerful aspects of this whole COVID experience for me is that, like you said, it's humanized a lot of things that I don't think really have that human element and that aspect before. And what I mean by that is that personally, and I know for a lot of people, that they've been way more considerate of the interactions that they've been having with other people, because I think it's easier than ever to kind of empathize with what people are going through. And it's really forced me, I think, to think about the interactions that I have with people in a different way. Even as a pretty conscientious person, you know, and someone who cares a lot about the relationships that he has with other people, it's just forced me to think about things in a slightly different way. And it's also really exciting to me to think about things that I have with other people. And like you said, I think it's really important to consider that on the other end of that code, which, like you said, is a very mechanical output, there's a human being that wrote that. And knowing that people are going through a lot of different changes, some more than others, really puts things in perspectives and really helps, I think, frame the way that we communicate with people, the tone of that communication, the patience that we have with other people. And so I think that has been a real, if you will, a really important part of my life. If you can find kind of a silver lining of all of this, for me, something that's really helped humanize a lot of the aspects of work and kind of remove just the, hey, we all show up for work every day, get our things done, and then kind of go home. It's never really been the attitude, but at least for us, but it's really now something I'm conscious of, of how are people thinking and reacting in this moment? What are they going through? What are they stressed about outside of work or outside of the situation? How is that going to impact our velocity or productivity? How do we account for that and be okay? And, you know, tell people that, yeah, maybe this was a tough week, or maybe this was a hard thing to adapt to, but we're okay with that because we grow and we learn as an organization. Yeah, it's interesting. There's this theory that any time a measurement becomes a goal, and I'm sure you hear this all the time, that it no longer is a valid measurement, right? Because you're changing the basically changing the game, right? There's new incentive. And when you measure something, theoretically, you should not have incentive at all. You're just taking a picture, right? But when you try to take a picture in such a way that it comes out looking like a particular thing, now that measurement has been distorted, or it has the likelihood, a higher likelihood of being distorted. And so this is one of the ways that, you know, we can measure things. And I think that's a really important thing to do. You could think about planning with, you know, whatever you want to use, the points or the t-shirt sizes, whatever the thing is that you're counting up and you're saying, okay, this is how much work we got done. The moment that you start changing that conversation, I would say, you know, you say, we got 60 done last week, we're going to do 65 this week. Well, now there is a lot of new information, right? The engineers are now potentially they're going to as a very simple example, and not necessarily, you know, with some malintent, right? They might start inflating their estimates. So that 65 is easier to hit, right? Maybe they are actually maxed out. Or, you know, on the flip side, you might actually see those estimates start to start to get smaller and smaller so that when you say, hey, let's try to get better next sprint, it's easier to get better, right? And yeah, I completely agree with that. I think there's always that opportunity. And even if it's not with malintent to kind of gamify the scenario of trying to get to that level. And, you know, I think where this gets really disruptive for teams too, is where you focus more on the points that you're trying to get accomplished than on the actual work that you're doing. And what I mean by that is, are you actually working on the most meaningful things that are going to move the business forward and actually, you know, contribute to your end goal? Or are you just picking up things because you know you can accomplish the points in a given sprint and hit your velocity, right? Meaning that are we leaving really important bugs on the table or like really important pieces of technical debt that we're actually neglecting that are going to really hurt us later on? Or even are we focusing on those things at the expense of building new features that actually enhance the experience for our users just because we know that we can get those points done and it'll look good and we'll be able to hit our velocity. At the end of the day, you know, that's not really what we're trying to do here. We're trying to build a great product or so many of us are trying to build great products or build great experiences or build great solutions that people use and provide value. And if we're just focused on, yeah, we hit our points, I think it kind of ignores that aspect of, yeah, but is what we built actually valuable to our users? And did we actually ship something of user facing value in this sprint? Or did we just go through and just kind of hit our point total and yeah, we're happy with that because, you know, we can check that box of meeting our velocity. We're going to take a quick sponsor break and then we'll get back to the interview with Aaron Upright. Today's episode is sponsored by Red Hat and Command Line Heroes. Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up. And it has returned for an all new season. It came out on July 14th to explore the job of being a coder. Author Clive Thompson joins host Saranya Barik to share her experience with Red Hat. his insight from over 200 interviews with coders for his latest book. This three episode miniseries or mini season rather will cover the many paths to a coding career, where coders work and what coders expect from each other. Past seasons have ranged from the history of open source to the origins of popular programming languages. And most recently, the creation of revolutionary hardware. Head on over to the podcast platform of your choice. For example, the one you're using right now, the podcast platform of your choice. And if you're interested in learning more about the podcast platform of your choice. For example, the podcast platform of your choice. And if you're to listen and subscribe to Command Line Heroes. Aaron, thank you so much for taking time to talk about this with me today. I really appreciate what you're doing. And the product that you're building, making developers lives a little bit easier and lowering the number of places that we have to go to be able to be productive. It's incredibly helpful. You know, I have a couple of questions I'd like to ask you before we wrap up here. And it's questions that I ask everyone who come on the show. The first one is what do you wish more people would ask you about the future of the software? And if you could just tell us a little bit about that. Yeah, it's a good question. Internally, and this is something I think our team does pretty well, but I wish they would ask even more about our customers, our revenue, our business and how it's going. I think a lot of leadership teams try to shield developers from the business side of things. And I think that's really wrong, because to me, that kind of sends the message to developers that, hey, you're here to build features, execute on our roadmap, not build a business. And I really love it when our developers come to us and say, why are we doing this? Why are we doing this? Why are we doing this? Why are we doing this? Why are we doing this? How does this connect back to our mission? Or how does this connect to the vision that we have? Or, hey, I disagree with what we're building here or how we're building it. So I would encourage more developers out there to ask questions of the business. And I wish more people even at Zenhub would ask me about the business on a week-to-week basis. I guess externally, I think about that question. What more people would ask me is just how things are going or how you're doing. I think there's a lot of ups and downs in building a business. And we all have good days and bad days. And I think that's a good question. And I think that's a good question. And I think that's a good question. I used to be incredibly business-focused. I'd show up at a one-to-one and just launch into the agenda without taking time to ask people how they were doing, how they were feeling in that moment, how their week was going. And when I started doing that, it really changed the tone of the conversation because you're giving people the opportunity to kind of say, hey, it's actually been a tough week. I've been dealing with this thing at home or this personal thing or been really struggling to try to find the time to do this and putting this off in my personal life. And that's now spilling over into my work life and my ability to get out of my work life. really important. And I think that's a good question. And I think that's a good question. And I think that's a good question. over into my work life and my ability to get stuff done. So just acknowledging that and giving people the opportunity to talk about how they're doing kind of changes the conversation. And I've tried to get better at doing that myself. So I think that's something I'd recommend more people just maybe ask and something I wish more people asked me to. Yeah, absolutely. That actually brings me to another question that I had on my list for you. And I suppose it's completely relevant to ask you this. What was a moment on your path? Where you felt like you had no idea what to do next? You didn't know what was coming next? Maybe you felt like maybe I'm going in totally the wrong direction. You're in the dark in a lot of ways. And perhaps even it was, you know, personally difficult in that moment for you. Do you have a story about that? That kind of moment? Yeah. So in the in the fall of 2016, GitHub launched a competing project for those of you who are using GitHub out there. And it was called the GitHub Outlook. And it was a project that was designed for GitHub platform evolution. At the time, GitHub was designed for evolution evolution, and evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution you'll know called GitHub projects, which is a very kind of, we'd say simple and intuitive task board that kind of sits on top of GitHub issues. And that, at the time was very much the space that we were playing in. And it was it was really difficult, we found out about the feature two weeks before it was going to launch at an annual user conference. And for those two weeks, we we knew what was going to happen, but we had no ability to react to it in the market, because we were essentially under NDA and had kind of learned about this through a privileged relationship that we had actually had with the GitHub BD team. And it was really tough, because we had spent several years building this business, we had more than 1500 customers at that point, we were more than or across the million dollar mark in terms of recurring revenue. And I really felt like we were just starting to hit our stride as a company. And so many great things were happening. And then just out of nowhere, this kind of came up. And I just remember thinking at the time, how did this happen? Not because we didn't think it was ever possible for GitHub to get into the space and to kind of cross over. But just the way I think that it was happened in the way that it was framed was was pretty blindsiding as a partner, I think. And GitHub for years before that had been kind of touting that it was all about its ecosystem. And then all of a sudden, this news came out and it happened. And it seemed very contrary to that message of supporting this best of breed approach and supporting this ecosystem. I think another really tough thing about that, too, is that there's a lot of people on the business development side of things as well, that were kind of the last to find out about this. And they fought really hard for us. But by the time they knew about it, it was already something that was committed to it was built and leadership at the time was really convinced that they wanted to launch this. And there was nothing that either side could really do to stop that. And you know, I could tell for them that that was a really hard conversation, because they got a bit blindsided internally about it as well, and had to come with to us and kind of be the bearers of bad news and all of this. And it was a particular low point, too, I remember thinking, you know, and, and wondering how our customers would react. And it was frustrating for me, because I think it really did confuse our customer base. And we'd worked really hard to kind of build that and listen to what people wanted to hear and build that into our product. And then overnight, it seemed like we had a ton of people coming to us with questions and kind of, you know, with with not necessarily being confident about where we were going in the space and not really questions that we had good answers for. And as a founder, that doesn't really feel good. And, you know, the other side of things, I felt kind of bad for the product team at GitHub, too, because I could tell that they'd obviously spent a lot of time building this, I think they expected that more people would use it. But it really wasn't close from a feature capability to what some of the other products are as included in the space could offer. And so it wasn't really used. And it was just kind of this perfect storm of being really disruptive to our business, but not very additive, I think, to their business at the time, and a lot of uncertainty around that point. But I guess to end on a more optimistic note, you know, as with so many of our customers, we've had a lot of issues with our product team. And so I think it was really important for us to kind of get a sense of what we were doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing. And I think that's what we're doing think we often find are often you know find happens now is that projects becomes kind of this on-ramp for zen hub where you get started with that you know you get uh kind of used to this feeling of managing a project inside of zen hub and then when that project gets more mature uh sorry managing a project in github i should say and then when that project gets more mature you start to look for other tooling around that and uh anecdotally i think about now a third of our customers that are coming in have actually had some experience with github projects and have tried that and realized that they really like that approach but they need something that's a bit more powerful a tool that can bring in that concept of estimation and help them measure their velocity and help build a roadmap so um so yeah i think kind of tying it all together that was a difficult time but led to a lot of really powerful learnings and actually um got us to a really powerful place as a company and it's worth kind of mentioning that you know github as well as a very very different company today and um a lot of that turnaround started when when jason warner who's now the cto entered the picture and brought a huge sense of maturity to the leadership team and model at github and a ton of respect for jason and what he did as a leader and obviously nat coming in to kind of supplement that has been phenomenal as well so um so yeah it's kind of a i guess from a low point to a high point and a very optimistic now about the future working with github going forward but but interesting story i guess from from kind of the past and zen hub and github yeah absolutely and i think it's important to note that you know engineers uh we make things uh and products you know product developers we make things that eventually are likely to become useless and this is one of those kind of difficult moments right eventually uh the you know and and the way that you can think about this is if you look back to let's say the 70s or the 80s the kinds of things that software engineers were making then today are uh a snap of the fingers right like they probably were making calculators right well now that's that's not very useful and those certainly don't exist anymore at least in in that form and so it's likely and it may not necessarily be in the near future in fact we may see as much success as we ever wanted to see as we ever kind of set out to see uh for a given product but eventually all things will change and they'll be replaced and so we have to accept that going in that change is inevitable and uh and it can be a very uh jarring thing when that change comes earlier or that challenge even in your case this this feeling that oh wait a second you know a lot of our work has just been challenged by by this this big company how how do we deal with this right those kinds of of challenges may not come when you expect them to and yeah this this is this can be incredible and i think it's a great way to difficult, personally taxing. It can be maybe the most underrated thing you can experience. And this is the emotions that go along with it. You can be very angry that the universe lined things up in this particular way. But the truth is, if you look forward, like you have, obviously, and you recognize that change is inevitable, but we can respond to that change. We can dig in and find out what do we do to adapt. That's really what growth is about. That's what it means. That's what it means to have a growth mindset is understanding that change, you're not going to keep change from happening. Change is actually an opportunity. And so all of the control that we try to impose on the world, all of the things that we try to reduce the amount of change that's happening around us, it's just going to frustrate us, right? But if instead we can use it as a springboard to the next thing, we're much more likely to succeed, much more likely to be at peace and experience those positive emotions of growth and excitement that we had in the beginning. Yeah. And I think that was the biggest learning lesson out of all of that, the kind of epiphany behind this is that I went from feeling like I'd failed our team, I'd failed our customers, we had failed to see something that was coming in the market. And, you know, just, just being really disappointed with myself and really disappointed in kind of how we had, you know, I guess our philosophy on how we had built our product up to that point to taking those feelings of disappointment and that I had let people down and saying, well, how do we learn from this? And how do we build our way out of this? Because that's something we still have an ability to do. We still have an amazing team here. We still have phenomenal engineers. And that kind of really shifted our focus from, you know, evolving as a product that was just filling a gap in GitHub's platform that was really, really obvious to bringing real value to our users and to our customers. And that pushed us down the path of building a lot of things into our product, like estimation, reporting, even building a product roadmapping solution. And it really pushed us to get opinionated on how we were building the product as well, and really kind of lit a new fire under everyone working at the company to really think about how we were differentiating in a much bigger way. And I think through that process, we ended up, like I said, building a lot of features and a lot of functionality, getting into certain areas and certain, you know, territories that we maybe otherwise wouldn't have gotten into, if we had just kind of stayed comfortable and stayed complicit in filling this gap that GitHub itself wasn't addressing in its product. And so, like you said, that's kind of really, I think when you're faced with those moments, you can continue to be disappointed and frustrated and even angry, and feeling like you've kind of let everyone down, or you can use that as a pivot point to say, we still have a lot of great things going on here. We still have customers that trust us and value us and are going to support us through this. How do we turn this around and actually kind of see the forest through the trees here, that there's a bigger opportunity beyond just what we're doing today, and really start to focus more on that. And it also kind of helped us get more mature as a company as well from just building, I think, what a lot of people looked at as a feature to building more of a platform and a solution on top of GitHub's platform. Yeah, yeah, absolutely. Aaron, thank you so much for your time. Thank you for sharing, obviously, that story and your time with me today. I have one last question for you. While we wrap up, in 30 seconds or less, what advice would you give to developers of all backgrounds and experience levels? It's a good question. I think we're seeing the shift right now where every company, in some aspect, is becoming a software company and developers are really at the center of that transformation. And so to developers that are listening to that, know that you have a lot of influence on the direction of the business. You're going to be able to do a lot of things that you may not have been able to do in the last five, six, seven, eight, nine, ten, nineteen, nineteen, and frameworks that get implemented, the different tools that get used. So get involved, ask questions of the business, and don't compromise on the things that help you do your job better and help you be able to add more value. You know, I think that that's very much a piece of advice that I would give to developers is that you're very much a part of this conversation, even though at times you can be shielded from the business, you do have a lot of influence, you know, and you can use that influence, I think, in really powerful ways. So, yeah, absolutely. Aaron, thank you so much for your time. I appreciate it. And what can people do to find out more about how Zenhub can help them with the things that they are trying to do with their project management, maybe change their estimation process? Where can they go? Yeah, if you're really interested in taking a look at the product, you can go to zenhub.com. You can either start a free trial or learn more about the product and more about our philosophy in terms of how we kind of see project management and how we're a little bit different than maybe something that we're not used to. So, yeah, I think that's a great way to start a free trial. the other project management tools out there. We're also very active on Twitter. If you want to follow us at Zenhub HQ, we're really trying to build a sense of community and always trying to get involved in conversations around software development and around project management and kind of introduce our opinions there and then, you know, take a stance of kind of listening to people and hearing more about what they want to see in this space and how they think it's going to be involved. So those are two great ways to stay in touch and to learn more about Zenhub and the things that we're doing. Awesome. Aaron, thank you so much for your time. I appreciate it. Yeah, thanks so much for having me again, Jonathan. Really appreciate it. Thank you for listening to today's episode of Developer Team, my interview with Aaron Upright, the co-founder of Zenhub. And I just want to echo what Aaron said there at the end. You can make a huge difference in the work that you do, whether that is a difference in the lives of the people that you work with or the difference in the business. The actual mission of the business itself. And both are valuable. So I encourage you to find ways to make an impact wherever you are, whatever you're doing in your work today. After all, this podcast is for driven developers, specifically for driven developers, to help you find clarity, perspective and purpose in your careers. And if you're not looking for those things, or if you're not looking to make an impact, then you probably should be looking for perspective. So I encourage you to look for the ways that you might make an impact. And it doesn't have to be in the ways that everyone else tells you. It doesn't have to necessarily be in the business. It doesn't necessarily have to be, you know, in the code base. There are a lot of ways to make an impact. And that may be as simple as helping the people around you in extraordinarily kind ways. And if you're not looking for perspective, then you probably should be looking for Thanks so much for listening to today's episode. Thank you again to today's sponsor, Command Line Heroes. Go and check out the wonderful new season on your podcast platform of choice. Just look for Command Line Heroes. This is the newest season. Thanks so much for listening. This episode and every other episode of Developer Tea can be found at spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea. See you next time. Thank you.