Detailed Notes
In this episode of Building Better Developers, hosts Rob Broadhead and Michael Meloche sit down with Greg Lind, founder of Buildly and OpenBuild, to explore how teams can bridge the gap in software development using AI, automation, and transparency.
Greg shares how his experiences leading global development teams inspired him to rethink Agile and create the Rapid AI Development (RAD) process — a flexible, human-centered approach that unites developers, product managers, and QA around shared goals.
🎯 In this episode, we discuss: • Why Agile is breaking under modern development pressures • How AI can bridge communication gaps across teams • The importance of automation in collaboration and trust • Practical ways to unify product and development processes • How developers can lead change from within
💬 “AI can tell you what’s urgent, but it can’t understand what’s important.” — Greg Lind
📘 Learn more about Greg Lind: https://www.linkedin.com/in/greglind/
🔗 Visit Buildly.io 🌐 Listen to the episode at https://develpreneur.com/bridging-the-gap-in-software-development-greg-lind-interview-part1/
*Follow-us on:*
* [email protected] * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://x.com/develpreneur * https://www.linkedin.com/company/develpreneur/
#BuildingBetterDevelopers #BuildingBetterFoundations #GregLind #SoftwareDevelopment #AI #Agile #Automation #Teamwork #Leadership #OpenSource
Transcript Text
little better. O, how you how how both you guys how you guys doing this morning? >> I'm doing good. Nice to meet you. And >> nice to meet you. Doing well. >> Grabbing some. Make sure I've got notes in front of me here. It has been one of those. It is a backto backto back meeting day and every one of them wants to go along. So, >> uh, how do this, uh, I will vamp while I'm doing this. Um, how do we do this? Is this going to be very much a conversational kind of approach? We'll start off, uh, do introductions. Um, I'll introduce myself, Michael introduce himself, then we'll allow you to introduce yourself and sort of give a, uh, some of your background and and things like that. Um, and then we will really just sort of start diving into the conversation itself. Um I think I want to our our focus this season is uh fundamentals is foundations of you know building better foundations as a developer and uh the more I've looked at which I probably like everybody recently um how things are developing is that AI is going to be definitely a part of that you know moving forward is that I think it's one of these things that you're going to you need to either figure it out or you're going to be left behind. you know, sort of that kind of stuff. And since that seems to be that's like an area that you uh definitely have spent some time in, have had some conversations about, I think that that's where we can we can take this one and we'll just sort of we'll see where it goes. This is definitely a I call it a geeky kind of thing. A lot of our listeners are, you know, the developer side of it is technical entrepreneur people. So people that can you know there's developers and we talk about career advancement for developers but a lot of that is based on there's a certain point where you're just not going to the best way for you to advance is to be an entrepreneur is to be building you know solutions and understanding how to talk to business about problems and and build such solutions. So, uh, this is >> for sure, >> uh, this is on video as well. Uh, so we'll be recording both audio and video. Uh, we will get you links after the fact, uh, once we've got those things available. Um, and then we'll, when we wrap up, uh, we'll ask you for, you know, contact information, best way to reach you. So, those links as well, we'll put in the show notes. Uh, this is a, uh, will run about an hour. It will end up being two episodes. We like to take our, you know, we'll do essentially we do hour interviews and we split them into about, you know, 20 25 minutes each half of it just depending on where it it best fits based on the topics. Uh that will all be part of the editing side that Michael will too. Um he have any questions or comments? >> No, I mean it sounds cool. I like like what you guys are doing and it's definitely aligned with what we're doing at Bidley. So be interesting. >> Excellently. then um then we will dive right into it. I'll get my little three two one. Well, hello and welcome back. We are continuing our season on building better foundations. Uh this is the developer our podcast building better developers this episode uh and next one we're going to be into an interview again and uh I will save that for a few moments from now. First introduce myself. I am Rob Redhead, one of the founders of develop developer, also the founder of RB Consulting where we help you leverage technology and do technology better, build yourself a road map for success. Good thing and bad thing. Uh good thing is is we are getting into the holiday season. Um this is always a part part of the year that I enjoy. I actually do find a little bit of downtime here and there to be able to get some relaxing in and things. Uh 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. Um 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 of things I wanted to knock out, uh 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." Uh, 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 Malashsh. I'm one of the co-founders of Building Better Developers, also known as Developer. 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. Uh good thing, bad thing. Uh similar to you, you know, we just got past Halloween. We're getting into that uh you know, 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's just kind of flown by. But, uh, good thing is we're getting into the holiday seasons and lots of food. >> And, uh, our guest today is Gregory Lind. He's a CEO and founder of Builderly, which is very hard to say. I have to say it slowly, but I'm going to allow you to go ahead and introduce yourself, Greg. >> Yeah, for sure. It's also hard to type. I've noticed on more than a few times I've left out that middle L in buildly. Um but yeah, so yeah, my name's Greg. I founder of uh Buildly and uh OpenBuild, which is our nonprofit partner. Um and yeah, my our focus is on bringing developers and product managers together into one tool and uh building things as a as a team rather than as two separate teams. And uh yeah, we're we're excited to talk a little bit about the the open source tool that we've built, the AI tools that we've built, and uh yeah, just also the developer prneur thing. I think for us it's it's really about helping developers become uh better at what they do, learn to use AI tools, but also um I think grow into those roles. Especially at Open Build, we have a a program where we train developers to go from a senior to maybe a CTO or VP type process um that we use um inside of Buildly as we work with customers and train folks to become that technical co-founder for another uh founder that maybe is looking for somebody to do that and using a our tools along with AI to help with that. So yeah, excited to talk about it. And that is uh I'm I'm going to dive right into that because I think that is um part of the challenge I've always seen with software development in general is the the siloing of team members where it's like you know 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 as it's just while we while we work as a team it's just like getting the cohesiveness across that team I think is always the challenge. the ones that I've been with that work really well have solved that problem. Uh the ones that don't usually have not solved it. And so I'm really curious from the um from productizing it, from systematizing how to do that better. Um I'd really like to just throw open the floor to that and talk about like how you guys have how you guys see it and how you guys approach it. >> Yeah, I mean it's been a long time coming. I think for me specifically, I I saw a lot of the same problems with the silos. Um, not just from a a team perspective, but obviously from the data perspective as well. And uh one of the first things we did when I when I first started actually working on what is now Buildly um I was on a uh a team called Humanitech in Berlin. And uh we were building a a DevOps platform essentially for uh cloud native and Kubernetes. And uh at that time uh I saw a lot of issues with communication. We we were working with a lot of different um small businesses in the area and some larger businesses and 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 up front, especially from the developer side. And then later on in the process, the product managers would feel left out of the the planning stages or the the backlog grooming stages in some cases or just how you're managing your own personal backlog. And then developers started to feel like they were, you know, 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. Um, and 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-reo processes with microservices were were breaking down that process even more and sort of isolating all of our issues. But at the time, we were using uh trying to use a combination of Jira and then GitHub. And none of the tools really worked for us. So, we couldn't really get any of these things to 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 as I started to spin out buildly from what was then human at the time uh was that we start I think that was right at the beginning of co and everyone was moving to these remote management processes and teams and we I had been doing that for years before that um with an organization called Mercy Corps with teams remote teams all over the world and uh I I I saw this breakdown down in trust between the the software developers and the product managers as well where they start they started to feel like they 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. um 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 where it all started. And I think where we 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 had 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 uh then you could see everything all in one place. And then all of a sudden the the 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 they were confused as to why one ticket that seemed like a small issue would get an estimate that would bring it down to, you know, essentially a one-day um development process, but one that seemed much more complicated. Um sometimes would get a week or or so. And then what so why were why was that happening? Why was this a week and why was this a day? And then the the flip side of that is things that they thought were easy were sometimes taking much longer and or or when QA got involved as 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. Um 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 uh communication to happen from everyone. So it's not just agile stakeholders, right? The old pigs and chickens at the who's who's more involved in the breakfast sort of approach. Everybody has an has a equal access to certain aspects of the 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 and I think the the biggest issue that we saw then and we still see to a certain degree is 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 AIdriven development tools and we also were looking at CI/CD tools and automatic deployment to multiple from multiple um repos into multiple hosting platforms right so we were doing multicloud as well as multi-reo deployments and we we started to see agile just not it's just it was almost like breaking under the pressure and and so we also started to work on our own process where we call it our RAD process which is just a 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 some huge benefits on the team side as well so moving away from just the traditional cycles you know one or two week or 3 week sprints into these releasebased, timebased systems where you could 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 the tools and everything else we want to continue to add more APIs and more uh bring in more u 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 there's additional there's there's always process problems I think and and I think we can 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 doesn't matter if you've also got other automation CI/CD tools that are sending you email messages or or um just you know platform messages, uh debugging tools, all of these different issues from from uh QA and and wherever else you can manage it all in one place. See your 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. Um, and I think that's the that's the next key and that's the part that we're working on the most with de our developers and our partner developers as well. >> There's a lot there. Um let's start with um how was with how you saw agile breaking because this is something that actually I've seen I've run into a couple different cases and of similar kinds of things and I'm wondering is it does your pro is was it breaking because the uh 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? Um, or was there were there other factors that were breaking it? >> I think those were the two primary ones. I think you hit it right on the head with the it's multi multi-reo obviously adds addition add additional levels of complexity um in anything you're doing but the CI/CD tools that are built for for this are are really handling it really well we use mostly um GitHub for GitHub actions uh to do it for for the most part of it for us right now but as you started to get into um 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 we started to look at that and 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. Um, and that was just sort of managing it all in one tool and essentially ignoring GitHub issues, which I think the the other part of this that I really wanted to see happen that that I don't think agile has ever really accommodated is the fact that I'm already um doing updates every time I check in code, right? I'm putting a a commit message in every time. the more detailed. Sometimes I I admit I I put in some really bad commit messages and other times I put in some, you know, detailed ones, maybe going too detailed, but I really felt like that part of the process was never really uh included in the in the agile process. Um, 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 and we had because of the multi-reo approach we could do a patch in one repo and a um a feature update in another repo and then maybe another patch or two in 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 of list of things to do. So that's where we really started to see it break apart. Um and on top of that I think as this and this is something that I think every generation you know of of or you know and I don't like the term as we go into the you know 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 that 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 um they're not getting that mentorship process either. >> And I think what you're what you miss when you jump into a team all of the sudden is these process the all of the different taxonomy around how the different labels for things. The different types of words you need to use. What is 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 and you have to then learn a whole new set of way of working with the team and most of the most of the um product management tools and project management tools and let's just 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 um and that's kind of the 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 insource 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 is started to see like 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 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. Um for us though we started to see as we work mostly with startups that were fast-paced and a lot of different outsourced developers. Um it's hard it's really hard to teach all of that to somebody. Um and there aren't really any tools that do that for you. And so that's kind of where we we came into it is like we wanted to to revamp agile and sort of create our own version of it that fit what we do. Um and it 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. Um, and I think that's the app 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 I've written a couple of articles and I actually wrote a book um last year um about this called radical um trans radical therapy for software development teams and it's um 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 and really every startup that we worked with we started to see transparency um once we moved to our new process. We moved away from agile included and and and 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 you know by essentially revamping agile to to be our own thing we are also fitting into the big a agile approach. uh but at the same time it's it's a new flavor at the very least if not a complete rework of how agile happens in a in an not just AIdriven software but I think in a more automated approach for cloud native especially I agree I think this is very much it is it's funny because it really is to me it's it's agile as the agile manifesto reads and not you know people think agile is you know conbon or sprints or scrums or 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 you hit on. And I think that's the struggle with the tools is uh and I'll just I I will interact and interject that like that is very much this is very much something that we have struggled with that 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 than something that's a then three things that are 100% there but then they have to jump around. uh 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 uh this is with agile in general when you start pulling the team into you're just part of the team as opposed to you're a developer or you're a database guy or you're a QA person or you're a front end >> um and giving the information uh which you know hits on your your early on you said like and I agree is that 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 and take a look at it and uh you know vice versa is helping people understand working with them they say well I see too much and maybe this is 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 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 a early on a developer I was working with who preferred to work on his own uh one and this was I think this was probably 2015 or so and um wouldn't didn't like to come to the sprint backlog grooming sessions um I was perpetually late to the office uh but a brilliant really good software developer and he was doing things in his time frame um you know essentially two to three times faster than everybody else in the team. Um 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 tell anyone that he had finished it and it was ready for the next step. And that 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 uh solution for that. And I think that's where this this sort of things really started to expose themselves to me was these issues around uh 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 and the certain tools don't allow that flexibility and and our tool is not perfect. we we are constantly um adjusting it and and getting feedback from users and that's the the idea is to adapt to not just the way product managers work and developers work but really anybody and that a a QA person a designer needs to be more involved in different aspects of those steps as well and so I I think that's the the key for for any process or any set of tools and it is to allow a user to see the information that they want uh and be able to act on it but not get overwhelmed with that amount of information, right? And because it it can be if you've logged into a a Jira dashboard or or you know 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 pri 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 it's a management problem and a process problem um and I think one of the things that that we've done in the past and and that I like to do is instead of focusing on obi sprint meeting or backlog um 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 Canbon for example and you've got a swim link that's your what you know sprint ready or your your back sprint backlog whatever it is it should be top down prioritize so that when the next developer comes in they can pull it in and start to work on assign it to themselves but as soon as one person removes something or they move something down 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 contribute. Now all of a sudden it's slightly unorganized, right? And and people are pulling from different areas and you're not going back and you're not re revisiting that. That's one of the things I I tell my 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 it doesn't know and it can't is 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 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 the that's not just the the a current problem. That's always going to be a problem. Um and I think that the developers adjusting to that and and product managers adjusting to that um is part of that essentially the the solution is to just sort of say I need to I need to be more involved at this level and in terms of prioritization but maybe I don't need to be as involved in overviewing and reviewing the tests down the road or maybe the 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 a daily task of reviewing the backlog and I know I have a daily task of making sure that my all of my codes been checked in at the end of the day and that all of the comments are there and I've followed up on any um 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 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 if it's a 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 any something comes in in the middle, which it almost always does, an issue from from a customer or the uh um we used to call the executive backlog, which is the CEO had something that needs to be out right now cuz 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 buil filters build it 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 it's up 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 you know I think do it on your own. figure out a way to to manage your own backlog that and automate it and then start to you know 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 zigg and zag and shake and bake and all that goodness. Uh 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. Uh and it is very much worthwhile and it's a there's a lot of thought invoking statements that have come out of this. Uh there's definitely a lot I'm going to do after we get done with this and uh that I'm going to consider as well because there's some things there I'm like, "Huh, I had really thought of it that way." That being said, uh, as always, if you have suggestions, comments, questions, shoot us an email at [email protected]. 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 podcast, you can leave us a review, you can leave feedback. We'd love to hear it, good and bad. Uh, and on X, we are developer. We have a developer Facebook page because yes, we're that old. We're not like the new people that never even touched 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 uh 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.
Transcript Segments
little better. O,
how you how how both you guys how you
guys doing this morning?
>> I'm doing good.
Nice to meet you.
And
>> nice to meet you.
Doing well.
>> Grabbing some.
Make sure I've got notes in front of me
here.
It has been one of those. It is a backto
backto back meeting day and
every one of them wants to go along. So,
>> uh, how do this, uh, I will vamp while
I'm doing this. Um,
how do we do this? Is this going to be
very much a conversational kind of
approach? We'll start off, uh, do
introductions. Um, I'll introduce
myself, Michael introduce himself, then
we'll allow you to introduce yourself
and sort of give a, uh, some of your
background and and things like that. Um,
and then we will really just sort of
start diving into the conversation
itself. Um
I think I want to our our focus this
season is uh fundamentals is foundations
of you know building better foundations
as a developer and uh the more I've
looked at which I probably like
everybody recently um how things are
developing is that AI is going to be
definitely a part of that you know
moving forward is that I think it's one
of these things that you're going to you
need to either figure it out or you're
going to be left behind. you know, sort
of that kind of stuff. And since that
seems to be that's like an area that you
uh definitely have spent some time in,
have had some conversations about, I
think that that's where we can we can
take this one and we'll just sort of
we'll see where it goes. This is
definitely a I call it a geeky kind of
thing. A lot of our listeners are, you
know, the developer side of it is
technical entrepreneur people. So people
that can you know there's developers and
we talk about career advancement for
developers but a lot of that is based on
there's a certain point where you're
just not going to the best way for you
to advance is to be an entrepreneur is
to be building you know solutions and
understanding how to talk to business
about problems and and build such
solutions. So, uh, this is
>> for sure,
>> uh, this is on video as well. Uh, so
we'll be recording both audio and video.
Uh, we will get you links after the
fact, uh, once we've got those things
available. Um, and then we'll, when we
wrap up,
uh, we'll ask you for, you know, contact
information, best way to reach you. So,
those links as well, we'll put in the
show notes. Uh, this is a, uh, will run
about an hour. It will end up being two
episodes. We like to take our, you know,
we'll do essentially we do hour
interviews and we split them into about,
you know, 20 25 minutes each half of it
just depending on where it it best fits
based on the topics. Uh that will all be
part of the editing side that Michael
will too. Um he have any questions or
comments?
>> No, I mean it sounds cool. I like like
what you guys are doing and it's
definitely aligned with what we're doing
at Bidley. So be interesting.
>> Excellently. then um then we will dive
right into it. I'll get my little three
two one. Well, hello and welcome back.
We are continuing our season on building
better foundations. Uh this is the
developer our podcast building better
developers this episode uh and next one
we're going to be into an interview
again and uh I will save that for a few
moments from now. First introduce
myself. I am Rob Redhead, one of the
founders of develop developer, also the
founder of RB Consulting where we help
you leverage technology and do
technology better, build yourself a road
map for success. Good thing and bad
thing. Uh good thing is is we are
getting into the holiday season. Um this
is always a part part of the year that I
enjoy. I actually do find a little bit
of downtime here and there to be able to
get some relaxing in and things. Uh 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.
Um 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 of
things I wanted to knock out, uh 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." Uh, 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
Malashsh. I'm one of the co-founders of
Building Better Developers, also known
as Developer. 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.
Uh good thing, bad thing. Uh similar to
you, you know, we just got past
Halloween. We're getting into that uh
you know, 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's just kind of flown by. But, uh,
good thing is we're getting into the
holiday seasons and lots of food.
>> And, uh, our guest today is Gregory
Lind. He's a CEO and founder of
Builderly, which is very hard to say. I
have to say it slowly, but I'm going to
allow you to go ahead and introduce
yourself, Greg.
>> Yeah, for sure. It's also hard to type.
I've noticed on more than a few times
I've left out that middle L in buildly.
Um but yeah, so yeah, my name's Greg. I
founder of uh Buildly and uh OpenBuild,
which is our nonprofit partner. Um and
yeah, my our focus is on bringing
developers and product managers together
into one tool and uh building things as
a as a team rather than as two separate
teams. And uh yeah, we're we're excited
to talk a little bit about the the open
source tool that we've built, the AI
tools that we've built, and uh yeah,
just also the developer prneur thing. I
think for us it's it's really about
helping developers become uh better at
what they do, learn to use AI tools, but
also um I think grow into those roles.
Especially at Open Build, we have a a
program where we train developers to go
from a senior to maybe a CTO or VP type
process um that we use um inside of
Buildly as we work with customers and
train folks to become that technical
co-founder for another uh founder that
maybe is looking for somebody to do that
and using a our tools along with AI to
help with that. So yeah, excited to talk
about it. And that is uh I'm I'm going
to dive right into that because I think
that is um part of the challenge I've
always seen with software development in
general is the the siloing of team
members where it's like you know 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 as it's just
while we while we work as a team it's
just like getting the cohesiveness
across that team I think is always the
challenge. the ones that I've been with
that work really well have solved that
problem. Uh the ones that don't usually
have not solved it. And so I'm really
curious from the um from productizing
it, from systematizing how to do that
better. Um I'd really like to just throw
open the floor to that and talk about
like how you guys have how you guys see
it and how you guys approach it.
>> Yeah, I mean it's been a long time
coming. I think for me specifically, I I
saw a lot of the same problems with the
silos. Um, not just from a a team
perspective, but obviously from the data
perspective as well. And uh one of the
first things we did when I when I first
started actually working on what is now
Buildly um I was on a uh a team called
Humanitech in Berlin. And uh we were
building a a DevOps platform essentially
for uh cloud native and Kubernetes. And
uh at that time uh I saw a lot of issues
with communication. We we were working
with a lot of different um small
businesses in the area and some larger
businesses and 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 up front, especially from the
developer side. And then later on in the
process, the product managers would feel
left out of the the planning stages or
the the backlog grooming stages in some
cases or just how you're managing your
own personal backlog. And then
developers started to feel like they
were, you know, 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. Um, and 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-reo
processes with microservices were were
breaking down that process even more and
sort of isolating all of our issues. But
at the time, we were using uh trying to
use a combination of Jira and then
GitHub. And none of the tools really
worked for us. So, we couldn't really
get any of these things to 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 as I
started to spin out buildly from what
was then human at the time uh was that
we start I think that was right at the
beginning of co and everyone was moving
to these remote management processes and
teams and we I had been doing that for
years before that um with an
organization called Mercy Corps with
teams remote teams all over the world
and uh I I I saw this breakdown down in
trust between the the software
developers and the product managers as
well where they start they started to
feel like they 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. um 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 where it all
started. And I think where we 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 had 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 uh
then you could see everything all in one
place. And then all of a sudden the the
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 they were
confused as to why one ticket that
seemed like a small issue would get an
estimate that would bring it down to,
you know, essentially a one-day um
development process, but one that seemed
much more complicated. Um sometimes
would get a week or or so. And then what
so why were why was that happening? Why
was this a week and why was this a day?
And then the the flip side of that is
things that they thought were easy were
sometimes taking much longer and or or
when QA got involved as 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. Um 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 uh
communication to happen from everyone.
So it's not just agile stakeholders,
right? The old pigs and chickens at the
who's who's more involved in the
breakfast sort of approach. Everybody
has an has a equal access to certain
aspects of the 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
and I think the the biggest issue that
we saw then and we still see to a
certain degree is 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 AIdriven development tools and
we also were looking at CI/CD tools and
automatic deployment to multiple from
multiple um repos into multiple hosting
platforms right so we were doing
multicloud as well as multi-reo
deployments and we we started to see
agile just not it's just it was almost
like breaking under the pressure and and
so we also started to work on our own
process where we call it our RAD process
which is just a 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 some huge
benefits on the team side as well so
moving away from just the traditional
cycles you know one or two week or 3
week sprints into these releasebased,
timebased systems where you could 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 the tools and
everything else we want to continue to
add more APIs and more uh bring in more
u 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
there's additional
there's there's always process problems
I think and and I think we can 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 doesn't matter if you've also
got other automation CI/CD tools that
are sending you email messages or or um
just you know platform messages, uh
debugging tools, all of these different
issues from from uh QA and and wherever
else you can manage it all in one place.
See your 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. Um, and I think that's the
that's the next key and that's the part
that we're working on the most with de
our developers and our partner
developers as well.
>> There's a lot there. Um let's start with
um how was with how you saw agile
breaking because this is something that
actually I've seen I've run into a
couple different cases and of similar
kinds of things and I'm wondering is it
does your pro is was it breaking because
the uh 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? Um, or was there were
there other factors that were breaking
it?
>> I think those were the two primary ones.
I think you hit it right on the head
with the it's multi multi-reo obviously
adds addition add additional levels of
complexity um in anything you're doing
but the CI/CD tools that are built for
for this are are really handling it
really well we use mostly um GitHub for
GitHub actions uh to do it for for the
most part of it for us right now but as
you started to get into um 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 we
started to look at that and 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. Um, and that was just sort of
managing it all in one tool and
essentially ignoring GitHub issues,
which
I think the the other part of this that
I really wanted to see happen that that
I don't think agile has ever really
accommodated is the fact that I'm
already um doing updates every time I
check in code, right? I'm putting a a
commit message in every time. the more
detailed. Sometimes I I admit I I put in
some really bad commit messages and
other times I put in some, you know,
detailed ones, maybe going too detailed,
but I really felt like that part of the
process was never really uh included in
the in the agile process. Um, 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 and we had
because of the multi-reo approach we
could do a patch in one repo and a um a
feature update in another repo and then
maybe another patch or two in 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 of list of
things to do. So that's where we really
started to see it break apart. Um and on
top of that I think as this and this is
something that I think every generation
you know of of or you know and I don't
like the term as we go into the you know
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 that 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 um
they're not getting that mentorship
process either.
>> And I think what you're what you miss
when you jump into a team all of the
sudden is these process the all of the
different taxonomy around how the
different labels for things. The
different types of words you need to
use. What is 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 and you
have to then learn a whole new set of
way of working with the team and most of
the most of the um product management
tools and project management tools and
let's just 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 um and that's
kind of the 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 insource
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 is started
to see like 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
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. Um for us though
we started to see as we work mostly with
startups that were fast-paced and a lot
of different outsourced developers. Um
it's hard it's really hard to teach all
of that to somebody. Um and there aren't
really any tools that do that for you.
And so that's kind of where we we came
into it is like we wanted to to revamp
agile and sort of create our own version
of it that fit what we do. Um and it 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. Um, and I think that's the
app 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 I've written a couple
of articles and I actually wrote a book
um last year um about this called
radical um trans radical therapy for
software development teams and it's um
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 and really
every startup that we worked with we
started to see transparency
um once we moved to our new process. We
moved away from agile included and and
and 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 you know by essentially
revamping agile to to be our own thing
we are also fitting into the big a agile
approach. uh but at the same time it's
it's a new flavor at the very least if
not a complete rework of how agile
happens in a in an not just AIdriven
software but I think in a more automated
approach for cloud native especially
I agree I think this is very much it is
it's funny because it really is to me
it's it's agile as the agile manifesto
reads and not you know people think
agile is you know conbon or sprints or
scrums or 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 you hit on. And I think
that's the struggle with the tools is uh
and I'll just I I will interact and
interject that like that is very much
this is very much something that we have
struggled with that 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 than something that's a
then three things that are 100% there
but then they have to jump around. uh
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 uh this is with agile in general when
you start pulling the team into you're
just part of the team as opposed to
you're a developer or you're a database
guy or you're a QA person or you're a
front end
>> um and giving the information uh which
you know hits on your your early on you
said like and I agree is that 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
and take a look at it and uh you know
vice versa is helping people understand
working with them they say well I see
too much and maybe this is 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 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 a
early on a developer I was working with
who preferred to work on his own uh one
and this was I think this was probably
2015 or so and um wouldn't didn't like
to come to the sprint backlog grooming
sessions um I was perpetually late to
the office uh but a brilliant really
good software developer and he was doing
things in his time frame um you know
essentially two to three times faster
than everybody else in the team. Um 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 tell anyone
that he had finished it and it was ready
for the next step. And that 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 uh
solution for that. And I think that's
where this this sort of things really
started to expose themselves to me was
these issues around uh 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 and the certain tools
don't allow that flexibility and and our
tool is not perfect. we we are
constantly um adjusting it and and
getting feedback from users and that's
the the idea is to adapt to not just the
way product managers work and developers
work but really anybody and that a a QA
person a designer needs to be more
involved in different aspects of those
steps as well and so I I think that's
the the key for for any process or any
set of tools and it is to allow a user
to see the information that they want uh
and be able to act on it but not get
overwhelmed with that amount of
information, right? And because it it
can be if you've logged into a a Jira
dashboard or or you know 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 pri 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 it's a management
problem and a process problem um and I
think one of the things that that we've
done in the past and and that I like to
do is instead of focusing on obi sprint
meeting or backlog um 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
Canbon for example and you've got a swim
link that's your what you know sprint
ready or your your back sprint backlog
whatever it is it should be top down
prioritize so that when the next
developer comes in they can pull it in
and start to work on assign it to
themselves but as soon as one person
removes something or they move something
down 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
contribute. Now all of a sudden it's
slightly unorganized, right? And and
people are pulling from different areas
and you're not going back and you're not
re revisiting that. That's one of the
things I I tell my 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 it doesn't know
and it can't is 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 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 the
that's not just the the a current
problem. That's always going to be a
problem. Um and I think that the
developers adjusting to that and and
product managers adjusting to that um is
part of that essentially the the
solution is to just sort of say I need
to I need to be more involved at this
level and in terms of prioritization but
maybe I don't need to be as involved in
overviewing and reviewing the tests down
the road or maybe the 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 a daily
task of reviewing the backlog and I know
I have a daily task of making sure that
my all of my codes been checked in at
the end of the day and that all of the
comments are there and I've followed up
on any um 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 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 if it's a 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 any something comes in in the
middle, which it almost always does, an
issue from from a customer or the uh um
we used to call the executive backlog,
which is the CEO had something that
needs to be out right now cuz 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 buil filters build it 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 it's up 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 you know
I think do it on your own. figure out a
way to to manage your own backlog that
and automate it and then start to you
know 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 zigg and zag and shake and
bake and all that goodness. Uh 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. Uh and it is very much worthwhile
and it's a there's a lot of thought
invoking statements that have come out
of this. Uh there's definitely a lot I'm
going to do after we get done with this
and uh that I'm going to consider as
well because there's some things there
I'm like, "Huh, I had really thought of
it that way."
That being said, uh, as always, if you
have suggestions, comments, questions,
shoot us an email at [email protected].
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 podcast,
you can leave us a review, you can leave
feedback. We'd love to hear it, good and
bad. Uh, and on X, we are developer. We
have a developer Facebook page because
yes, we're that old. We're not like the
new people that never even touched
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 uh 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.