Stop Vibe Coding: Spec-Driven Development With the BMad Method  🔗 **Source:** [Stop Vibe Coding: Spec-Driven Development With the BMad Method](https://share.snipd.com/episode/3dc94cb0-032e-471c-998c-4f6b1e07cc8f) ## Highlights - **Why Vibe Coding Hits A Wall** - Vibe coding fails because agents hit context and decision walls without upfront structure. - Brian Madison frames a funnel: brainstorming → PRD → architecture → UX → context-rich user stories so agents get exact, limited context to act on. Transcript: Brian Madison If you can explain, what is BMAD Method? The BMAD Method right now has multiple workflows. You work with a product manager to produce a PRD. You work with an architect to produce your architecture or solution design. Each of these artifacts eventually produce what are user stories and ethics to break your work down. Henry Suryawirawan Product managers started seeing this and saying, wow, this can actually help me produce better PRDs than I ever had before. What kind of impact that you see? Is it like productivity impact? The number of people becomes lesser? Brian Madison 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 better tools, it'll 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. ([Time 0:00:23](https://share.snipd.com/snip/add6085d-2742-4371-81ba-14c9c07e232f)) - **Army Leadership Shaped His Tech Leadership** - Brian traces leadership and discipline back to his U.S. Army experience that taught him delegation and trust. - Army NATO assignments exposed him to diverse teams, shaping his belief in diverse perspectives for engineering teams. Transcript: Henry Suryawirawan 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? 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 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 I – 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, it really plays in my career right now. When you're leading, you know, you have to show self-confidence, and you don't always have that for the benefit of the people following you. ([Time 0:02:56](https://share.snipd.com/snip/2e716d34-907b-4948-8551-875201a5cfaf)) - **Use AI As A Facilitator Not A Coder** - Treat AI as a facilitator and engage in multi-turn, guided conversations to elicit missing product details. - Use agent personas to ask product and flow questions so the PRD surface hidden requirements before coding. Transcript: Brian Madison If you go to – you can look at my YouTube channel. There's a master class 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 and 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 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 Bmed method has been going about a year now, almost a year. A lot of people treat the AI like a chat CPT or even the agent mode, ask it a question, give it an answer. I have this function. How would you refactor it? 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, you know, 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. ([Time 0:14:10](https://share.snipd.com/snip/90c2a353-4e79-4547-aa2a-611c78aa2a3f)) - **How A Year Of Late Night Experiments Sparked BMad** - Brian experimented for months doing 'no-typing' agent-driven builds and found context files dramatically reduced hallucinations. - He evolved prompt files into PRDs and story specs that let agents complete complex apps on older models. Transcript: Brian Madison Yeah, that's a good question. Thanks for asking that because I think it helps explain 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 smallish company. And I started out as a staff engineer. And now I manage teams across the product engineering org. And we were using Copilot. And if you remember 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, 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 chat GPT like really started getting big though like when that 3.1 came out and we started seeing engineers using chat GPT instead of Stack Overflow right and and it was getting Good at answering questions and then 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. 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 were 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, 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 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 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 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 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 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 SignUp 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 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 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. ([Time 0:29:24](https://share.snipd.com/snip/e489629b-b6ff-42ef-b713-03a6a7d40999)) - **The Two Week No Typing Sprint Transformed The Team** - Brian ran a two-week sprint where each engineer had one story and was forbidden from typing code, which accelerated agent adoption. - The sprint gave psychological permission to fail and led engineers to invent spec-driven workflows themselves. Transcript: Brian Madison 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. 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't take the time. I really still need to get the work done. And that takes a priority. So by, 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 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 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 want to transform your engineering team and get them to start using these tools, give them that space to do it. 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. ([Time 0:39:09](https://share.snipd.com/snip/3c694ec1-118b-4b69-b4e7-c93d9e7d27bf)) - **Make Epics The New Unit Of Work** - Reframe the unit of work from user stories to features/epics so engineers can own larger outcomes. - Let engineers act as epic or feature champions working across product, design, and architecture with AI assistance. Transcript: Brian Madison 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, you know, that was probably 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, you know, again, the B-Man 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 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 what is now a pretty common term, but we started calling it thinking AI native. It doesn't mean 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 to help you um 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 um 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% 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 to 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 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 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 realistically true, that there is faster velocity. When the work is defined, the output is going to be quicker. ([Time 0:45:19](https://share.snipd.com/snip/2ac4e0e6-3e0e-462c-9b9f-26ec7f4b95e1)) - **Problem Decomposition Is An Engineering Superpower** - Non-developers benefit because BMAD forces problem decomposition they usually miss, making software planning accessible. - Engineers' decomposition skill is an AI superpower that amplifies agent effectiveness in legacy code bases. Transcript: Brian Madison 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 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 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 BMED method is, oh, 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, 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 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 and 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 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. ([Time 0:52:38](https://share.snipd.com/snip/3bd129b4-1f16-4af3-bac1-a8a592310986)) - **Use Correct Course And Treat Docs As Snapshots** - When specs and code diverge, use correct-course skills to assess impact and replan stories rather than blindly refactoring. - Keep solution docs as snapshots and rely on code plus updated stories as living documentation. Transcript: Brian Madison 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 B-MED 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 if you can think of you know some of those things up front but you know there's the saying best laid plans right it's still 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 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 document that I never, that I remember, keep around as actual documentation long term. Even 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 BMED 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 B-Med 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 this happens in agile you might be halfway through our 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 replan the stories. And hopefully, 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. ([Time 0:56:20](https://share.snipd.com/snip/cefe8795-55c5-4283-b3d3-b531e783f69e)) - **Start Small And Learn One Model First** - Quick start by mastering one agent/model and learn token/context limits before adopting BMAD. - Then install BMAD, try the brainstorming skill first, and join the BMAD Discord for community help. Transcript: Brian Madison Well, a couple of 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 it questions. And it will give you advice of how to use the BMED method. There is a website, docs.bmed You can go there, and there's a quick start 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 there's a pretty simple workflow there. So that is how I would recommend using the B-MED 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. 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, a better Google. And that will, I think, unlock the rest of the BeMad method with you. ([Time 1:01:30](https://share.snipd.com/snip/ff1c4baf-c7f7-41b3-8c0e-0d1ec27bf2f7)) - **Leadership Rules For AI Transitions** - Delegate to become a force multiplier, give teams permission to experiment, and lead with confident support through transitions. - Read widely about leadership and management to grow beyond technical skills and better shepherd teams through AI change. Transcript: Brian Madison 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, you know, the first one that I've seen leaders really struggle with, especially when they're a new leader, is delegation. 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 in shepherding and helping your team. But also you're going to give people on your team the opportunity 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 complexity or 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 and 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. And maybe this sounds boring. You had one of my favorite people on your podcast a few weeks ago, Gene Kim. I am a junkie. 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 leaders are readers, and I believe that. ([Time 1:08:36](https://share.snipd.com/snip/c8affd1e-8b31-451a-aa45-fe919d3c198b))