Aaron Upright is a cofounder of Zenhub and in this part 1 of the interview with Aaron we talk about his background, how he got going with Zenhub and what he's working on today.
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.
Â
This week we have Aaron. Aaron is a co-founder of ZenHub. If you haven't checked out ZenHub, I encourage you to go and check it out. ZenHub is excellent software. It helps with project management directly inside of GitHub. It's actually a browser extension. My name is Jonathan Cutrell. You're listening to Developer Tea and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Aaron and I have an excellent conversation over two episodes of Developer Tea. These two episodes are both coming out this week so I encourage you if you enjoy today's the episode, the first part of this interview. Go ahead and subscribe so you don't miss out on the second part of my interview with Aaron. Aaron, thank you for coming on to Developer Tea. Thanks so much for having me, Jonathan. I'm excited to talk about the things that you are becoming the expert or an expert in. But first, I want you to give a background. What do you do on a day-to-day basis? Yes. I have a little bit of a different background, I think, from most founders and, I guess, most technical founders too. I don't actually come from a software development background. But I do a lot of different things at ZenHub. I guess as a founder and wear a lot of different hats. I've mostly operated on the go-to-market side of our business. So, covering things from sales, customer success, and marketing, and really getting those functions up and running in the early days and making sure that we were doing everything in our power that we could be doing to really support our customers. But today, that's kind of evolved into a lot of different things. And while I still very much sit with that team and still very much sit with those functions, I do a lot of work with our customers still. A lot of product and strategy work now as well. And really kind of looking at the space for project management and where all this is headed and trying to kind of marry that with providing a great developer experience and great experience around kind of development tools and the development life cycle. So, I guess that's a long way of saying a lot of different things and a lot of different areas in the company. I still get the opportunity to contribute to, but most of my day is kind of split between a lot of product strategy and a lot of go-to-market. So, that makes sense. So speaking of the products, I think it's important to recognize that this is a really hard problem to solve. And that there's multiple solutions, probably. I don't know, maybe you don't agree with that, but I think there's multiple solutions. It depends on your team. It depends on what works best for your particular type of product. It's interesting that you are building a product that enables other people to build their products. Have you found that the people who are using Zinhab are building particular types of products? Are they building MVP stuff or are they working more towards the larger end of the scale where there are multiple iterations in? What do you think is kind of the sweet spot for your product? Yeah, it's a really good question. And I think when we first started that, our interpretation of who our audience would be is much different than it actually ended up being. Now even completely different as we've kind of grown as a business and evolved our product as well. And when we first started Zinhab, I think because of the way that we really integrated into a source code management platform being GitHub, we thought that this kind of style of project management could be really powerful for teams that were really focused around smaller products or maybe focused around bringing products to market, had smaller development teams, and really just wanted to work in an autonomous way. But what we actually found is that there was a lot of teams out there that were actually struggling to manage their projects in a way that were more connected to their code base. And that didn't necessarily just correlate with the size of the team or the complexity of the project. We started to see teams from all different sizes of organizations and all different verticals and industries that were really interested in using this as a solution to help bring project management closer to the code. And so it's really interesting. We thought that this would definitely be a tool for the small-to-mid market companies. But really, we have representation across a lot of very forward-thinking startups, but also some massive, massive customers and Fortune 50, Fortune 10 companies, even that are using this, that are really transformed the way that they're building software. So that's been really exciting that we get to interact with so many different types of audiences and so many different types of companies, even that are building so many different things and so many different spaces. It's a very complex total sense. I think it's helpful for people to know what the philosophy is before we continue this discussion, because I think we're going to get into some important questions about, for example, making estimates and establishing reference points and that kind of thing. So can you kind of give maybe a 30,000-foot view of what is the philosophy behind Zen Hub? Yeah, that's a great question. So I think to give a little bit of background around who we are as a tool and kind of what we do as well, we are a project management solution really end to end that's built into GitHub. And really that comes back to this core philosophy that we have, our have of how do we make life as easy as possible for developers and allow them to really focus on that meaningful work. That's really a core part of our mission and that concept of focusing on meaningful work is actually something that we've included in our mission as well. What I mean by meaningful work is that type of work where developers are actually coding and spending time on that rather than updating a project management tool. And we really wanted to take a lot of those really high friction parts of the process of writing and developing code or writing and developing software where you're having to go back and update project management tools to keep the organization informed and to kind of make sure that the project is moving in the right direction. So a really core kind of philosophy for us as a product is how do we help people that are using our products spend more time doing that meaningful work, more time doing the work that they love rather than having to update different tools and keep these systems and processes up to date for the rest of the organization. That makes total sense and I guess my next question would be what are the mechanics of that? If we were to get down to the nuts and bolts, what is the process that is too heavy or what is the opposite of that look like as a developer? I'm having to go to multiple platforms maybe. Maybe I'm having to make the same comments in two or three different places or copy ticket numbers from one platform number to another. How does that play in? What are the mechanics that make it? It almost sounds like it doesn't exist, right? That's not obviously it does. What make it transparent and how do you make sure that there is enough there that it's worth using? Yeah, I mean as developers ourselves we just found that we were doing a phenomenal amount of context switching back and forth between where we were developing software and where we were updating the rest of the organization on what we were developing and how far along we were. It was that kind of point of friction that I think was really leading to a really poor experience around every other tool that we had tried out there in the market. When I talk about context switching I mean that physical jump that you have to do is a developer from being in an editor or being in your command line and actually writing code to going and updating a project management tool, clicking around in that interface or clicking around in that tool, writing comments to keep the rest of the team in the organization up to date with what's happening. Like you said a lot of times that's duplicated effort. It's happening in multiple systems where you're maybe adding comments to an issue inside of GitHub but then you're also having to add those same comments whether it's copying and pasting or kind of paraphrasing into a ticket in Jura. We just found that not only did that create a massive amount of wasted time and people duplicating efforts and people having to come back and comment on things but every time that you leave that focused working time where you're in the code base you're actually writing code it's really destructive and really hard to get back into that. If you have to jump outside of that context in order to do something else it can be really hard to put yourself back into that same mindset or that perspective of how you were maybe solving that problem or writing that part of code. We really want to help eliminate those high friction moments that happen when people are forced into other systems or forced into other tools. Makes total sense and just for anybody who's listening if you think that this is a paid episode it's not. These principles can work with multiple types of tools and not just when it comes to managing your projects. Essentially the underlying principle that we're talking about here is reducing the surface area and trying to integrate your efforts into the most important work that you're doing and making the work that you're doing higher leverage. Getting advantage of, for example, if you're opening issues or opening PRs, taking advantage of what you're already doing there in other places. Regardless of what tools you're using that's the underlying principle here. I think it's important for people to know that because this can apply to your email inbox just as much as it applies to the code that you're writing and committing to in GitHub. I want to switch gears and ask you a couple of questions about estimation because I think this is probably one of the most critical problems that developers face throughout their careers. Not just when they're young developer. If you're a young developer listening to this, when I say young, I just mean if you're early in your career as an engineer and you're listening to this and you think eventually you're going to get better at estimating. Eventually you're just going to have perfectly accurate estimates and 20 years in, everybody will be able to rely on those. If you're a developer who's been in this for 20 years, then you know that's not true. I'm really interested to know what have you learned, maybe something that wasn't really intuitive to you when you first started on this journey about estimation that you can share with engineers today. Yeah, I think one of the maybe the most powerful learnings is that you get better at estimation by doing it and it takes a lot of trial and error to get to a place where you're comfortable as a team with the estimates that you kind of put forward. I think what turns a lot of people off about starting estimation is that there's really no good starting point for that. There's really no good first run on the ladder to start with estimation and it really does require you to kind of jump in with both feet. I'm mixing analogies now, but it's that concept of, you know, hey, if we don't know how to estimate, then estimation isn't for us and we never know how to estimate because we're not estimating and we don't have a concept or we don't have this idea of what this, you know, set of story points means or what the difficulty or effort level associated with this particular task is we even struggle with this as a team as well when we were building Zenhab and when we were, you know, before buildings and had building other pieces of software trying to understand, you know, how much effort was involved in something, how difficult it was and trying to map that back to oftentimes what teams use. Story points or t-shirt sizing or sometimes even ideal days to try to get a better understanding of how long something is ultimately going to take. And there's a number of kind of mental models that we've developed around that to help make it more powerful, but one of the biggest things for us and just, you know, actually getting comfortable with that was that concept of jumping in and actually just being comfortable with the fact that we were going to get it wrong for several sprints and several iterations, but after, you know, doing it and after kind of learning from those mistakes, we would eventually be able to refine that model to a place where not only we could teach on it, but it came, you know, really powerful and really meaningful for us as an organization and really helped, you know, anchor our ideas of how long something was going to take or how complex something was going to take as well. And there's, again, all kinds of different parts of estimation and all different kind of philosophies around estimation that you can use. But again, I think the most important thing is just really starting with it and trying to get comfortable with the concept. And I know that's hard for a lot of teams, but if you can, you know, if you're on the outside kind of looking in in terms of whether or not we should be doing it, you know, my advice in my recommendation would be, you know, to start trying it out and to start building up that idea and understanding of how it works. So that's fantastic advice. I think as with most things, as you gain experience doing a specific thing, you become better and better at it, estimation is a hard problem to solve. It's hard because most of the work that we do as engineers is not the same as, it's not a discrete problem. You know, we don't want to look at it and we say, oh, okay, we know exactly how to solve this. Now we're just estimating, you know, time and materials basically. It's a more difficult problem because we're basically solving, trying to presolve or estimate the amount of complexity for solving a problem and that on its own is really difficult to do because the problem has either not been solved or at least it hasn't been solved in this particular way by this particular team. And there's so many variables that go into it. I'm interested to know, you know, do teams tend to, based on kind of the information that you have, do teams tend to improve in their productivity as they begin estimating? And my basis for this question is the common practice of trying to increase the number of points that you're completing every sprint. This is a very common practice. It's something that a lot of engineering managers will do. They'll say, okay, we did 60 points last sprint. Let's try to get 65 points in or let's see if we can push it. And always trying to increase that capacity. Does it make sense from your perspective, kind of from the data perspective, to try to create that endless improvement on that particular productivity metric? Yeah. I think, I mean, teams I think should always be trying to improve and continuously get better at their process. But I think if we were to graph the data, what we would find is that it very much looks like a U-shade. So when teams start estimating and they're not really comfortable with it and they're getting into it, oftentimes there's a period of time or a series of sprints where their productivity actually goes down. And a lot of that is because you're starting that process of figuring out how to estimate and that takes time. You're doing backup or final meetings that you maybe didn't do before. Or when you're sprint planning, you're not just kind of taking the top issues from your backlog and then dropping them into a milestone and dropping them into a sprint. You're being thoughtful and kind of critical on the stories that you are bringing in and how impactful they are and how difficult they are relative to some of the other stories. Even that time of sitting the team down and kind of coming up with these estimates in a backlog refinement session, it does add time and friction or maybe overhead is a better word to the team's process. And so at least in the short term, we definitely do see that dip in productivity where is the team starts to take on for lack of better word those kind of rituals and build them into or those events, I guess you could say, kind of build them into the calendar that it starts to take time to do. But over time, we find that productivity actually increases because people have a better sense of how difficult things are. They've maybe had the ability to relate those to other projects as they've done in the past and understand the relative complexities that are involved with them. Even sometimes the active estimation gets the teams thinking in terms of what the complexity of this actual thing is that we're delivering and considering beyond just how difficult something is to build. Or maybe it's a really high risk feature or function that's touching a difficult part of the code base that not a lot of people have experienced with or a production system in some way that carries a really high level of technical risk. So it kind of forces us to think about the things that happen outside of code two, around testing, QA, deployment and kind of build that into the concept of the estimate as well. And over time, I think being more considerative of those things, well, it takes a lot of time out front, helps teams be more productive in the long term, and also helps teams avoid getting kind of blindsided midway through a project and realizing that something is actually way more complex than maybe they originally thought it was going to be or that the path we've kind of started down from a technical perspective is no longer feasible. We're essentially kind of shifting some of that work up front so that we're thinking about it a lot earlier in the cycle rather than getting halfway through a project and realizing that we need to kind of scrap that work and take a different approach because we're building something that's fundamentally different or has changed from what we originally set out to. Yeah, this is such a good point that there is kind of a dip in productivity as you take on any new process and as you kind of have to learn even if that process is light and you have to learn and reintegrate, you're working habits with it. And I've seen this with teams as a scale especially and particularly with teams that have really strong, let's say for example, a technical co-founder or something that was highly responsible for shipping code early on and given startups history. And they're having a hard time letting that stuff go. They kind of jump over the process. They don't really estimate their own work and everyone else kind of follows suit. When someone comes to the table like an engineering manager and they say, hey, we need to kind of bring this under control. And because we're going to have three teams in the future and they're all going to be working on different things and hopefully those teams are going to have higher competency than even the co-founder did. Right? That's the goal. We want to hire people who are better than us. And so it's interesting to see that dip and I wonder, here's maybe the hardest question to answer because certainly there are people who leave that process. They say, oh, this is too expensive. This is too difficult. It's not worth it. It's given us a dip in productivity and when really we just need to go back to the good all way of doing things that we used to do. So do you have some way of knowing, okay, this really is too heavy of a process, right? We really do need to retract some of what we've done here. It's too much. Or is there a way to know, okay, no, this is that normal dip that we should expect. What is the length there? Do you have kind of a rule of thumb that you use? You know, I think it's really hard to normalize and it's going to be different for every team depending on what you're building. If you're finding after several sprints, we work in two week cycles, but whether or not you work in two weeks, three weeks or four weeks, if you're finding after maybe several iterations of that that you're just not getting it and it's slowing the team down. The team is more focused on the actual estimation and the work than maybe that's a time to actually try something different or simplify your approach to estimating. A lot of teams kind of jump in and start with maybe points when in reality it would make a lot more sense to start with T-shirt sizing. Instead of having all these different points that can mean very arbitrary things, just have the concept of a small, medium, large, and extra-large story. Coming back, I think, to the question on, is estimation going to work for every team? It really is looking at the scale of the business that I think you want to build and the scale of the engineering team that it's going to require to do that, to understand when to bring in estimation and when there probably is a good time to say, hey, even though in the short-term productivity seems like it's not really as strong as what it used to be, this different productivity is worth it because it's going to allow us to kind of scale past that in the future. There's certain situations where I think not estimating might allow us to move further and the one that comes to mind and I think that one of the only ones I can think of is when you have a team that's relatively small where the seniority of the people on that team is relatively similar. Maybe everyone's later in their career or a senior developer, you might be able in that way to work in a way that's more autonomous where people kind of know what they need to get done. They know how complex things are because they've seen similar styles of problems or similar types of problems before and they don't need to sit down as a team and kind of go through that process and that art kind of of estimating things. If you plan to kind of scale beyond that team, like you said, those early employees or those early kind of developers on the team, it really does help to define and start to understand that the concept of estimation and complexity because when you start to bring other people into the foal that maybe aren't a senior in their career or don't have the same ability to kind of think through problems and understand not only the solution but the technical risks associated with things, a lot of that just kind of falls apart and a lot of companies make that transition from, hey, it's a group of people kind of working in a room where everyone knows everyone and it's really easy to kind of just talk with someone and figure out what they're working on and where they're blocked to. Now we have a growing team, we have different disciplines and different functions. We instead of having a product person who works closely with the entire development team, multiple product people and multiple areas of the product that involve multiple design teams as well, that's really where we see and need to start building process around that. So it's not necessarily intuitive because it's very much like what a very young early career developer feels when they're learning at a rapid pace. They feel like that learning is going to continue at that rapid pace throughout their whole career. Eventually you're going to kind of level off and you're going to be in practice mode rather than in learning mode. You're not going to learn nearly at the pace that you were learning previously, but now you're practicing and you're producing at a much higher rate than you were producing before. That kind of staging is different. We naturally think linearly like whatever we did yesterday, if we just do more of that, then we'll get more of what we got with that process that we used yesterday. So let's continue scaling with the existing processes we have and no need to create extra infrastructure. But this is problematic because we don't think about, for example, even the simple human factors, the human factors of relationships, managing all of those interpersonal relationships and trying to take cues from each other and all that. When realistically we might want to create something that allows us to manage our relationships differently. For example, if you have the ability to assign things to people, that might be a little bit easier than just assuming everyone is going to pick up what they should be picking up. That's a very simple and dumb example, but it can be something that small that changes the productivity and the scalability of a given team. I'm sure that you see that in your data as well. Yeah, absolutely. I think even that composition of the team starts to change over time as well as the company matures and as the organization grows. Even in that example that I talked about of where teams might be able to get away without estimating if they have people in the room that are of relatively similar skill sets, experiences and backgrounds, that's going to change and it should change over time where you start to bring in more diversity of backgrounds and more diversity of experience levels. Again, if you don't really adapt the process or introduce process to help account for that, they can get really, really complex and complicated. A really good example that I think I always like to use is let's say that I'm a junior developer, I'm two years into my career in Jonathan year, maybe 10, 15 years in your career. If someone asks us how long something is going to take, our response to that is likely going to be very different. In your case, it's probably going to be far shorter than it would be for me, just because you have more experience, you've maybe seen these problems before, you've seen similar implementations in the past where this might be the first time that I'm seeing a particular problem. Further to that, maybe you have a background in the language that we're working in and this is maybe my first time actually working with Ruby or working with Node or something like that. If we're asked to give a time-based estimate, that's where things get really hairy because oftentimes if you're more senior, you have more experience in the code base, your estimate is going to be way, way shorter and so that's where we push people to really say, you need to build the shared definition and understanding of complexity and of effort that's involved rather than having everything be time-based. Think of that as an investment into your future scale because eventually there's going to be people sitting around the table and people that are in the room that don't have that same experience level that don't have that same background and they're going to need a foundation or a framework by which to be able to understand how complex what they're taking on is and be able to communicate that to the rest of the organization. So again, even if there is that initial hesitation, this is really something that helps us into the future as well as we think about scaling out our organization and bringing in different people with different levels of experience and different backgrounds as well. Absolutely, and the truth is that it's not difficult to keep, for example, decision records, reasoning for why you made a given decision. This is incredibly important as an organization scales because as you bring on new developers into your team, they're going to look at something or say, this is not the conventional way of doing it. But they don't know if it's because somebody did it the wrong way or if there's a reason that it happened. And so there's a cycle loss there where they have to go and ask, okay, why is this this way? Well, now we might have to trace all the way back to the very beginning. Maybe there was a contractor that was working on the project. They did it that way. And we don't know why. We have no idea. There's no comment. There's no documentation about it. And there's no way to know, you know, should we change this or not? So it makes people feel uncomfortable changing the code. It makes cycle times longer and makes it feel like kind of a land mine or a mine field rather. When actually it's absolutely possible for you to keep those things in documentation and accept accessible to new engineers who are joining the team and they could go and look that up and say, oh, this line of code, you know, obviously GitHub is a great place to do this. You can look at the change history for a given line of code and they can find out, oh, here's the PR, here's the issue, here's the thing, here's the story that this was related to. Being able to do that can absolutely increase two things. One, the speed, obviously, this is, you know, the most important thing to the average startup is speed, but also the sense of autonomy that the engineer feels. They know that they can go and dig into the history of this code. Not just how it changed, but why it changed. And they can dig in and figure that out and be able to make informed decisions without relying on a human block, right? And so that's the kind of process that can really change the dynamics on a team, not just the capability of the team, but also the interpersonal dynamics of that team, which can really unlock people's sense of autonomy and ultimately help increase their personal productivity and confidence in what they're doing. Absolutely. And I think that kind of critical questioning and that critical thinking is super important. And, 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 building and 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 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, you know, I guess, relax about our 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 there much the same way. And no one's really focused on 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 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 update how we think about this or change how we think about this because there's a better way of doing things. Thank you so much for listening to this first part of my interview with Aaron Upright. And of course, a huge thank you to Aaron for joining me on today's episode. And on the next episode of Developer Tea, if you enjoyed this episode and I'm going to guarantee you that you will enjoy the next one as well, the end of my interview with Aaron, go ahead and subscribe and whatever podcasting app you're currently using. Today's episode and every other episode of the show can be found at spec.fm. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time. Enjoy your tea.