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 Upright. 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 Cottrell. 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 enjoyed today's 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 Upright. Aaron, thank you for coming on to Developer Tea. Thanks so much for having me, Jonathan. Really excited. I'm excited to talk about the things that you are becoming the expert or an expert in. First, I want you to give a background. What do you do on a day-to-day basis? I have a little bit of a different background, I think, from most founders and most technical founders, too. I don't actually come from a software development background, but I do a lot of different things at Zenhub as a founder and wear a lot of different hats. I've mostly operated on the go-to-market side of our business. I'm covering software development, I'm 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. Today, that's evolved into a lot of different things. 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 looking at the space for project management and where all this is headed and trying to marry that with providing a great, developer experience and great experience around development tools and the development lifecycle. I guess that's a long way of saying a lot of different things in a lot of different areas in the company I still get the opportunity to contribute to, but most of my day is split between a lot of product strategy and a lot of go-to-market. That makes sense. Speaking of the product, 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 Zenhub are building particular types of products? Are they building MVP stuff or are they working more towards the product that they're using? I think that's a really hard question. I think that's a really hard question. The larger end of the scale, where there are multiple iterations in, what do you think is the sweet spot for your product? Yeah, it's a really good question. 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 grown as a business and evolved our product as well. When we first started Zenhub, 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 really 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 transforming the way that they're building software. So that's really interesting. And I think that's a really good question. It'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 in so many different spaces. Makes 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 Zenhub? Yeah, it'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 of how do we make life as easy as possible for developers and allow them to really focus on that mutualization of the two? And I think that's a really good question. I think that's a really good question. I think that's a really good question. I think that's a really good 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 out 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 keep the organization in shape. And I think that's a really good part of our mission. 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, you know, the 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, you know, what are the mechanics of that? If we were to get down to the nuts and bolts, what is the, what is a process that is too heavy or what, what is the opposite of that look like as a developer? You know, 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 packet, you know, platform number to another. How does that play in? What are the mechanics that make it, you know, it's, it's almost sounds like it doesn't exist, right? Like that's, that's not obviously it doesn't exist. It does, but you know, 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 kind of updating, I guess, the rest of the organization on what we were developing and how far along we were. And it was that kind of point of friction that I think was really leading to pretty much a really poor experience around every other tool that we had tried out there in the market. And when I talk about context switching, I mean that physical jump that you have to do as a developer from, you know, being in a, 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, you know, writing comments to keep the rest of the team and 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 Jira. And we just found that not only did that create a massive amount of kind of wasted time and people duplicating efforts and people having to come back and comment on things, but every time that you kind of leave that focused working, you know, time where, you know, you're in the code base, you're actually writing code, it's really disruptive and really hard to get back into that. You know, if you, if you have to jump outside of that, that context in order to do something, 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, or writing that part of code. And so we really want to help eliminate those high friction moments that happen when people are kind of forced into other systems or forced into other tools. Makes total sense. And, and just for anybody who's listening, if you think that this is like a paid episode, it's not, uh, these principles can work with, with, uh, multiple types of tools and not just when it comes to, you know, writing code. At the same time, you may find these principles may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, may work for you, kind of integrate your efforts into the most important work that you're doing, right? Making the work that you're doing higher leverage, taking advantage of, for example, if you're opening issues or opening PRs, taking advantage of what you're already doing there in other places, right? So regardless of what tools you're using, that's the underlying principle here. And 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. So 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 a 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, right? Like 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, right? So 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. Uh, that you can share with engineers today. Yeah, I think one of the, maybe the most powerful learnings is that, you know, 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. And I think what turns a lot of people off about starting estimation is that there's really no good starting point for that, or there's really no good first run on the ladder to, to start with estimation. And it really does require you to kind of jump in with both feet. Yeah. Yeah. Yeah. I'm mixing analogies now, but it's, it's that concept of, you know, Hey, if, 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 struggled with this as a team as well, when we were building Zen Hub and when we were, you know, before building Zen Hub, building other pieces of software, trying to understand, you know, how much effort was involved in something, how difficult it was to do it. And trying to map that back to oftentimes what teams use is story points or t-shirt sizing or sometimes even ideal days to try to get a better understanding of how long something is, 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, 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. 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 and my recommendation would be, you know, to start trying it out and, 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, it's a more difficult problem because we're basically solving, trying to pre-solve or estimate the amount of complexity for solving a problem. And that on its own is, is really hard. It's 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. There's so many variables that go into it. I'm interested to know, you know, do, 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. Uh, 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, last sprint. Let's try to get 65 points in, or, you know, we 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, you know, improvement, uh, on that particular. 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 shape. So when teams start estimating and they're not really comfortable with it and they're getting into it, you know, 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 background refining meetings that you maybe didn't do before, or maybe you're doing a lot of other things. And so. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. At least when you're bringing your team together, you may find that they may have taken the most time they needed to write these Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp Camp 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 as the team starts to take on, for lack of a 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, whether or not 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 experience 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 too, around testing, QA, deployment, and kind of build that into the concept of the estimate as well. And over time, I think being more considerate of those things, while it takes a lot of time upfront, 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 fair. So I think that's a really important part of the process, is that we're not just kind of thinking about the things that are feasible. We're essentially kind of shifting some of that work upfront, 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. Yeah. And you kind of reintegrate your working habits with it. And I've seen this with teams as they 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. Yeah. And so when someone comes to the table, like an engineering manager, and they say, hey, we need to kind of bring this under control, right? 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, you know, 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. You know, it's not worth it. It's given us a dip in productivity when really we just need to go back to the good old way of doing things that we used to do. And so, you know, 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 the way to go. And so, you know, do you have some way of knowing, okay, no, this is the way to go. And so, you know, do you have some way of knowing, okay, no, this is the way to go. And so, you know, that normal dip that we should expect, what is the length there? Do you have 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, you know, several sprints, you know, 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, you know, it's slowing the team down, the team is more focused on the actual estimation and the work, then maybe that's the way to go. And so, you know, I think it's really hard to normalize 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. And instead of having all these different points that can mean very arbitrary things, you know, just have the concept of a small, medium, large, and extra large story. But coming back, I think to the kind of question on, you know, is estimation going to work for every team? It really is kind of 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 kind of understand when to bring in estimation and when there probably is a good time to say, hey, even though in the short term, you know, productivity seems like it's not really as strong as what it used to be, this dip in 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 want to build a team, you want to build a team, you have a team that's relatively small, where, you know, the seniority of the people on that team is relatively similar. Maybe everyone's kind of 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 estimating things. But and, you know, if you plan to build a team, you're going to have to kind of work in a way that's more autonomous. And if you plan to kind of scale beyond that team, like you said, those early employees or those early kind of, you know, developers on the team, it really does help to, you know, define and start to understand that that concept of estimation and complexity. Because when you start to bring other people into the fold 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, you know, I think that's a really good point. And I think that's a really good point. And, you know, 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, you know, now we have a growing team, we have different disciplines and different functions, you know, we instead of having, you know, a product person who works, you know, closely with the entire development team, multiple product people in multiple areas of the product that, you know, involve multiple design teams as well, that's really where we start steep, see a need to start building process around that. So, you know, it's not necessarily intuitive, because, you know, it's very much like what an early, 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, 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. And so, you know, it's a really good point. But now you're practicing and you're producing at a much higher rate than you were producing before. And there's, you know, that 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 this is problematic, because we don't think about, you know, for example, even the 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 manages that allows us to, to manage our relationships differently, right? For example, you know, if you have the ability to assign things to people, that might be a little bit easier than if you're just a regular person, right? So you're going to have to do a lot of things. And so, you know, that's, that's a really good point. And then, you know, you're going to have to do a lot of things. And then, you know, you're going to have to do a lot of things. So you're going to have to do a lot of things. And then, you know, you're going to have to do a lot of things. than just assuming everyone is going to pick up what they should be picking up. Right? 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. And I'm sure that you see that in your data as well. Yeah, absolutely. And I think, you know, even that composition of the team starts to change over time, as well as the company matures, and as the organization grows, and, you know, even in that example that I talked about of where teams might be able to do things that are not 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. And, again, if you don't really adapt the process or introduce process to help account for that, it can get really, really complex and complicated. And a really good example that I think, you know, I always like to use is, let's say that, you know, I'm a junior developer, I'm two years in a company, I'm a senior developer, I'm a senior developer, I'm a senior producer, you may have signed up for the evolution platform, you may have signed up for the 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. And 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. You know, 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. And so 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's going to be way, way shorter. And so that's where we push people to really say, no, you need to build the shared definition and understanding of complexity and of effort that's involved rather than having everything be time based. And think of that as an investment into kind of your future scale, because eventually there's going to be a lot of time and a lot of time and a lot of time and a lot of time and a lot of 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, you know, 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 kind of initial hesitation, this is really something that helps us into the future as well, as we think about kind of 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, like, 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 and 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. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.ensionension Yeah.!! 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 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. 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 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 a business, I did a lot of the things that I did in the very early days of building and creating a business. And I think that's a really important part of the 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? Then that progress and change never really happens within the company. And you just kind of become this, this, uh, 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 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 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, then I guarantee you that you will enjoy the next one as well, the end of my interview with Aaron. Go ahead and subscribe to 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 John. I'm Jonathan Cottrell. And until next time, enjoy your tea.