#255 - Stop Vibe Coding: Spec-Driven Development with The BMad Method - Brian Madison

[00:02:02] Introduction

Henry Suryawirawan: Hello guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m very excited to meet someone who is the creator of the BMad method, B-M-A-D. So I haven’t heard about BMad method before, but someone in my community actually mentioned about it, and he found it really interesting and useful to use it to apply agentic AI and all that for your software development. So I think, today, I’m really looking forward for this conversation. Brian Madison, welcome to the show.

Brian Madison: Thank you, Henry. I’m so excited to be here. And that’s so cool that somebody in your community, you know, let you know about the BMad. So I’m happy to be here and talk to it about, you know, talk about it with you. It’s very exciting.

[00:02:44] How Did the US Army Shape Brian’s Journey into Software Engineering?

Henry Suryawirawan: Yeah. So maybe before we go into the BMad, so when I did a little bit of research looking at your background, one interesting thing that I found is that you actually started in the US Army first before going into software engineering, software development. So maybe tell us this unique background, how did it shape you? And what actually brought you, you know, the knowledge from US Army to software engineering?

Brian Madison: Yeah, sure. Henry. Yeah, that’s a great question. I started out actually in electronics and engineering, so I’ve pretty much been in engineering all my life. You know, I guess I should go back even before the Army when I was a child, you know, I grew up with a Texas Instruments computer and I started, you know, probably programming when I was, I don’t know, I don’t even — Like I remember being in kindergarten and typing away on computers. But I really had a love for computers and electronics and went in the army to do that. It really did shape me in ways I never expected. I know this is gonna sound a little cliche, but it really did teach me leadership. I probably grew up as a child with not a lot of self-confidence maybe, and I really developed a sense of self-confidence and leadership in the army that I don’t know if I - maybe I always had it - but I really developed that. In the Army though, you really do turn, you know, get to lead in interesting situations. And there’s some things that I learned there that have really — even now I was thinking about this the other day — it really plays in my career right now.

When you’re leading, you know, you have to show self-confidence don’t always have that for the benefit of the people following you — and this really applies even in the workplace when you’re, you know, leading, when you’re the tech lead on a team — you have to show some confidence and leadership, but you also have to place trust on your team. You’re responsible for the team. You are the owner at the end of the day. You are responsible for the actions of your team, but you have to trust in your team and delegate. And I think, I learned a lot of that because it’s very easy to think you have to do it all, but you really learn when you’re managing a large group of team in the army or a squad. You have to really rely on the people on your team. And that’s, you know, something that’s hard to do at first. And I really learned that.

Another great thing that happened to me in the Army though, Henry, is I got very lucky. I was assigned to a lot of NATO units, which means I was working with the Dutch and the French and Canadians, and so many different countries. So I was assigned in these units with very diverse groups of people that I would’ve never been exposed to. I got to travel the world and get outside of the bubble of America. A lot of people that grew up in America, they’re kind of like in this bubble. I loved traveling the world and just meeting people everywhere, and I really have carried that through all my life. I really strongly believe in good, diverse teams with interesting perspectives. And I don’t — I mean, maybe I would’ve developed that over time —but I really enjoyed just that opportunity to see so many different perspectives and meet people from so, you know, so many places. So that’s really all.

Probably indirectly, shaped my career. And then when I got out of the military, it was an easy transition into, still working for the Department of Defense. That’s what really transitioned me into working on simulations and computers. And I realized I really loved just working with computers and software and programming, and kind of made a career out of it since then. So it really, you know, it really shaped where I am now. So it’s been a long time, Henry. It’s been, you know, over 20 years now since I’ve been in the military. And so it’s kind of interesting thinking back on it and how it has kind of shaped where I’ve ended up.

[00:06:35] How Can Engineers Overcome Imposter Syndrome and Build Self-Confidence?

Henry Suryawirawan: Yeah. Thanks for sharing your background and your story. So definitely very interesting journey, I would say. And you mentioned about self-confidence. From many engineers that I know, some of them actually kind of like lack self-confidence, especially, you know, in a big team set up or maybe talking to executives. Some engineers really did have challenges, especially, you know, when conveying messages and they’re somehow not confident, especially talking about technical stuff. Maybe from your point of view, right, from your experience, because you have turned yourself to more self-confident, how would you advise people to kind of like be more self-confident?

Brian Madison: You know, that can be something that’s really hard at first, especially if you do struggle with self-confidence. But a few things that I use, and I have shared this with other people, is if you cannot explain an idea, it doesn’t matter how good it is, if you cannot convey the idea. So sometimes you have to believe in what you’re doing and just share the idea with confidence. Some people will say fake it till you make it. I don’t know. That’s, I don’t know if that’s really the right way to say it, but you just, you gotta develop that, whether you feel it inside. Everybody suffers from imposter syndrome. I still do, Henry. I mean, I’m feeling it right now, right? But like, should I really be on this podcast? But no, I, actually, I’m happy to be here and I believe it. But everybody’s gonna have that voice of self-doubt or many people will. You just gotta remember that not everybody sees, you know. They’re listening to you because they believe you have something to tell them. I believe I have something to share with you, Henry. I believe you have stuff to share with me. So whether we have that voice in our head, just remember that is just the voice in your head and not everybody feels that way because or else they wouldn’t even be listening to you. So feel good about yourself, share your message. But as engineers, a lot of times we focus on the code and, you know, the beauty of it and the technical details. But share it with confidence to really explain what it is you’re doing to your audience so they can appreciate it. I think just sometimes trying to get out of your head, it’s easier said than done, but this is something that can be dealt with and built up over time. And sometimes it takes time, but I think everybody can get there. If you work at it, it’s a skill that you can develop.

Henry Suryawirawan: Yeah, speaking about imposter syndrome, definitely, I also feel it. you know, even though how many years of experience you have worked. Especially these days, especially all these technologies seems to advance rapidly. You know, you won’t know everything, right? So definitely always there’s a imposter syndrome, especially people who work in tech. And yeah, being confident is something that can be trained. So I think for everyone who listen, if you’re not confident, you can train that maybe in a smaller scale.

Brian Madison: I really, really I believed that too, Henry.

Henry Suryawirawan: Yeah.

Brian Madison: And I think that’s a, you know, I think that is a good reminder for people. And I, still tell that to people, because I’m pretty confident when I’m speaking in front of people, when I’m presenting to a board or to leadership and people see that, but they might not realize that as leaders we still suffer from that weird voice in our head, right? it doesn’t necessarily go away. But when you’re — I know when you’re new in a career, you feel like, wow, do I really belong here, right? Or wow, I got lucky getting this job. But just know that everybody has gone through that. It’s a universal feeling that I think most go through. And I think as leaders, if we share that we even still go through that sometimes, I think that can actually help build some self-confidence and make people not feel like, oh, I must be weird because I’m feeling this. Because I used to feel like that and I’m like, wow. Like I remember when I was, you know, new in my career. I used to have those thoughts and not think that anybody felt that way. But then you kind of start to realize it’s universal.

[00:10:23] What Does BMad Actually Stand For?

Henry Suryawirawan: Yeah. So let’s go into your the BMad thing, right? So first of all, I would like to clarify what does BMad stand for? Because I see a couple of different definition, but I also kind of like see your name. Brian Madison. Is this like Brian Madison as BMad? So tell us what does it stand for actually?

Brian Madison: It really started out as just people — first of all, Henry, if you like, you can’t call me BMad. People actually call me BMad in my day-to-day life. It is just been a nickname for a long time. And when I was starting BMad and I think we’ll talk a little bit more about why I started BMad and how it started. It did, it did not start out as this grand vision where I needed to put a good name on it or anything. So I stuck with BMad and I made the acronym match something. When I was starting BMad though, I really was trying to map processes onto a way of working that I’ve always worked, which was Agile. I’ve been working, you know, for the last 15+ years out of my 25+ year career using Agile methodologies. I’ve been involved in Agile transformations. And for me it was a very good thought framework, so I came up with the breakthrough method of Agile AI-driven development. Over time I realized it’s very hard to say. It’s very long, and it actually ends up spelling like B-M-A-A-D-D. So it doesn’t even work that well. But for what I was doing, it actually does make sense.

So, yes, it is my name. It is the breakthrough method of Agile AI-driven development. But as the platform and what we’ve been building as a community has evolved, I now just call it Build More Architect Dreams because — we’ll talk a little bit about what the BMad method is, but it’s become more than what it originally meant. So yes, there’s not a clear answer, Henry. It means multiple things. But, you know, it’s funny, I was watching another podcast or a video, and I didn’t even know about it. I’m watching it. And it’s funny because like halfway through the host just realized, oh, wait a minute, did this guy just name it after himself? And he, so, so yes. So I don’t know. It’s funny story, I think, but yes, the BMad method means multiple things. But it really is about taking a way of structuring Agile, and, you know, a way to think about working in an Agile method with AI to do context engineering at the end of the day.

Henry Suryawirawan: Right. So definitely it’s a fun trivia, right? So for people who are kind of like maybe confused, what does it stand for? I think maybe, we’ll, let’s just call it whatever that is name in the GitHub, which is like, Build More Architect Dreams, right? Or maybe simply your name as the creator.

Brian Madison: You know what’s funny, Henry, is a lot of people will like use AI just to create like an article about BMad. Maybe they wanna just like, you know, put something up on their social or whatever. And the funny thing is, it’s a little bit better known now by the models, but the older models, like every time I see a different article about BMad, it has a different acronym. Because the AI would just like guess what BMad stands for. So like if you Google it, you might find like a hundred different answers just because people keep putting up different articles and it just whatever it spits out, it’s like. So it’s actually pretty fun ‘cause sometimes I’ll see those and I’m like, dang, I should have used that one, I actually like that one better.

[00:13:49] What Is the BMad Method?

Henry Suryawirawan: Right. Speaking of, which, right, so maybe if you can explain what is BMad method? Because I assume some people might have heard about it, but some may not, right? Especially even like for people who have used, you know, a lot of AI in their software development, some may not have heard about it.

Brian Madison: Yeah, lemme give you a good explanation. The BMad method as it is right now, if you go to, you can look at my YouTube channel, there’s a masterclass on there. Or you can go to the — if you just go to GitHub and you search for the BMad method, you’ll find it. What it is right now is a way to do context and spec engineering. But what it does, as I mentioned, is it maps these Agile personas and ways of working into doing Agile. So when you start out with a project, if you’ve done vibe coding before, Henry, and I think everybody’s tried vibe coding at this point, you eventually hit a wall. Even now the models are very good. You know, they can almost one shot very simple applications. But as you keep working with the agent mode in these tools, eventually you hit a wall and you still hit a wall where — and this is kind of the vibe coding thing, right? You just, you tell it to do one thing and it starts doing it three different ways. Or it gets stuck in these death spirals where it starts testing over and over again and then it will just randomly start throwing stuff away.

The BMad method right now has multiple what will be skills, but they’re just workflows right now, organized in a way to work through. So you work with a product manager to produce a PRD. And you know, a lot of people produce PRDs and then they jump right into the coding. But what I found is just a PRD on its own always isn’t enough. So then you can work with a design agent, a UX expert to help produce your design. You work with an architect to produce your architecture or solution design. And I can go into the benefits of some of these and why these different artifacts matter. But each of these artifacts, if you think of it as a funnel, Henry, they kind of each feed into the next one to eventually produce what our user stories and epics to break your work down. And then those get filled with context, with a different agent and a different process. So then when you actually develop with the agent mode, you take your story, it has everything it needs in that one user story so the agent mode doesn’t have to spend a lot of context reading all of these different documents and trying to figure out what to do. So the theory is when it actually finally picks up that user story, it can pretty much know everything it needs to know to implement the story without making bad decisions. It’s gonna know exactly what libraries and frameworks you’re using and make good decisions.

But the difference I think between the BMad Method and other frameworks, especially when it first started, there’s a lot of, you know, similar stuff out there now. But I didn’t wanna just come up with something where I just give the AI my idea and it spits out all these documents and give them to me.

One of the things I really realized, it’s funny but the BMad method has been going about a year now, almost a year. A lot of people treat the AI like a ChatGPT or, you know, even the agent mode. They ask it a question, give it an answer. I have this function, how would you refactor it? What libraries should I use to do X, Y, Z? What I really started to notice early on with the AI is that it can be an amazing facilitator. I come from a background like you, Henry. I’ve been an engineer, like I said, for 25 years. I know a lot of things and I have opinions. And I think especially as engineers, and this is something else we can talk about if we have time, but don’t think of the AI as just a replacement for your own skills.

So the way I’ve built the BMad method is when it goes through these workflows, it’s having multi-turn conversations with you and trying to pull the best information out of you. It’s gonna ask you questions and it will give you suggestions, but it really tries to teach you as the expert, working with the AI as a partner. It’s almost like pair programming. So you might not be an expert product person because you’re an engineer, but working through the PRD, it’s gonna ask you things that you might not normally think of. Like, you know, do you need admin? What are the user journeys? What are the flows through your system? It will help you come up with more requirements. Because the more that you can kind of specify upfront, the less you’ll be having to change when you’re actually building your application. So that is really why you wanna go through this whole funnel.

But there’s other features also of the BMad method. One of the things that people really seem to love, and this surprised me, but we have a brainstorming mode at the very top of the funnel. So if you don’t even know exactly what you wanna do, this will do brainstorming with you, acting as a facilitator. And people might have done this, you know, if you go into like ChatGPT or some of these other ones, there are brainstorming modes in there, but I’ve developed something that I feel is really special because people have told me sometimes that’s all they use. And people have told me they’ve spent six hours just using the brainstorming agent, using it for everything across their lives, which really surprised me. You know, it’s funny when you release a piece of software and you start learning how other people are using it, it gives you new ideas. And so that’s what happened with here.

So the BMad method has evolved. I know this is a very long answer of what is the BMad method. I hope this is making sense, Henry. But it really is this platform with all of these different skills and tools, but they’re all meant to work together to kind of eventually produce software. But yeah, the brainstorming is special because it has all these techniques in it. It’s working with you. I am horrible at brainstorming. If you give me a whiteboard like Miro or something and they have these brainstorming methods like built into it, I stare at it and it gives me the rules, and I still, I don’t know, I just draw a blank. And I used to always think I’m not a creative person, and so many people have told me this. I never realized it was, I was a creative person. When you treat the AI as a facilitator, and it is not doing the brainstorming for you, it’s perf, it’s specifically set up not to do the brainstorming for you but to give you prompts and ideas and work through these different interesting techniques, all of a sudden you’re coming up with stuff and then it helps you kind of distill down what you came up with. I believe I’m a very creative person now. And that is what so many people have told me. So it’s just so, it’s so cool to see people that think they are not creative. Now all of a sudden, you know, coming up with creative ideas through the help of AI, but it is not like the AI coming up with the ideas. It really is them. So that is really, I think, the special sauce of all the BMad method is it treats you as somebody with ideas and it’s not just doing all of it for you. So let me pause there cause I know that’s a lot.

Henry Suryawirawan: Yeah. Speaking about creativity, I think that kind of like just reminds me that to be creative, it comes back to the questions that you ask, right? Like if you naturally don’t think in questions, sometimes you can get stuck, right? But if you are always like curious, asking different questions, different ways, different perspectives, I think you can be creative. Yeah.

Brian Madison: And that’s the cool thing about the brainstorming method also. Like if anybody wants to try out the BMad method, if you try nothing out, just try out the BMad method brainstorming. It’s different than everything I’ve seen out there. It’s about 50 different techniques built into it. Depending on what you’re working on, you’ll tell it what you wanna do and it’ll suggest some of the techniques. But there’s some crazy ones in there. There’s like alien visitors, you know, and it kind of guides you through if like there were aliens seeing this for the first time, what would their perspective be? There’s, just, there’s idea gardening, there’s some of the classic ones like the thinking hats and, you know, the seven ways of, you know, dissecting a problem. But they’re all just very creative. And again it will, like you said, you hit it on the nail. It’s the questions it asks you, and you’ll come up with some very interesting things. It’s a lot of fun. I love doing it. I, and I even use it for things outside of software engineering. It’s a lot of fun.

[00:22:11] How Does BMad Approach Context and Spec Engineering?

Henry Suryawirawan: So maybe since I’m not like a very advanced BMad user, in fact, I have never used it in my project before. So if I can understand it further, first, it’s like you try to solve this kind of like context engineering problem, especially when you build applications that evolves over time, right? Especially complex software, you kind of want to build some kind of context knowledge base so that the agent will be able to refer to it and always use that to produce the next output, right? And the other thing is that you have these different kind of like personas built in. Maybe some people is, like you can associate that as like agent skills these days, like where you have different skills for different purpose. And, yeah. And then the third thing that I can associate BMad is actually with spec-driven development. Maybe let’s start from there first. Is this a different flavor of spec-driven development or is it something different?

Brian Madison: Yeah, Henry, that’s a great question. You know, when I kind of gotta go back to when I started BMad, there was no name for these things. Like even when I started it, there wasn’t really a name for vibe coding and then like, vibe coding became a very popular term. And I don’t consider BMad vibe coding. I think of it as the antithesis of vibe coding because you’re actually putting some thought and planning upfront and working with a plan. Context engineering was something I didn’t have a name for. It’s funny. I must be like many engineers, you know, they say naming is hard. I’m not good at naming and branding things, I guess. But we were doing context engineering before that was a term. And if you think about what is context engineering, again, it’s taking those ideas, getting it down to something. There wasn’t really a name for it yet, but this thing, I was calling it the user story because that’s what I had for my own vocabulary of working in Agile. So, you know, so long, with acceptance criteria in it.

So a very good user story is not just, you know, as an X, I wanna do Y so that Z, but it’s also putting in good BDD or some kind of style of acceptance criteria. Just in the quote ‘real world’ before AI, if you do your user stories that way when your developers pick them up, they really know what needs to be done for the story. And you can specify things. By building the stories in that way with the BDD, I was noticing these huge improvements in the agent to actually be able to build these complex software applications 100% without me having to type the code. And this is even a year ago when the models were nowhere near what they are now. So that was context engineering. And what we are really producing are specs. So they call it spec engineering now. And that really is what BMad is producing for you.

And now we’re starting to lean into the same language and we’re calling things skills and context engineering and spec engineering. But really the stories with the AC in them, you know, organized into these epics, are specifications. And, you know, just like what we now call spec engineering, it’s basically the same thing. So it’s a spec engineering framework. But the difference with BMad, again, is that you can start at the top of this thought funnel and it really helps you plan and think about what you’re gonna need before you produce all of your specs and have it start working so you’re not hopefully changing this much halfway through or forgetting major features or, oh, I forgot I need a database or I need authentication. So it will guide you and help you through that.

Now you asked about the agents. Henry, when I first made the BMad method, and maybe we can talk a little bit about why I even made it, but it started out as just six files. So I knew that I wanted to create a PRD, and then I knew I wanted to create this like tech stack list, which I called the architecture, and I knew if I was working on UI, I wanted some UX information there. So I just, at the time, you know, all of the prompting guidance was give it a persona, you know, tell it like you are a professional product manager and you have all these attributes. And in the single file, it was talking about here’s the PRD and this is the information that we need, and do this in a facilitative way. So, you know, you’re getting this information out of the user. It grew over time to be multiple files in a separate agent, because I wanted to give people the ability to customize these things. But the reason the agent is there is because it started out as kind of tied to the PRD. It was kind of a thought process. In the real world, when you’re working in Agile on a lot of teams, the product manager is producing the PRD. Or the lead engineer, the tech leader, the architect is producing the solution design. So it’s kind of just how it evolved. But now with agents in the BMad method, the agents have the ability to have memory and remember things, and can evolve over time. So it has become much more than as it started.

There’s another thing that I should also mention about the BMad method is it is part of a platform now. So there is something called the BMad Builder. It’s going through some rework. It will be up really soon. But it’s basically a skill builder for workflows. So you can create your own custom workflows and work them into the BMad method. Unlike most skill builders though and skills in general is, in the BMad method, they all register into a help system and they all have sequencing and information. So as you install different modules, which are like apps for the BMad method or plugins, you know, is what Anthropic calls them. The interesting thing is they all have information about how they’re related to each other and it dynamically populates the help. So if you don’t even know what to do with the BMad method ‘cause it can be overwhelming at first, you can just ask the help and describe to it what you wanna do. And it will suggest, oh, you don’t really know what your idea is yet. You might wanna start with the brainstorming. Oh, you installed the Creative Intelligence Suite and you need to work on a pitch. Well, maybe you want to use that module and use its storytelling for business workflow to help you kind of think of these ideas. So the BMad method has also grown to be a lot of different modules. The community can also contribute modules. And it evolves to help you with many different things. So it’s more than a skill collection because it all ends up being tied together. But it can do now a lot more than just helping you get to the end and do software development.

Henry Suryawirawan: Yeah, sounds like…

Brian Madison: I know that was a very long answer.

[00:29:02] What Sparked the Creation of the BMad Method?

Henry Suryawirawan: Yeah, sounds like it has grown since you started it like a year ago or so, right? So it has grown into like more this framework, modules, plugins. And I’m quite curious when you mentioned just now, right, why … Like the story why you actually started BMad method. Maybe if you can share with me, how did it started in the first place? Like what kind of problems do you see?

Brian Madison: Yeah. That’s a good question. Thanks for asking that, because I think it helps explain where it is also now. Henry, a little over a year ago, I work at a company called Extend. It’s a startup in San Francisco. It’s a, you know, smallish company. And I started out as a staff engineer and now, you know, I manage teams across a product engineering work. And we were using Copilot, and if you remember, you know, Copilot like two years ago, it was basically a very good autocomplete, right? Like at the time it seemed like magic. But a little over a year ago, you know, Cursor’s started getting very big. I assume you’re familiar with a lot of these tools, Henry?

Henry Suryawirawan: Yep.

Brian Madison: Yeah. So Cursor came out. I was working in this organization and we were looking at other tools to replace Copilot. People loved Copilot. You know, we’d been using it about a year. And it was great for autocomplete. You could like show it a function and it would help you like rework the function. And it did seem like magic at the time. When ChatGPT like really started getting big though, like when that 3.1 came out, we started seeing engineers using ChatGPT instead of Stack Overflow, right? And it was getting good at answering questions. And then Cursor came out. And so we were talking about it in the organization and a few of us started playing with Cursor on the side and we were enamored with the agent mode. It was amazing! Even for the time, it was nowhere near as powerful as any of the tools we have now. It seems like generations ago. It’s hard to believe it was only a little over a year ago. But we rolled it out across the company.

Now as I was managing my teams, I saw that they picked up Cursor and they liked it because it had like a very good way to do autocomplete on multiple lines. But people were still typing code. But a few of us in the company, mostly working on like smaller tools or utilities, we’re using this agent mode. And I was seeing this disconnect between the engineers on the teams over the months, the few months of us rolling out Cursor. Nobody was really using the agent mode to talk to it and actually write the code for them. But I was seeing other people in the company, like a few people like myself and a few others, we were able to get it to do a little bit more. But nothing big or grand that it wasn’t working very well in brownfield. It struggled a lot. It would run out of context really quick.

The disconnect from what I was seeing on YouTube, Henry, though, was these channels showing Cursor and these tools and these amazing claims. You can have no experience, you don’t even need to be a software developer, and overnight you can build your million dollar SaaS application. And I kept seeing these videos and they were impressive when you would watch them, but I’m like that seems like a little bit farfetched. I don’t know about that. But there was this wide disconnect and I kept seeing those videos. And then at the other end of the spectrum, I was seeing engineers in my company not really wanting anything to do with the agent mode. It just seemed like a fad or maybe you could use it to ask it a question like ChatGPT. But there was this chasm.

So I became obsessed. I’m like there has to be more to it. So as a leader of my team, I wanted to figure out is there something to this agent mode because Cursor’s making these claims. Sonnet 3.5 is supposed, at the time, was supposed to be this amazing new thing. But everybody was using it like autocomplete. So I started, before there was a term for vibe coding, I was basically vibe coding at night. I would watch Netflix and just vibe and it was fun. And Cursor at the time was very slow. You would hit this thing, they would call Slow Mode. I don’t know if everybody knows Slow Mode, but after you would use up your tokens. It would like make you wait for 15 minutes before it would start processing. So it was great for watching TV on the couch. Every once in a while you would look back and give it another command. But that’s when I started seeing the vibe coding curse, right? I had an idea for a pretty complex application at the time. And I gave myself the challenge, I’m gonna figure out how to get this agent to build this complicated application, multiple stacks, front-end, back-end, database. And get to do it without me typing any code. And I would do this over and over again, Henry. And I started to kind of realize like, oh, it gets this far and it starts breaking. Or it starts randomly doing a test, it fails, and it says, well, maybe if I just throw out the database and put in another one, it’ll work better. And if you’re not paying attention, it’ll do these crazy things. So I said, well, if I have this file that says we are using these libraries and frameworks and only use those, I started to notice that, oh, now I can get a little bit farther where it doesn’t start doing those still silly things. And then I started to realize like, oh, if I actually create a prompt file, I don’t have to keep repeating myself, and it gets a little bit farther. Oh, what if I take a PRD, and have it lean so it knows all the requirements upfront, and it gets a little bit farther. And it’s just, it kind of evolved out of this loop that I was doing. And I got to a point where I could actually build this pretty complex application.

It was exciting. And again, this is like a year and a half ago now with old Sonnet 3.5 in Cursor with this limited context window and it was doing this thing. And that’s another thing is with Cursor, you start to realize, wow, this thing starts hallucinating really quick. And this is not like a knock on Cursor right now, but this is just the state of things at the time. So you had to start coming up with your own ways of like, oh, if we have files and we break it down into smaller segments, it actually does better. So why don’t we call that a user story? And so thing kind of started forming where basically I’m taking what I’ve done for the last 15 years with Agile and thinking in this Agile fashion. I said it actually works really well to use that as a thought framework, as a model to kind of apply it. Here we’re doing the same thing. We’re talking about a problem, we’re doing a product inception. We’re breaking it down, we’re doing a solution design, and we’re coming up with stories. Again, context engineering, there wasn’t a name for it yet. Spec engineering, there wasn’t a name for it yet.

So I was so excited. I’m like, this is amazing. I can take this back to my team. It is gonna revolutionize everything. I brought it back and nothing changed. So that was the surprising thing. But I put it online and it did start to, you know, catch fire there with that first one. I just put it up there to be this thought framework. I never thought it would become anything it is like today, Henry. And it started resonating a lot with people online. Product managers started seeing this and saying, wow, this can actually help me produce better PRDs than I ever had before. Because as a professional product manager, it’s reminding me I forget these things and it’s actually helping ask me the questions of. So it’s funny because product managers started reaching out to me saying they were using it. And then people that have never written code before were starting to use it. And it’s like they’re learning like how Agile works and how industry works and people started learning from it. But I still wasn’t seeing it catch fire in my own organization which was the whole point.

So I did this technique, Henry. If I can go into maybe another little story, ‘cause I think this is useful for a lot of tech leaders right now because you might be seeing this in your own organizations. And since I’ve done this, I’ve actually talked to a lot of companies and helped transform my own organization and others. So there is a success story here at the end. But if you just give engineers this thing and say, hey guys, I figured it out. If you just do a PRD, and do this, and do this, it’s gonna give you this magic. It’s gonna work. Engineers, I think, have egos. We all have egos, and it’s like, no, I’ll figure it out myself. And they don’t really come to the same conclusions. And so they kind of will still feel like, yeah, the agent mode is good, but I’m still gonna go back to doing it this other way. I’m faster. What I did with every — and by the way, it’s not for lack of trying. Like I would tell people to try it. They would try the agent mode, especially in legacy projects where you have big code bases. It’s like, nah, it’s still not figuring it out. It’s getting it wrong. It’s messing up the code. I’ll just go in and fix it. And you kind of fall back because you’re under the demands of your current sprint. You know, your team probably wants you to get things done. And a lot of times you don’t feel like you have the space to really experiment. So you just kind of fall back on what you’re, what you need to do.

We had done AI sprints before in our company where the goal was let’s try to come up with an agent or let’s try to come up with some way to put AI or everybody come up with a creative use of AI. And those were pretty successful. And we did some hackathons and it led to some good ideas within our company, even, you know, for our products. But I said, what if instead of an AI hackathon where the goal is to come up with some new AI feature for the product, I had everybody do what I did for months in a two week sprint. So with my team, I took my team, Henry, and I said, we work in two week sprints. If people don’t know what a sprint is, it’s like a two-week block of work where the team commits to so much work at the beginning. I assume by now everybody knows by Agile, but just if people don’t, right, you commit to a group of work and by the end of the two weeks, the team really tries to push and get that two week work done. I said for this sprint, what we’re gonna do is everybody’s only gonna have one story. Each will be assigned a story. That’s not something we normally do in Agile. We want it to be more organic, but I said, in this case, everybody will have one story to do. This is a piece of work that would normally take you two to three days to do. But the only caveat is everybody has to use the agent mode. You cannot type any code. And if you get it done, I want you to do it over again and keep doing it and refining it.

This was the most transformative sprint, because first of all, it gave everybody the permission to not have to worry about getting the thing done and moving on to the next thing. And even in a normal sprint, if you tell your developers and your teams, don’t worry, like learn how to use these tools, take some time to do it, a lot of developers will still self internalize that, yeah, well I can take the time. I really still need to get the work done. And that takes the priority. So by taking the pressure off for two weeks, it gave everybody this permission to fail. The permission to fail, right? The permission to take a chance and see what happens. Henry, when I tell you this was the most transformative thing I’ve ever seen, like it’s not an understatement. People started coming to the same conclusions. And basically inventing spec-driven development.

You know, that’s why it’s funny because all these frameworks are coming out and it probably seems across the industry that people are always kind of coming up with the same ideas. Because if you actually go through this and do this, you start coming to your own conclusions. Oh, I don’t have to repeat myself to the agent every time. I can just put it in a file and give it that information, and I don’t have to explain to it, hey, I’m a X, Y, Z, and we’re doing this thing and we have to do this. You might not have the words for it, but you’ll come to all these same conclusions. Not only did people start figuring this out, but they started figuring out like, oh, we can save these prompts and it can help me do the same thing across all these code bases. And I can create an agent persona and they, it can help me do these things. Oh, I can give it a task list. So whether you call it a PRD or a story breakdown or a list of things to do, it’ll do better. And oh, it failed for this reason, but when I start over, if it has this rule or this thing, it will now get a little bit farther.

Not only did people figure out how to get their stories and use agent modes, it was transformative in ways I did not even expect. All of a sudden people started saying, why do we need to do error triage manually every morning and look at the logs? We can now create a prompt that does that for us and pulls this information. Or, oh, there’s this thing called MCP. Why don’t we put an MCP in front of this tool? Before that, for months I was trying to get people to like, let’s be creative guys and just think of these things. Whatever it was about this exercise, not only did people start thinking about how to work with agent mode, but they started looking at all these opportunities to start automating their job away and it became like wildfire. And this is even before like there was a skills explosion or before the tools were good as they are now.

So if I could give one piece of advice to every company, if you wanna transform your engineering team and get them to start using these tools, give them that space to do it. After that — this is no exaggeration — a few engineers went from never using the agent mode to using it 100% of the time, where they’ve taken it as their challenge to do everything with the agent mode. And this is not simple greenfield hobby projects. Like a lot of people think this only works with a greenfield or simple projects. This was people working in these legacy, you know, services that have existed for 5, 6, 7 years using the agent mode. Now since then, this has spread across the organization and it’s been transformative across product engineering and architecture and design. And, yeah, it’s just been magic. Like I can’t explain how useful that was.

So this all evolved from, you know, trying to do this myself, coming up with this thought framework, which was the BMad method, and then using it as a teaching tool to kind of have people do the same exercise, come to their own conclusions which funny enough were basically the same conclusions, right? Having a plan, giving it small bite-sized things, giving it context. Again, we didn’t have the name for it at the time but it became context engineering. So let me pause there, Henry, ‘cause that’s kind of a long story. But it’s just, it was an amazing experience and it’s transformed things.

Henry Suryawirawan: Yeah. Thanks for sharing such a beautiful story. I think I can see when you look back, right? So it’s kind of like the transformational impact that I think you must be proud of, right? But like which is also a reminder for, you know, leaders here, listeners here, right? So I think organizations that thrive is organization that learns a lot, right? And give the space for people, you know, to fail, experiment without kind of like the pressure of always delivering all the time, right? So I think that’s a actually a very good story.

[00:44:55] What Productivity Gains Has the BMad Method Produced?

Henry Suryawirawan: Speaking about, you know, this, the thing that you mentioned, you know, you can work with legacy code base, you can work, you know, or purely 100% agentic. What kind of impact, maybe if you can quantify a little bit to tease, you know, the listeners here to give it a try. Like what kind of impact have you seen? Is it like productivity impact, the number of people becomes lesser? Or what kind of impact do you see? Maybe not just from your team, but other users as well?

Brian Madison: Yeah, well let me tie it to the organization first and then I’ll talk about users of the BMad method. But in the organization since we did that, you know, that was probably six, six to eight months ago that we did it. Maybe six months ago, nine months ago. A lot has changed since then. The tooling has gotten better. Skills have exploded. We started to realize that this is not only great for the engineers, but can we help accelerate product? And you know, again, the BMad method I told you about, how like product managers reach out about how it can help them produce better PRDs. So, you know, training and realizing these tools, like now this is common sense, but 6-8 months ago we were realizing that these tools are actually really good for everybody. So helping share this information and teaching everybody to start working this way.

And you know what is now a pretty common term, but we started calling it like thinking AI native, it doesn’t mean like what is the next AI product we can build or bolt onto our product but how can we start using AI in all of our workflows? As a tech leader or a manager, you can use AI to help you look at data and create feedback loops to better understand where your team is operating. So, you know, you can use it for so much more than coding and engineering. So we started realizing all of these things and there’s been this huge acceleration. There’s been a lot of studies, you know, and I think the general consensus is you can see productivity gains from anywhere from, some people say 10-20%, some people say even more. As software engineers, we bring a lot more to the table and not everything is pounding out code. When you’re, you know, a senior engineer or a junior engineer or anywhere in there, your job is not to type code all day. And sometimes we lose sight of that. So AI will help you speed that aspect up. But it can also help you speed up the other aspects of the job. The other 60-70% of the time as an engineer, you’re having discussions, you’re thinking, you’re communicating, you’re having confidence in explaining ideas to different people in different ways. Those things don’t go away, and those things are still the very human aspect of what we bring to the table.

It’s funny, I just had this conversation a week or two ago because we are having such acceleration with AI in our organization and people are getting better and better using at it. Now everybody is using agent mode. Everybody is using skills. Everybody’s producing these amazing skills to do everything. You know, you can spit up a new dashboard to monitor something in a day now, what used to, you know, take months of planning and, you know, what tool are we gonna use. And some developers on my team have started to ask the question, well, it’s fun and it’s exciting, but I’m also starting to lose my, not lose my identity a little bit, but a lot of developers, their identity is tied to how good or how fast they can type the code. But what I really, you know, try to share with people, and I strongly believe this, and I think a lot of them are also kind of feeling this is, it’s just another abstraction, right? It’s like the switch from Assembly language to, I’ll just say to TypeScript, right?

[00:48:36] How Will AI Change the Unit of Work for Software Engineers?

Brian Madison: But this feels like almost that much of a gap. You’re able to step away a little bit. You’re almost becoming more of a leader of AI. You’re looking at it, you’re planning, you are thinking about a bigger picture. And I think it really frees you up to focus on more interesting challenges. You know, like how to do the for loop or how, you know, like what is the best way to structure this code. It’s still important, and as an experienced engineer it’s still important to keep those things in mind. But this also frees you up to think about it in a different way and plan. And as the unit of work changes for developers, ‘cause I will say this is something that will happen and is happening now. If the unit of work used to be the user story, I really believe very soon the unit of work is become, is gonna become the feature or the Epic. Different teams use different phrases, but what I mean by an epic is a collection of related user stories to build a whole feature.

We’re at a point now where a single developer can definitely finish a user story much faster. A user story that used to take a week, maybe it takes hours or a day now. And that is realistically true, that there is faster velocity. When the work is defined, the output is gonna be quicker. And as we develop better tools, it will get faster and faster. We can automate code reviews, we can, you know, I mean, that’s a whole other topic, but what I wanna say is now the developer can be responsible for a whole epic and maybe even deliver that epic themselves. So what I see is this transformation coming where now the developer can be more responsible, or almost everybody, you know, almost everybody can be a tech lead at this point in the sense that we call them epic champions or feature champions. And that’s a good way to develop all the people on your team, right? Regardless of their level, give them responsibility for an epic. But now by giving them responsibility for an epic, they can actually work closer with the product manager or whoever’s defining the epic. They should really be more involved in that conversation, understanding it, being able to explain it, and really implementing the whole thing almost themselves now.

So we are in a transitional period where this larger body of work will become the unit of work. But I think it’s exciting because it really moves you up the funnel. Instead of just being handed a single task where maybe you’re not really fully aware of how it fits into the whole bigger picture, we are being freed up as engineers now to actually be able to start focusing on that. I think that’s exciting. Because remember, our goal as engineers is not to, you know, create the most — I mean, sometimes optimization matters, right? But it’s not the elegant for loop that you wrote, right? It’s not gonna matter six months from now. It’s the features that you’re building to deliver value for the company that you work for. And so you actually now have the ability as an engineer to step back a little bit, orchestrate these things to do the work with you. Still treating it as a facilitator. Still, you know, keeping your own discernment and taste in the picture, and bringing your experience to the table to guide the AI, but you get to focus on this other stuff. So framing it that way, I think people are very excited and starting to see that, yeah, this is good. It does free me up to kind of look at these bigger picture things and feel like you’re actually having a bigger impact on the company. Because now you’re delivering whole features at a time that are delivering value, instead of delivering small pieces that might take three months to actually release to production and give value. So it’s an exciting time to be an engineer.

I wanna very briefly though, say also, for the BMad method itself, I have heard from many people that have never done software engineering, so go back to what I said was the scammy thing I’ve seen before. I really did also develop and keep evolving the BMad method with the community because people were giving their own feedback. They really do appreciate that if you’ve never built software before, if you’ve never been an engineer, we take for granted as engineers, one of our greatest skills is the ability to take a problem and decompose it into small things, which is why we’re gonna work with AI so well. That is not something people take for granted. And if you’ve been a tech, if you’re a tech lead or if you’ve been in tech tech even more than a year or two and you’ve been out of university for a while, you start to forget that. It just becomes just an innate skill you have. You know, you might even do it in the world. You’re thinking about how to cook and you’re thinking it in these small, granular steps, right? That is not a natural thing for most people. So that is really one of the engineering superpowers.

So when people that have never developed something and they first just try vibe coding, they’re not thinking about decomposing it into these smaller problems. And that’s where I think people really realize the magic of the BMad method is, oh, I’ve, when it’s working with you and you’re not a software engineer and it’s forcing you to think about breaking it down into these smaller pieces, and actually thinking about like, oh, I never thought I might need authentication. Or yeah, I guess I do need a UI to go in and administer these things. Or whatever, right? Like we take those for granted so much, but it’s helping so many people just get their ideas down on paper. Whether they build the actual final application or it still gets difficult for them at some point, it’s been magic and then it’s been helping people plan out their ideas in their applications in a thoughtful, methodical way. People have reached out to me that it’s helped them build pitch decks and, you know, launch applications that they’ve been able to get VC funding more, that they were having trouble explaining before. And just working with AI, it was never doing them for that.

So as engineers, remember that really is a superpower. The ability to break things down into these small tasks, and that is how, that really is the magic. And you know, that it really is the lesson that everybody learned even from this two weeks, you know, sprint that I did. Now that I, think about it, I just thought of this now, Henry, but it really did kind of remind them that just like humans, oh yeah, if we break this down into small, granular things and give it to the AI, it can even work well in the nastiest old code bases and still figure it out because we’re giving it this bite-sized bit of instruction that it can figure out and do so. Yeah, so that’s how it’s helped out both, you know, in the organization and also, you know, people from all walks of life kind of think methodically.

Henry Suryawirawan: Cool! So I really like the reminders that you mentioned just now, right? So when engineers now kind of like lose their identity, you know, because code is largely written by AI agents now. So I think you reminded something about, you know, moving up the abstraction layers and still using our problem decomposition skills to actually solve a problem and can become much more ambitious now, right? You’re talking about, you know, epic level instead of just user story or individual tasks. So I think those are great reminders for engineers to evolve yourself.

[00:55:51]

How Does BMad Keep Specs and Code in Sync Over Time?

Henry Suryawirawan: So speaking about, you know, evolve, evolution, right? Because one of the challenges working with AI is actually yeah, definitely, context engineering. Because if you have a complex system, you know, with large user stories, large number of features over the time with large number of developers, you know, changing the code, sometimes it can lose track and it can be out of sync from the spec and the code as well. So tell us, how do you actually solve this with your BMad method?

Brian Madison: With the BMad method itself, let’s just talk about a greenfield project for a second, just to keep it simple. And then I can talk about, you know, more of a legacy application. But for a brand new application, one of the places the BMad method does help is just the better planning upfront. Again, it will help you think of things that you might forget if you were just doing vibe coding or even if you just create a quick, simple spec. You might forget certain features and then you’re halfway through and it’s harder to have the AI put those in after the fact, if you can think of, you know, some of those things up front. But, you know, there’s a saying, best laid plans, right? It’s still, you’re still gonna forget things no matter how much planning. You still wanna be Agile with it and you’re still gonna have to change things.

The PRD, the architecture, and the specs that you’re gonna do, first of all, just like in the real world, I always look at those as a snapshot. In the real world, when you’ve been doing Agile or anything, you create a solution design. The solution design is a point-in-time document that I never that I remember keep around as actual documentation long-term. Even, you know, before AI, it’s gonna evolve, it’s gonna change. It’s meant to kind of convey a picture of what we’re gonna build. But the best documentation is the code itself. The code is a piece of documentation. And that’s the same with the AI.

But you asked how does the BMad help with that? We do have a few skills in the BMad method. One is correct course. So if you’re halfway through your build and let’s say you forgot something major like, oh, this relational database is not gonna work. I need to use NoSQL. I forgot a major feature, I did not consider authentication. That’s a major change that you’re going to use and I hope the BMad method will help you actually come to those conclusions before that. But you might wanna change it, right? We do have a correct course thing. The Scrum master will help you do correct course, and it will actually talk you through what is the impact of your change. Is it something that can just be worked in with some new stories and kind of change the flow? Or is it so drastic that you need to do a replan? And this actually comes from Agile ideas also, right? This happens in Agile. You might be halfway through a project and you have to pull the cord and do a, you know, a quick meeting and figure out, are we throwing this all out? Are we gonna pivot? It’s no different with AI. So what it will do is it will help you go through and update the documents as you need to and replan the stories. And hopefully, you know, you can just change the stories that are not done and work in your changes there. So that works actually for both greenfield and existing projects. So that’s one way that it helps.

But I will say the bigger thing is, the bigger way the BMad method helps, is it does really coach you and work through trying to figure out most of these things upfront. And that is the biggest difference between vibe coding and some of the leaner spec engineering kits. I mean, I think they’re all good. But some of them are not gonna really push you to think a lot of these things upfront. And sometimes that’s fine. So in BMad, there is a quick flow also because you don’t always need a PRD in an architecture up front. If you’re working in an existing project and you just want to add like a new feature onto an existing, you already have a REST API and you want to add a new route to it, you don’t need the whole B…, you know, you don’t use the whole BMad method. Instead you use the quick flow or you just make a quick spec, which basically amounts to just understanding the current state of the project. The AI will scan and understand your code base. It will understand your documentation, and if you don’t have documentation, you want to generate good documentation and context for the AI. And it will help you generate just the story or the spec that you need just for the one feature.

So brownfield in some ways believe it or not, is actually easier with AI when you start to understand these techniques. And we don’t really have enough time to go into a lot of those techniques. But again, it’s giving the AI the understanding of your code base, working in small increments. And then you can start doing magic things. Like even Claude agents can start doing these things now. You can, or you can give it… So, you know, Ralph loops are very popular or these things that can autonomously, you know, work for you. If you start using some of these techniques that will actually work for you. And it’s pretty amazing where the tooling is getting to help you with it.

[01:01:01] What Is the Best Way to Get Started with the BMad Workflow?

Henry Suryawirawan: Wow, cool! So many different tips and trick, I would say, and also embedded inside the BMad workflow. It sounds really useful. So maybe if, for people who are kind of like intrigued and want to give a try, is there any like, I don’t know, quick start, advice, or tips that you wanna give to the listeners here so that they can get up to speed with BMad method? Because sometimes when you use a framework, it can be, you know, super daunting, you know, there’s so many different things. But how do you do a quick start for BMad?

Brian Madison: Well, a couple things I wanna say is, first of all, if you’re an engineer, continue to be curious and just learn the tools themselves. I would say before even using BMad, if you haven’t used AI or agent mode yet, first, just start with, you know, Claude Code or, you know, Kimi or whatever tool you’re gonna use. Pick one and learn it well, and try to do the exercise I did and start to come to some of the understanding of how the context window works. Why it starts hallucinating. Why it makes sense to, you know, start new conversations and not keep the same one going. Because I have seen a lot of people will come into BMad, and without developing some of that foundational understanding of just how the LLMs work in general, it can still be a little bit of a challenge. So I wanna say any of these frameworks that you use, it is still important to learn the tool, keep up with what the tools are doing, and they’re evolving so fast. So learn to use a tool very well.

But then to get into using the BMad method specifically, you can go to the GitHub. There’s an installer, you install it. Once you install it, you can do BMad help, which is just a skills/bmad-help, and ask it questions and it will give you advice of how to use the BMad method. There is a website, docs.bmad-method.org. You can go there and there’s a quickstart on there and it will kind of guide you also through, first you do this skill, and then you do this skill, and then you do this skill, and it’s, and there’s a pretty simple workflow there. So that is how I would recommend using the BMad method.

But if somebody just wants to experience the magic of treating the AI as a facilitator, if nothing else, again, even if you don’t think you’re creative, follow the tutorial, install the BMad method for the tool of your choice. I would recommend Claude Code, but whatever you’re using. Just work through — a GLM is very good with it also ‘cause they’re both very creative models. Just do the brainstorming and see how interesting it is. And another thing I didn’t mention about the brainstorming is at the end of the brainstorming, it’s gonna do two or three different techniques with you. It’s gonna produce this report and a summary of the brainstorming you did. And it’s gonna also tell you the nuggets and insights and highlights that you actually came up with doing this brainstorming. Just try that. You’ll get a taste and a feeling for what it means to treat the AI as a facilitator instead of just a, you know, better Google. And that will I think unlock the rest of the BMad method with you.

One of the thing is we do have a Discord. It’s totally free, so I would invite everybody to come there. We have a community of 20-30,000 in there. Very popular, but very helpful people. There’s just a lot of people. Also in organizations there’s a lot of tech leaders and people that own companies in there, all trying to figure out how to apply AI in the workforce and how to use these tools. It’s a very welcoming community. So just come in there and ask questions. Also we’re very happy to help you, you know, just how to use the AI agents in general. We’re in there exploring, you know, what to do with these new models and what the new features are and all these new techniques. Because this is gonna change. What I’m saying today will not be the same six months from now. So there’s a lot of resources out there. So I welcome everybody to come in and try it and say hi. Reach out to me and say hello also, if you heard about this on Henry’s podcast here.

[01:05:00] Which AI Models and Tools Does the BMad Method Support?

Henry Suryawirawan: Yeah. So I’ll definitely make sure to put those things in the show notes. So you mentioned about a couple of models. So tell us like what models that these BMad tool support? Does it have to be BYOK, or you know, what kind of, you know, how do you run the agent with the AI model?

Brian Madison: Sure. Very good question. One thing I recommend to everybody is if you can afford it — well this is much more affordable regardless, is go with a subscription. Don’t bring your own API key. I will say some of the BMad method workflows right now, we are working on improving them and making them leaner, but they are context heavy. These are gonna use a lot of tokens because it is working back and forth with you doing all of this planning. It will read in documentation and other things. So I highly recommend getting a good subscription to Claude Code or Codex or, you know, Kimi, or any of these. The nice thing about the BMad method is we have built it to be model and tool agnostic. So when you use the installer for the BMad method, I think there’s 12 or 15 tools that we support in there now. Very soon we will be full skill compliant. So this will work with anything that basically supports skills. One of the goals with the BMad method is to actually get away from the IDE and also support tools like Claude Cowork or these platforms that allow non-technical. Very soon the skills explosion is gonna lead to, you know, web browsers and web tools will also support skills. So very soon this is gonna work across platforms. But find something, get a subscription, ‘cause you’re gonna be using a lot of tokens. And that is my advice. But it works across the models.

Some models are more creative than others. Some models will produce better code than others. So if you use a tool like Cursor or something that allows you to use different models, you’ll start to learn over time that the brainstorming is better with Claude or GLM. Code review, we have code review things in there that help improve the code. Those might be better with Codex or, you know, the ChatGPT model or these other things. But you don’t have to worry about all those details at first. At first, just pick a tool, pick a model, and start learning that one really well. And you’ll start to learn maybe where some models work better than the other ones but you can learn to work with the model that you have also and make it work for you. So those are just some of the skills that you have to kind of develop a feel for over time. But you start to pick it up, it’s kind of like riding a bike. You just start to kind of get a feel for it, and you’ll start working together with it really well.

Henry Suryawirawan: Yeah. Always happy to whenever the tool is agnostic, you know, especially all these AI models that you can just pick and choose, right? So definitely, it’s a advantage, I would say. We have covered a lot. As we go to the end of our conversation, is there something else that you wanna mention or shout out about BMad, maybe something that we haven’t covered today?

Brian Madison: You know, I think we covered a lot of it, Henry. Again, I just suggest everybody go out there and just try it out. Have fun with it. And if you take nothing else away from this, I’ll say again, just treat the AI like a facilitator. And it’s honestly a magical experience when you try it the first time, if you haven’t really worked with AI before. So that is kind of like my one message.

[01:08:21] 4 Tech Lead Wisdom

Henry Suryawirawan: Right. So Brian, as a tradition in my podcast, I always ask this last question which I call the three technical leadership wisdom. If you can think of it just like advice you wanna give to the listeners, maybe if you can share your version today that would be great.

Brian Madison: Yeah. I really love this question. I’ve listened to a few of your episodes, Henry, and I have become a fan, and I like that you asked this for everybody. I want to take this from the perspective of sharing information for, with new tech leads. Or people that are leaders or people that might be thinking about leaders, because we can all be leaders, especially now with AI, right?

So, you know, the first one that I’ve seen leaders really struggle with, especially when they’re a new leader is delegation. So I just want you to remember that you as a tech lead or an engineering manager or any kind of leader, your goal is really to start becoming a force multiplier for your team. And the best way you can do that is to delegate. And at first you’re gonna feel like, oh, I’m just pawning my work off to people or this doesn’t feel right. But the more that you can learn to do that, A) the more you can really focus and shepherding and helping your team, but also you’re going to give people on your team the opportunity to go, to grow, and be responsible for things. And you’ll be able to take on more and more leadership because you’re starting to learn to trust people and delegate. And even, you know, get away from knowing all of the details and relying on other people. It’s really, delegation is a superpower and it’s not like cheating, but I see people struggle with that. So delegation, you know, is really a force multiplier.

The second one, and I already talked about this so I’ll be really brief on this, but giving your team permission to experiment and fail. And I already talked about the AI sprint. But what that really means is sometimes you really gotta give them the space to experiment and know that it’s okay if they come out with the wrong thing. Or, you know, pull back the pressures from the sprint for somebody to let them do a little bit of an experiment to come to these conclusions. And you will see a flourishing of new ideas and new ways of thinking if people really feel — I think the term is psychological complexity or is that psychological safety, excuse me, right? But part of psychological safety — and complexity — is the ability to feel comfortable in failing. People forget that, and sometimes just think it means, you know, feeling comfortable talking, but it is also permission to fail or permission to experiment.

The third one, and this is a new one that I’ve come up with and it’s really recent, but with this AI and transformation, remember that a lot of people are scared right now or just don’t know what the future holds. I don’t know if scared is the right word, but some people are scared, some people are uncertain. None of us have the answer of what is coming. As a leader — and I said this at the beginning, I really picked this up from my army training — sometimes it is putting a good face on things because not only can your team recognize confidence, but they can also recognize fear, and that will have an impact on how they operate. So sometimes you do have to put a good face on things to lead people through adversity. And I’m not saying AI and this transformation is adversity. But helping people learn to grow through this new transition and recognize their own self-worth. And people are gonna embrace these tools and then they’re gonna have these moments of, wait, what is my purpose now?

If you can shepherd them through these times, that will make you a great leader. But that also really shows that you care about people. As a leader, you need to care about people. And part of caring is just helping lead through adversity or challenging times, or helping people realize what their self-worth is. And I think we’ve shared a little bit of that throughout the podcast of what your self-worth is, as these AI tools comes, it is stepping back and applying your experience and your discernment and knowing that you can work with the AI as a partner, but you’re giving it something that the AI, I don’t think has or ever will has, which is your lived experience and knowledge and discernment. So helping your team do that is really part of being a leader.

I have one more, Henry, though. I know you said three but I wanna give one more. And this is a cliche old one that I’ve always heard, but it applies now more than ever. Leaders are readers and I really strongly believe that. If you’re new to tech leadership, it’s fun to focus on, you know, still learning engineering patterns. There is a lot of fun in learning about leadership and about management and organization. Maybe this sounds boring. You had one of my favorite people on your podcast a few weeks ago, Gene Kim. I am a jump. I love Gene Kim’s books, I’ve read all of them. And I love business books and management books that kind of have a story in ’em. So I’m a sucker for those types of books. But learn these techniques and you’ll start to realize it’s just like engineering. You’re starting to learn ways of working with people or how to apply these different things. And you might start to really enjoy the leadership and management side of things and it will just help you grow. So read about techniques and focus not only on the technical, but how to become a better leader. And you will, you’ll become a better leader. It’s a lot of fun. So, sorry I had to squeeze one more in there. But, you know, leaders are readers and I believe that.

Henry Suryawirawan: Happy for more wisdom from my guest to share. So thank you for sharing such a lovely message. I think all those are really critical, you know, skills for leaders. You know, being able to delegate, creating psychological safety, right? Caring about people going through, you know, difficult periods, you know, adversity and things like that. And definitely, inviting people to read more. So BMad, if people want to connect with you, asking you more questions maybe about BMad maybe about other things, is there a place where they can find you online?

Brian Madison: Yeah, the best thing, honestly, it’s easy. I mean I have a lot of email addresses, but check me out on YouTube. I do have a masterclass on there where you can also watch and learn about the BMad method and my contact information is on YouTube. But the easiest is come into Discord. So if you go to our GitHub for the BMad method, there is a Discord link. You can join our community. It’s free. Come in there and say hello, ask questions. Myself and the community will be happy to help you out and tell you more about BMad or you know, how to apply engineering and these changes across your own organization. Happy to help.

Henry Suryawirawan: Right. It’s been a pleasant conversation. Thank you so much for sharing all those things. I really love your story as well, the background, how you came up with this BMad method. I wish you good luck and great success with this evolution of the BMad.

Brian Madison: Thank you Henry. This was so much fun. I really enjoyed talking to you and I love your show. So, thank you so much. This was awesome.

– End –