# Spec-Driven AI Development and the BMAD Method

**Podcast:** Tech Lead Journal
**Published:** 2026-04-20

## Transcript

I don't consider BMAD vibe coding.
I think of it as the antithesis of vibe coding because you're actually putting some thought in working with a plan.
Today's guest is Brian Madison, creator of the BMAD Method, a spec-driven AI development framework that transformed his team from skeptics to 100% agentic developers, now used by a community of 30,000 engineers worldwide.
What I really started to notice early on with AI is that it can be an amazing facilitator.
It's almost like paired programming.
If you can explain, what is BMAD Method?
The BMAD Method right now has multiple workflows.
You work with a product manager to produce.
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.
When the work is defined, the output is going to be quicker.
As we develop that tools it will get faster and faster if the unit of work used to be the user story i really believe very soon the unit of work has become the feature or the epic engineers now kind of like lose their identity because code is largely written by ai agents now a lot of developers their identity is tied to how good or how fast they can type the code it's just another abstraction right it's you're almost becoming more of a leader of ai one of our greatest skills is the ability to take a problem and decompose it into small things that is not a natural thing for most people which is why we're going to work with ai so well Hey, quick pause.
My goal with Techly Journal is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe to follow the channel.
It's the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here and let's get back to it.
Hello, guys.
Welcome back to another new episode of the Techly Journal podcast.
Today, I'm very excited to meet someone who is the creator of the BMAD method, B-M-A-D.
I haven't heard about BMED 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.
Thank you, Henry.
I'm so excited to be here, and that's so cool that somebody in your community let you know about the BMED.
So I'm happy to be here and talk about it with you.
It's very exciting.
Yeah.
So maybe before we go into the BMAT, 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 U.S.
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 the knowledge from U.S.
Army to software engineering?
Yeah, sure, Henry.
Yeah, that's a great question.
I started out actually in electronics.
engineering so I've pretty much been an engineer 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 going to 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.
I don't know if maybe I always had it, but I really developed that.
In the Army, though, you really do 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 have to show self-confidence, and you don't always have that.
For the benefit of the people following you, and this really applies even in the workplace 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.
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 and delegate and i think um 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 or 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 have never been exposed to.
I got to travel the world and get outside of the bubble of America.
A lot of people that grow 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 um i really strongly believe in good diverse teams with interesting perspectives and i don't i mean maybe i would have 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 you know shaped my career and then when i got out of the military it was an easy transition into I'm 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 shaped where I am now.
So it's been a long time, Henry.
It's been 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.
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 in a big team setup or maybe talking to executives.
Some engineers really did have challenges, especially 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 a more self-confident, how would you advise people to kind of like be more self-confident?
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 got to 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 going to have that voice of self-doubt or many people will.
you just got to remember that not everybody sees that.
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 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 so they can appreciate it um so i think i think just um 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 Yeah, speaking about imposter syndrome, definitely I also feel it.
Even though how many years of experience you have worked, especially these days, especially all these technologies seems to advance rapidly, you won't know everything, right?
So definitely always there's an imposter syndrome, especially people who work in tech.
And yeah, being confident is something that can be trained.
So I think for everyone who will listen, if you're not confident, you can train that maybe in a smaller scale.
I really believe that too, Henry.
And I think that is a good reminder for people.
And I still tell that 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 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 it's a 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 so yeah So let's go into the BMED thing, right?
So first of all, I would like to clarify, what does BMED stand for?
Because I see a couple of different definitions, but I also kind of like see your name, Brian Madison.
Is this like Brian Madison as BMED?
So tell us what does it stand for, actually.
It really started out as just people, first of all, Henry, if you like, you can't call me BMED.
People actually call me BMED in my day-to-day life.
It's 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 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...
be mad 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 for the last 15 plus years out of my 25 plus 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 that'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 have been building as a community has evolved, I now just call it...
build more in architect dreams because we'll talk a little bit about what the B-Man 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?
So, yes.
So, I don't know.
It's a funny story, I think.
But, yes, the BMED method means multiple things.
But it really is about taking a way of structuring agile, you know, a way to think about working in an agile method with AI to do context engineering at the end of the day.
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 let's just call it whatever that is named in the GitHub, which is like build more architect dreams, right?
Or maybe simply your name as the creator.
You know what's funny, Henry, is a lot of people will like use AI just to create like an article about Bmed.
Maybe they want to 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's just whatever it spits out.
So it's actually pretty fun because sometimes I'll see those and I'm like, dang, I should have used that one.
I actually like that one better.
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.
Yeah, let me 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.
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 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 B-Man 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 are 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 going to 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 similar stuff out there now.
But I didn't want to 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 it's funny but the bmed method has been going about a year now um almost a year a lot of people treat the ai like a like a chat cpt or you know even the agent mode ask it a question give it an answer i have this function how would you refactor it um what libraries should i use to do xyz 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 BMED 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 going to 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 paired programming.
So you might not be an expert product person because you're an engineer, but working through the PRD, it's going to ask you things that you might not normally think of, like do you need to 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 up front, the less you'll be having to change when you're actually building your application.
So that is really why you want to go through this whole funnel.
But there's other features also of the BMED 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 want to do, this will do brainstorming with you.
acting as a facilitator.
And people might have done this.
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 BMED method has evolved.
I know this is a very long answer of what is the BMED 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 I was a creative person.
When you treat the AI as a facilitator.
And it is not doing the brainstorming for you.
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 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 B-Man 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 because I know that's a lot.
Yeah.
Speaking about creativity, I think that kind of like...
It just reminds me that to be creative, it comes back to the questions that you ask.
If you naturally don't think in questions, sometimes you can get stuck.
But if you're always curious, asking different questions, different ways, different perspectives, I think you can be creative.
And that's the cool thing about the brainstorming method also.
If anybody wants to try out the B-Man method, if you try nothing out, just try out the B-Man method brainstorming.
It's different than everything I've seen out there.
50 different techniques built into it depending on what you're working on you'll tell it what you want to do and it'll suggest some of the techniques but there's some crazy ones in there there's like uh 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 um just uh there's uh idea gardening there's um 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.
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, and I even use it for things outside of software engineering.
It's a lot of fun.
So maybe since I'm not like a very advanced BMAT user, in fact, I have never used it in my project before.
So if I can understand it further, first is 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 like 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 this 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.
Yeah, exactly.
Yeah.
And then the third thing that I can associate BMED 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?
Yeah.
Yeah, Henry, that's a great question.
You know, when I kind of got to go back to when I started BMED, 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 BMed vibe coding.
I think of it as the antithesis of vibe coding because you're actually putting some thought and planning up front and working with a plan.
Context engineering was something I didn't have a name for it.
It's funny.
I must be.
Like many engineers, 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 long with acceptance criteria in it.
So a very good user story.
It's not just, you know, as an X, I want to 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, and the models were nowhere near what they are now.
So that was context engineering.
are really producing our specs so they call it spec engineering now and that really is what BMAT 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 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 BMAT, 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 going to need before you produce all of your specs and have it start working.
So you're not hopefully changing as much halfway through or forgetting major features or, oh, I forgot I need a database or I need authentication.
um so it will guide you and help you through that now you asked about the agents henry when i first when i first made the bmed method and maybe we can talk a little bit about why i even made it but um it started out as just six files so i 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, all of the prompting guidance was give it a persona, 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're getting this information out of the user.
It grew over time to be multiple files and 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 and the BMED 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 BMED method is it is part of a platform now.
So there is something called the BMED Builder.
It's going through some rework.
It will be released 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 B-Man method, because it can be overwhelming at first, you can just ask the help and describe to it what you want to do.
And it will suggest, oh, you don't really know what your idea is yet.
You might want to 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 bman method has also grown to be a lot of different modules the community can also contribute modules and it 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 Yeah, sounds like...
I know that was a very long question, a very long answer.
Yeah, sounds like it has grown since you started it like a year ago or so, right?
So it has grown into like all these framework modules, plugins.
And I'm quite curious when you mentioned just now, right?
Why, like the story, why you actually started BMath Method?
Maybe if you can share with me, how did it start in the first place?
Like what kind of problems you see?
Yeah, that's a good question.
Thanks for asking that.
I think it helps explain where it is also now.
Henry, a little over a year ago, I work at a company called Xtend.
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 the product engineering org.
And we were using Copilot.
And if you remember, you know, Copilot like two years ago.
It was basically a very good autocomplete, right?
At the time, it seemed like magic.
But a little over a year ago, Cursor started getting very big.
I assume you're familiar with a lot of these tools, Henry.
Yeah, so Cursor came out.
I was working in this organization, and we were looking at other tools to replace Copilot.
People loved Copilot.
We'd been using it about a year.
And it was great for autocomplete.
You could show it a function, and it would help you rework the function.
And it did seem like magic at the time.
When ChatGPT really started getting big, though, when that 3.1 came out, and 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 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 smaller tools or utilities, were using this agent mode.
And I was seeing this disconnect between the engineers on the teams over 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, and 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 sas 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 far-fetched 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.
um 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 i would watch netflix and just just vibe and it was it was fun and cursor at the time was very slow you'd hit this thing they would call slow mode i don't know if everybody knows slow mode but after you 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 going to figure out how to get this agent to build this complicated application, multiple stacks, front-end, back-end database.
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 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 up front?
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 and 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 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 this this this 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 or 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's going to 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 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.
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 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.
I did this technique, Henry, if I can go into maybe another little story, because 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.
Do a PRD and do this and do this.
It's going to give you this magic.
It's going to 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 going to 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.
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 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 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 going to do is everybody is only going to 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.
Even in a normal sprint, if you tell your developers and your teams, don't worry.
Learn how to use these tools.
Take some time to do it.
A lot of developers will still self-internalize that, yeah, while I can take the time, I really still need to get the work done.
And that takes a 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.
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 XYZ, and we're doing this thing, and we have to do this.
And 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 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.
We're good as they are now.
So if I could give one piece of advice to every company, if you want to 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 five six seven 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 trying to do this myself, coming up with this thought framework, which was the BMED 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.
Let me pause there, Henry, because that's kind of a long story.
But it was an amazing experience.
And it's transformed things.
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?
Which is also a reminder for leaders here, listeners here, right?
So I think organizations that thrive is organizations 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 speaking about you know this yeah 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 the listeners here to give it a try, what kind of impact have you seen?
Is it productivity impact, the number of people becomes lesser, or what kind of impact that you see, maybe not just from your team, but other users as well?
Yeah, well, let me tie it to the organization first, and then I'll talk about users of the BeMed method.
But in the organization, since we did that, that was probably six.
six to eight months ago that we did, 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 again, the B-man method, I told you about how product managers reach out about how it can help them produce better PRDs.
So training...
and realizing these tools like now this is common sense but six eight 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 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.
And I think the general consensus is you can see productivity gains from anywhere from some people say 10% to 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 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 the 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% to 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 at using it.
Now everybody is using agent mode.
Everybody is using skills.
Everybody's producing these amazing skills to do everything.
You can spit up a new dashboard to monitor something in a day now.
What used to take months of planning and what tool are we going to 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 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?
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're thinking about a bigger picture and i think it really frees you up to 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, because 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 going to 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 that is realistically true that there is faster velocity when the work is defined the output is going to 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 want to 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...
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, 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 is 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're 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 create the most, I mean, sometimes optimization matters, right?
But it's not the elegant forward loop that you wrote, right?
It's not going to 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 want to very briefly, though, say also for the BMED 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 BMED method with the community because people were giving their 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 going to work with AI so well.
That is not something people take for granted.
And if you're a tech lead or if you've been in 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 this innate skill you have.
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 B-Med.
method is oh i've when it's working with you and you're not a software engineer and it's 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 oh 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 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 in that it's been helping people plan out their ideas and their applications in a thoughtful, methodical way.
People have reached out to me that it's helped them build pitch decks and launch applications that they've been able to get VC funding more, that they were having trouble explaining before.
And just working with AI 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.
That really is the magic, and that really is the lesson that everybody learned even from this two-week 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.
Yeah, so that's how it's helped out both in the organization and also people from all walks of life kind of think methodically.
Cool.
So I really like the reminders that you mentioned just now, right?
when engineers now kind of lose their identity because code is largely written by AI agents now.
So I think you reminded something about 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 epic level instead of just user story or individual tasks.
So I think those are great reminders for engineers to evolve yourself.
So speaking about evolution, right?
Because one of the challenges working with AI is actually, yeah, definitely context engineering.
Because if you have a complex system with large user stories, large number of features over the time, with large number of developers 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 BMAT method?
With the BMAT method itself, So let's just talk about a Greenfield project for a second just to keep it simple, and then I can talk about more of a legacy application.
But for a brand-new application, one of the places the BMED method does help is just the better planning up front.
Again, it will help you think of things that you might forget.
If you were just doing vibe coding or even if you just created 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.
some of those things up front.
But there's the saying, best laid plans, right?
You're still going to forget things no matter how much planning.
You still want to be agile with it, and you're still going to have to change things.
The PRD, the architecture, and the specs that you're going to 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 going to evolve.
It's going to change.
It's meant to kind of convey a picture of what we're going to 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 BBET help with that?
We do have a few skills in the BMED 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 going to work.
I need to use NoSQL.
Or 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 BMED method will help you actually come to those conclusions before that.
But you might want to 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 going to 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 re-plan the stories and hopefully you know you can just change the stories that are not done and work work work in your changes there so that 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 BMED method helps is it does really coach you and work through trying to figure out most of these things up front.
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 going to really push you to think a lot of these things up front.
And sometimes that's fine.
So in BMED, 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 you don't need the whole b you know you don't use the whole bmet 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.
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 cloud agents can start doing these things now.
Or you can give it to, you know, RELF loops are very popular or these things that can autonomously 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 that.
Wow, cool.
So many different tips and tricks, I would say, and also embedded inside the BMAT workflow.
It sounds really useful.
So maybe for people who are kind of intrigued and want to give a try, is there any, I don't know, quick start advice or tips that you want to give to the listeners here so that they can get up to speed with BMAT method?
Because sometimes when you use a framework, it can be super daunting.
There are so many different things.
But how do you do a quick start for BMAT?
Well, a couple things I want to 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 BMED, if you haven't used AI or agent mode yet, first just start with Claude Code or Kimmy or whatever tool you're going to 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 start new conversations and not keep the same one going.
Because I have seen a lot of people will come into BMED, 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 want to 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 BMED method specifically, you can go to the GitHub.
There's an installer.
You install it.
Once you install it, you can do BMED help, which is just a skill, slash BMED help, and ask you questions, and it will give you advice of how to use the BMED method.
There is a website, docs.bmed-method.org.
You can go there, and there's a quick start on there, and it will kind of guide you also.
First you do this skill, and then you do this skill, and then you do this skill.
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 because 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 going to do two or three different techniques with you.
It's going to produce this report and a summary of the brainstorming you did.
And it's going to 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 better Google.
And that will, I think, unlock the rest of the BeMad method with you.
One other 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,000 to 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 just how to use the AI agents in general.
We're in there exploring what to do with these new models and what the new features are and all these new techniques because this is going to change.
What I'm saying today will not be the same six months from now.
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.
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 BMAT tools support?
Does it have to be BYOK or what kind of a, how do you run the agent with the AI model?
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 Bmed method workflows right now, we are working on improving them and making them leaner, but they are context heavy.
These are going to 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.
I highly recommend getting a good subscription to CloudCode or Codex or Kimi or any of these.
The nice thing about the Bmed method is we have built it to be model and tool agnostic.
So when you use the installer for the Bmed method, I think there's 12 or 15 tools that we support in there now.
Very soon, we will be full skill compliance.
So this will work.
with anything that basically supports skills.
One of the goals with the BMED method is to actually get away from the IDE and also support tools like Cloud Cowork or these platforms that allow non-technical.
Very soon, the skills explosion is going to lead to, you know, web browsers and web tools will also support skills.
So very soon, this is going to work across platforms.
But find something, get a subscription because you're going to be using a lot of tokens.
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 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.
Yeah.
Always happy whenever the tool is agnostic, especially all these AI models that you can just pick and choose, right?
So definitely it's an advantage, I would say.
We have covered a lot as we go to the end of our conversation.
Is there something else that you want to mention or shout out about BMAT?
Maybe something that we haven't covered today.
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.
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 want to give to the listeners, maybe if you can share your version today, that would be great.
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 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 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 going to feel like, oh, I'm just pointing my work off from people or this doesn't feel right.
But the more that you can learn to do that, A, the more you can really focus on shepherding and helping your team.
But also, you're going to give people on your team the opportunity to goal, 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 get away from knowing all of the details and relying on other people.
Delegation is a superpower and it's not like cheating, but I see people struggle with that.
So delegation 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...
the permission to experiment and fail.
And I already talked about the AI sprint, but what that really means is sometimes you really got to give them the space to experiment and know that it's okay if they come out with the wrong thing or 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 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 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 in this transformation is adversity, but helping people learn to grow through this new transition and recognize their own self-worth.
And people are going to embrace these tools, and then they're going to 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 want to 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 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 them.
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 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.
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 skills for leaders, being able to delegate, creating psychological safety, caring about people going through difficult periods, adversity and things like that, and definitely inviting people to read more.
So BMAT, if people want to connect with you, asking you more questions, maybe about BMAT, maybe about other things, is there a place where they can find you online?
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 master class on there where you can also watch and learn about the BMED method, and my contact information is on YouTube.
But the easiest is come into Discord.
So if you go to our GitHub for the BMED 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 BMED or how to...
how to apply engineering in these changes across your own organization.
Happy, happy to help.
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 BMED method.
I wish you good luck and great success with this evolution of the BMED.
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.