Bridging the Gap Between Product and Development: Building Better Foundations with Greg Lind

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season on Building Better Foundations. This is the Developer podcast, Building Better Developers. This episode and next one, we're going to be into an interview again, and I will save that for a few moments from now. First, introduce myself. I am Rob Redhead, one of the founders of the developer and developer, also the founder of RB Consulting, where we help you leverage technology and do technology better. Build yourself a roadmap for success. Good thing and bad thing. Good thing is, is we are getting into the holiday season. This is always a part of the year that I enjoy. I actually do signed a little bit of downtime here and there to be able to get some relaxing in and things. The bad news is, or the bad thing is that it's already the holidays. It's like it's there's a lot going on. There's a lot to do. The year has flown right by. And while I'm looking forward to the next two months, also there's a little bit of like a little sadness of like the year has already flown by and many things I wanted to knock out. I did get a lot accomplished, but probably I have a feeling when I start looking, there's going to be a lot that I'm like, oh, crud, that's something I didn't get done this year. One of the things I have gotten done is passing over the introductions to Michael every time. Michael, go ahead and introduce yourself. Hey, everyone. My name is Michael Molloch. I'm one of the co-founders of Building Better Developers, also known as Developer Nerd. I'm also the founder of a company called Envision QA, where we help businesses take back control of their systems by focusing on what really matters most, quality, reliability, and the support you can count on. Whether you're building something new or trying to fix what's broken, we combine custom development through testing and make sure your systems actually work before you hand it off to the customer. Check us out at EnvisionQA.com. Good thing, bad thing. Similar to you, we just got past Halloween. We're getting into that Thanksgiving rush and madness. Walked into the store the other day and saw Christmas stuff up. It's like, it can't be that time of the year already. So that's kind of the bad thing this year. It's just kind of flown by. But the good thing is we're getting into the holiday season and lots of food. And our guest today is Gregory Lind. He's the CEO and founder of Buildly, which is very hard to say. I have to say it slowly, but I'd like you to go ahead and introduce yourself, Greg. Yeah, for sure. It's also hard to type, I've noticed. I'm more than a few times I've left out that middle L in Buildly. My name's Greg. I'm the founder of Buildly and OpenBuild, which is our nonprofit partner. Our focus is on bringing developers and product managers together into one tool and building things as a team rather than as two separate teams. And we're excited to talk a little bit about the open source tool that we've built, the AI tools that we've built. And yeah, just also the developerpreneur thing. I think for us, it's really about helping developers become better at what they do, learn to use AI tools, but also, I think, grow into those roles, especially at OpenBuild. We have a program where we train developers to go from a senior to maybe a CTO or VP type process that we use inside of Buildly as we work with customers and train folks to become that technical co-founder for another founder that maybe is looking for somebody to do that and using our tools along with AI to help with that. So yeah, excited to talk about it. And that is, I'm going to dive right into that because I think that is part of the challenge that I've always seen with software development in general is the siloing of team members where it's like, project management sort of does their stuff and developers do their stuff and testers do their stuff and database people do their stuff and on and on and on. It's just while we work as a team, it's just like getting the cohesiveness across that team I think is always a challenge. The ones that I've been with that work really well have solved that problem. The ones that don't usually have not solved it. And so I'm really curious from productizing it, from systematizing how to do that better. I'd really like to just sort of open the floor to that and talk about how you guys see it and how you guys approach it. Yeah, it's been a long time coming I think for me specifically. I saw a lot of the same problems with the silos, not just from a team perspective, but obviously from the data perspective as well. One of the first things we did, when I first started actually working on what is now buildly, I was on a team called Humanitech in Berlin and we were building a DevOps platform essentially for cloud native and Kubernetes. At that time, I saw a lot of issues with communication. We were working with a lot of different small businesses in the area and some larger businesses and communication between the project manager or the product manager and the development team and at what stage they were talking as well. And that wasn't just that they weren't communicating sometimes, it was they weren't communicating early enough or they weren't involved in enough of the meetings upfront, especially from the developer side. And then later on in the process, the product managers would feel left out of the planning stages or the backlog grooming stages in some cases or just how you're managing your own personal backlog. Developers started to feel like they had an engineering manager, maybe they had a CTO, they also had a product manager they were responding to. So they had multiple bosses essentially. That was really sort of the start of where I started to look at process more and then I started to look more specifically at how multi-repo processes with microservices were breaking down that process even more and sort of isolating all of our issues. But at the time we were using, trying to use a combination of Jira and then GitHub and none of the tools really worked for us. We couldn't really get any of these things to connect across multiple repos in a way that allowed us to have one place to manage everything, at least not without huge license fees in some cases. And so that's kind of where it started. And I think what we saw initially as I started to spin out Buildly from what was then Humaniseq at the time was that we start at that, I think that was right at the beginning of COVID and everyone was moving to these remote management processes and teams. And I had been doing that for years before that with an organisation called Mercy Corps with teams, remote teams all over the world. And I saw this breakdown in trust between the software developers and the product managers as well, where they started to feel like not only were they not involved in those discussions about how features were being built or what types of libraries essentially that would have to be used in order to make these things, they felt like every time they started to work on something, it was an interrupt driven process as well because product managers were coming at that point and jumping in and saying, oh, can I see what you've done so far? I'd really like to have this look this way or that look that way. And so that's kind of where it all started. And I think where we brought it together is first we looked at the API. So we started off and are still mainly supporting Trello for product managers and GitHub for software developers because they have this easiest, simplest process to manage from an API standpoint. And we could bring all of those into one board essentially and associate your product backlog with your actual sprint backlog, which is what we were using at the time. And then you could see everything all in one place. And then all of a sudden, the realization as we started to go through that, that the other side of that was that product managers felt like there was this magic happening behind the scenes with software developers, right? Something that they didn't understand. And so they were confused as to why one ticket that seemed like a small issue would get an estimate that would bring it down to essentially a one day development process, but one that seemed much more complicated sometimes would get a week or so. And then why was that happening? Why was this a week and why was this a day? And then the flip side of that is things that they thought were easy were sometimes taking much longer. Or when QA got involved, I'm sure you guys know really well, when QA gets involved in that process as well, you come back into that process after testing it and those iterations start to happen on their own. So you have development cycle iterations and then testing iterations and they don't always meet back at the same place. And so the communication around all of that was difficult. So really what we decided was let's automate the communication, bring it all into one tool, bring all of that process there and then allow communication to happen from everyone. So it's not just agile stakeholders, right? The old pigs and chickens who's more involved in the breakfast sort of approach. Everybody has equal access to certain aspects of the platform, but they look at it from a developer or a product view. But they can still see everything, communicate on everything and get feedback and automate as much of that communication as possible. And that's kind of how we got to where we are. And I think the biggest issue that we saw then and we still see to a certain degree is really just about that whole getting velocity and estimates and all of that process. The agile approach to that started to really break down for us, especially once we got into more AI driven development tools. And we also were looking at CI, CD tools and automatic deployment from multiple repos into multiple hosting platforms. Right. So we were doing multi cloud as well as multi repo deployments. And we started to see agile just not, it was almost like breaking under the pressure. And so we also started to work on our own process where we call it our RAD process, which is just a rapid AI development process, keeping up process with the AI tools, keeping up with automation tools, all of that. And I think that's where we really started to see some huge benefits on the team side as well. So moving away from just the traditional cycles, one or two week or three week sprints into these release based time based systems where you can push out a patch in a day or a week, depending on how many features you needed to build out. And so there were multiple cycles happening at the same time and it started to really sort of flow together much better at that point. So yeah, I mean, I think a lot of the tools and everything else, we want to continue to add more APIs and bring in more connections. We're already starting to build out GitLab integration and then we'll look at more of the Atlassian tools as well. But I think there's always process problems, I think. And I think we're continuing to refine that with vocabulary and things like that. But I think for developers, having tools like ours or really any sort of system where you can go one place and know this is where I can get my list of things I have to work on today, that's a huge benefit. And it doesn't matter if you've also got other automation CI-CD tools that are sending you email messages or just platform messages, debugging tools, all of these issues from QA and wherever else, you can manage it all in one place. See your priority list. I think that's what we want. And then using those AI tools, that's the next step is how do you do that efficiently without sort of depending on AI, right? So learning to use AI for education and learning to use AI for the redundant boring pieces, but not using AI for replacing yourself essentially in that process. And I think that's the next key and that's the part that we're working on the most with our developers and our partner developers as well. There's a lot there. Let's start with how you saw agile breaking because this is something that actually I've seen. I've run into a couple of different cases and similar kinds of things. And I'm wondering, was it breaking because the, and I'm going to give you a couple and it may be all of the above, was it because the cycles weren't fast enough based on how fast you're producing it? Was it because you had multiple, essentially multiple repositories, the equivalent of having parallel sprints, we'll say going on at the same time or was there, were there other factors that were breaking it? I think those were the two primary ones. You hit it right on the head, but it's most multi repo obviously adds additional levels of complexity in anything you're doing, but the CI CD tools that are built for, for this are really handling it really well. We use mostly GitHub for GitHub actions to do it for the most part of it for us right now. But as you started to get into looking at where your issues were being managed, you were having to go bounce back and forth between different GitHub issues in each repository or in GitLab, you had the same, the same process. And so we started to look at that and that's really where we started to see things starting to creek and break a little bit. But we came up with some pretty simple solutions for at least some of that. And that was just sort of managing it all in one tool and essentially ignoring GitHub issues, which I think the other part of this that I really wanted to see happen that I don't think Agile has ever really accommodated is the fact that I'm already doing updates every time I check in code. I'm putting a commit message in every time. The more detailed, sometimes I put in some really bad commit messages and other times I put in some detailed ones, maybe going too detailed. But I really felt like that part of the process was never really included in the Agile process. And so I wanted to see that brought into it as well. But then I think the other aspect is we were doing patches and we had, because of the multi-repo approach, we could do a patch in one repo and a feature update in another repo, and then maybe another patch or two in a different repo altogether. And so managing all of that as a product manager, you're bouncing back and forth between tools and you're not really seeing one sort of backlog of list of things to do. So that's where we really started to see it break apart. And on top of that, I think as this, and this is something that I think every generation, or I don't like the term as we go into the gen X versus gen Y versus gen Z and how they approach work. But if you just look at the more modern software development approaches that are not just, they're not getting taught necessarily in schools. They're coming in and learning on their own and figuring out how to be a developer on their own. They're not getting that mentorship process either. And I think what you miss when you jump into a team all of a sudden is these process, all of the different taxonomy around the different labels for things, the different types of words you need to use. What is a sprint? What is agile? What is scrum versus lean versus all these different approaches. And you get lost in the terminology and you have to then learn a whole new set of way of working with the team. And most of the product management tools and project management tools, even issue trackers are either trying to be very unopinionated about process or they are very opinionated about process. And there's not a lot of in between. And that's kind of the other aspect that we saw starting to break is we were running multiple sprints with multiple teams. And this is outsourced teams as well as in source teams. So we had all of these different levels of understanding, different terms that weren't making sense to folks. And so what we started to do is started to see that agile, it doesn't matter which flavor or how we adapted, it just wasn't quite working for what we needed. And that's not to say that for large enterprise teams that are mostly internal or I'm sure there's other use cases where agile was working fine and still will work fine. For us, though, we started to see as we work mostly with startups that were fast paced and a lot of different outsourced developers, it's hard. It's really hard to teach all of that to somebody. And there aren't really any tools that do that for you. And so that's kind of where we came into it. It's like we wanted to revamp agile and sort of create our own version of it that fit what we do. And it also has to include some of this automation so that things like messages that you do and commit messages, those actually become visible and usable and can automate your daily standup. I don't need to sit here and tell you everything that I did yesterday when you can just go look at my commit history and see what I did. And I think that's the access that we needed. So it started there and it grew throughout that rest of that process. But I think, you know, and I've written a couple of articles and I actually wrote a book last year about this called Radical Therapy for Software Development Teams. And part of that is transparency. But the other part of that is process and how you manage that process and how flexible it is. And I think that's the aspect that we, as a team at Buildly and really every startup that we worked with, we started to see transparency once we moved to our new process. And we moved away from agile, included. And frankly, that's part of the Agile manifesto is to sort of adjust to your team and your process, not to be this set of rules. It's really just about delivering working software. And so in a way, I think by essentially revamping agile to be our own thing, we are also fitting into the big A agile approach. But at the same time, it's a new flavor at the very least, if not a complete rework of how agile happens in a, not just AI driven software, but I think in a more automated approach for cloud native, especially. And I agree. I think this is very much it is. It's funny because it really is to me, it's agile as the agile manifesto reads and not, you know, people think agile is, you know, Kanban or Sprint or scrums. Which are all agile things. But then people conflate the two and they're like, well, you're not doing agile because you're not doing scrum or you're not doing, you know, it's like, well, no, actually go back to, go back to the source material, go back to the manifesto. And it's really about like, it's really about adjusting. It's, it is loose. I think that is, and I think that's what you hit on. And I think that's the struggle with the tools is, and I'll just, I will interact and interject that like that is very much, this is very much something that we have struggled with it. I've worked with for years is it's like finding the right tool to do the thing that you need to do, but then they don't end up talking. And so I've sort of gone the same route is that I'm more and more, I'm just like, okay, let's simplify it down because I would rather have something that is, you know, 80% there and it gives the developers and everybody one place to see everything. Then something that's then three things that are a hundred percent there, but then they have to jump around, which sort of leads me to my next question on this is that, is the, it's really, I guess the people side of this, because one of the struggles I see when we, this is with agile in general, when you start pulling the team into, you're just part of the team as opposed to your developer, or you're a database guy, or you're a QA person, or you're a front end and giving the information, which hits on your early on, you said like, and I agree, is it like the developers are not brought in early enough. The team is not involved sometimes later into that. And there's just, there's just, it goes back into the silos. And so it's the person side of like, how do you address, for example, like talking to a developer and saying, look, you know, this status stuff actually should mean something to you. These, you are expected to, you may not be pulled into every design meeting, but you're expected to have your thoughts on it and take a look at it. And, you know, vice versa is helping people understand, working with them. They say, well, I see too much. And maybe this part of what your tool is, is finding a way to help them. And maybe that's where AI comes in to sort of like, to get to what the right amount is, that perfect, you know, the Goldilocks thing of like, I'm not getting too little information, I'm not getting too much. And I am properly handling and processing it and doing what I need to do and understanding that while I'm not the product manager, I still have work I have to do to help the product manager do their job. There are things that aren't my job per se, but I need to do these tasks in order to get for the team to do better. Yeah, for sure. For sure. I think it's interesting that there was a, I had an early on, a developer I was working with who preferred to work on his own. And this was, I think, this was probably 2015 or so. And wouldn't, didn't like to come to the sprint backlog grooming sessions. I was perpetually late to the office, but a brilliant, really good software developer, and he was doing things in his timeframe, you know, essentially two to three times faster than everybody else in the team. But he wasn't participating as part of the team. And so sometimes he would work on things that he shouldn't be working on, or sometimes he would finish something, hand it off and not really telling you when that he had finished it and it was ready for the next step. And that was partially a communication problem, but partially just a way he works problem. And this was, you know, again, he was doing work from home and everybody else was working in the office and we hadn't really worked on that hybrid approach yet. And so we didn't have a great solution for that. And I think that's where this sort of things really started to expose themselves to me was these issues around, you know, folks in the office versus folks that are remote and different ways of doing things and wanting to be involved in certain aspects and not wanting to be involved in others. And the certain tools don't allow that flexibility. And our tool is not perfect. We are constantly adjusting and getting feedback from users. And that's the idea is to adapt to not just the way product managers work and developers work, but really anybody in that, a QA person, a designer needs to be more involved in different aspects of those steps as well. And so I think that's the key for any process or any set of tools and is to allow a user to see the information that they want and be able to act on it, but not get overwhelmed with that amount of information. Right. And because it can be, if you've logged into a Jira dashboard or any of those things, it can be overwhelming the amount of information. If you're not in there every day, you don't know what to look for. And I've had mornings where I've logged in and I don't know even what to do today because there's so many things. It feels like there's a list of high product and everything is priority one, right? Everything is this highest priority possible. And I think that's where, not just, you know, it's not just a tool problem, it's a management problem and a process problem. And I think one of the things that we've done in the past and that I like to do is instead of focusing on a weekly sprint meeting or backlog is to go in every day and look through the backlog and prioritize things and get feedback from the developers and the product managers and adjust it. So if you've used like Kanban, for example, and you've got a SwimLink, that's your, you know, sprint ready or your back sprint backlog, whatever it is, it should be top down prioritized. So that, I mean, the next developer comes in, they can pull it in and start to work on it and assign it to themselves. But as soon as one person removes something or they move something down the list because they all of a sudden, you know, oh, I'm better at this and I could do this really fast and so I want to do that so I can, you know, contribute. Now, all of a sudden, it's slightly unorganized, right? And people are pulling from different areas and you're not going back and you're not revisiting that. That's one of the things I tell my team and developers as well as product managers is that AI can help with a lot of things and automation can help with a lot of things. But the thing it doesn't know and it can't, it's not very creative, right? And it can't go through and look at a full list of things and understand what should be the top priority. It can look at an individual ticket or issue and say this should be a high priority or not based on this or this or this. But it doesn't do a good job of grouping those things and managing those things together. And so you have to go in and do that. And that's the, that's not just the current problem. That's always going to be a problem. And I think that the developers adjusting to that and product managers adjusting to that is part of that. Essentially, the solution is to just sort of say, I need to be more involved at this level in terms of prioritization, but maybe I don't need to be as involved in reviewing the tests down the road or maybe the UI implementations. I don't need as much information. So I'm going to filter those out at the top level so that I only see the things that I need to do every day. So I know I have a daily task of reviewing the backlog and I know I have a daily task of making sure that all of my code's been checked in at the end of the day and that all of the comments are there. And I followed up on any pull request reviews or anything else that I need to do. Bringing that all into one area. And it could be as simple as, you know, and to me, I think the best developers are the ones that want to automate everything because they're a little lazy, right? And good developers have that sort of lazy gene in them where they want to automate everything, right? They want to avoid having to do redundant, boring things. So even if it's just a script that you write on your own to pull from GitHub and to pull from JIRA or whatever it is you're managing and create your own universal backlog where you can just see the things that are important to you, that helps so much that first part of the day where you're just going in and looking at what are my priorities, that's the information you want to see at the beginning of the day, right? Is what do I need to work on? And then if something comes in in the middle, which it almost always does an issue from a customer or the, we used to call the executive backlog, which is the CEO had something that needs to be out right now because he's already promised it to some customer or something else and you need to go in and adjust it so that like being able to see that priority right away is the most important thing. And so filters building, even if it's your own tool, just figure out a way to sort of get your own priority backlog in place so that you can manage it that way. As long as you're updating it in the other tools, that's what will matter for the rest of the team. So ideally communication all happens in one place, but if you don't have that, if you're at an organization that doesn't prioritize that for you, then I think do it on your own, figure out a way to manage your own backlog and automate it and then start to show that to people and say, hey, this is the kind of tool we need. This is the thing that we need is for developers to prioritize based on their own set of filters and then share that with the rest of the team. And that is where we're going to pause this part of it. Don't worry, we will be back. We will be continuing to talk to him. We're going to continue to like just pivot and zig and zag and shake and bake and all that goodness because this goes all over the place, but it really is like, as I think you've already figured out, he's got a lot that he can share and it is very much worthwhile. And it's a, there's a lot of thought invoking statements that have come out of this. There's definitely a lot I'm going to do after we get done with this and that I'm going to consider as well, because there's some things that I'm like, huh, I hadn't really thought of it that way. That being said, as always, if you have suggestions, comments, questions, shoot us an email info at developer.com. Also check us out at developer.com. There's a contact form. You can reach us there. You can leave feedback anywhere on the site, wherever you get podcasts, you can leave this review, you can leave feedback. We'd love to hear it good and bad. And on X, we are at developer.com and we have a developer on our Facebook page because yes, we're that old. We're not like the new people that never even touch Facebook. And out any of those places, we'd love to hear from you because you are part of what makes us better while we're trying to make you guys better as building better developers that we try to do. As always go out there and have yourself a great day, a great week, and we will talk to you next time. This was sponsored by RB Consulting, your partner in building smarter, scalable tech. From startups to established teams, RB Consulting helps you turn tech chaos into clarity with proven roadmaps and hands-on expertise. Visit rb-sns.com to start your next step forward. Also sponsored by Envision QA. They help businesses take control of their software by focusing on what matters most, quality, reliability, and support you can count on. Find out more at EnvisionQA.com. Thanks for tuning in to the Develop the Newer Podcast where we're all about building better developers and better careers. I'd love to hear your thoughts or feedback, so drop a note to info at DevelopTheNewer.com. Be sure to subscribe on Apple Podcasts, YouTube, or wherever you listen. And remember, a little bit of effort every day adds up to a great success. Keep learning, keep growing, and we'll see you in the next episode.