# Brian Seitel's Blog > Thoughts on engineering leadership, software architecture, AI-native development, and building high-performing teams. By Brian Seitel — https://brianseitel.com --- # On Being a Servant Leader - Author: Brian Seitel - Published: 2026-08-11 - Tags: leadership, management, philosophy - URL: https://blog.brianseitel.com/on-being-a-servant-leader/ > I win if you win. # First, the Philosophy My job, as I see it, is to support my team. What the company pays me for is output, but my personal view is that by supporting my team, I increase autonomy, ownership, and pride in the work, and that leads directly to better output. Further, I think it's really important as a human being, as someone who deeply cares about the people around me, that I support my team even after we no longer work together. I have quarterly calls with a dozen of my former employees -- people I now consider friends and colleagues. That's a network that I can rely upon for anything. When I run into a tech problem, I can ping Jake and ask him for advice. When I have a team struggling with the latest Python frameworks, I can call James. When I need management advice or mentorship, I'll call Bryce. When I need someone to hold me in check and tell me I'm full of shit, I'll text Patrick. # The Compliment About a year ago as I left a job, I was doing my final one-on-ones with my team. I explained, briefly, my reasons for leaving the company, what my plans were for the future, and offered to sit and talk about anything my team wanted to do. This was really important to me. Most of them expressed sadness. "I'm sorry you're leaving," they'd say. "I really learned a lot and enjoyed working with you." For others, it was just another Tuesday. But for some, it was an emotional moment. One of the managers that reported to me sat with the information for a minute, then he said, softly, "I've worked for a lot of companies, and a lot of managers. I've never worked for one who made me feel supported, and who made me feel like I was a human and not a resource." Honestly? That's the most incredible thing anyone has ever said to me. # The Lesson I thanked him for that, obviously, but I also took it as a teaching moment. I told him it was my pleasure and my honor to work with him. I told him how I believe very strongly that when he is successful, I'm successful. To put it more starkly: if he fails, I fail. And so why wouldn't I do everything in my power to make him successful? That makes perfect sense to me. And so I did. I gave him opportunities to lead. I let him drive architectural decisions with my input primarily as a set of guardrails. We talked as peers and equals, even though the corporate ladder says I'm his boss and he's my employee. But here's the thing that a lot of power-intoxicated leaders miss: I can't make you do _anything_ that you don't want to do. I can't physically grab your fingers and type for you. I can't force you to read a ticket or PRD if you don't want to. If I want my team to do something, I have to _convince_ them. I have to make them believe that the direction I'm offering is worth it. "But you can fire him, Brian!" you might be thinking to yourself. And you'd be right. I _could_ fire him. But then what happens? I don't get what I wanted. He has lost his job and livelihood. I now have to interview dozens of candidates to replace them. And then, maybe, I get what I wanted... three to six months later. Worth it? Almost certainly not. # On Authority versus Responsibility Contrast this with a familiar archetype: the leader who treats titles as authority and not responsibility. You know what I'm talking about: the founder who says "I'm the boss, do as I say," and who treats disagreement as insubordination rather than input and collaboration. Who, frequently, will loudly proclaim their desire for collaboration, yet fall back on appeals to authority when they don't get their way. As a colleague of mine once said, "If you have to say you're the boss, then you're not acting like the boss." You see this all the time in politics and leadership. The people with the real power are not out there bragging about how powerful they are. They're quietly getting things done. And the real leaders, the ones with loyal followings and people who will do anything for them, treat their roles as responsibilities rather than power. ## An Illustrative Lesson on Responsibility vs Authority A mentor of mine taught me this lesson. He asked me one time, "When I introduce myself to everyone else, what do I say?" I thought about it for a moment, then said, "You say: I'm John Smith, CTO." He shook his head. He said, "Next time, listen to what I say. I don't say my title. I say I am _responsible for technology_." Sure enough, the next time I saw him introduce himself, he said, "I'm So-and-So, and I'm responsible for technology at Company." There's a lesson here: words have meaning. Words have _power_. The way that you present yourself to the world, however subtly, influences the way people look at you. Note what he didn't say. He didn't say "I _own_ technology" or "I _manage_ technology" or "I _lead_ technology." No, what he said was, "I _am responsible for_ technology." See the difference? He's saying: The buck stops with me. I have a _responsibility_ to make sure that my teams are successful. # Back to the Beginning My job, as I see it, is a _responsibility_ to support my team to make them better engineers, better colleagues, better communicators, better friends and parents and siblings and neighbors. It's not just my job, it's my _duty_ to leave this company -- this team! -- in a better place than I found it. When my former colleague says to me, "No manager I've ever worked for has supported me like you have," then that sound you hear is me reveling in my success. I've created a space where they can succeed, where they feel loved and heard and understood, where they _want_ to be for the long haul. And that environment? That better world that we're creating where people are happier and more fulfilled? One of the side effects just happens to be... better output for the company. --- # Too Loud to Think With - Author: Brian Seitel - Published: 2026-06-13 - Tags: language, communication, politics - URL: https://blog.brianseitel.com/too-loud-to-think-with/ > We lost a word. But I have a new one. # We lost a word There's a verb that English has needed for a while, and until recently we had one. Trump, in the card-game sense, meant something specific: to play a card that wins not by being higher in the ranking, but by belonging to a different category of card entirely. A trump card doesn't beat you. It changes what game you're playing. That verb is now unusable, for two reasons. The first is obvious. The word got too loud to think with. The second is darker. The reason the proper noun colonized the verb is that it fits. Trump the person also appears to operate outside the normal rules. Not by being better or stronger or more qualified. By existing in a category where the usual comparisons don't apply. The word didn't just get crowded out. It got claimed. So we need a new one. The concept is still real and useful. Ethics, law, science, systems design: all of these have moments where one thing doesn't just outweigh another, it changes which comparisons are even valid. That's different from outranking something, or overriding it. Those words assume you're still playing the same game. My proposal: *outrule*. Full definition, examples, and the case for why it's distinct from the words we already have: [outrules.com →](https://outrules.brianseitel.com) --- # A Founder is not a King - Author: Brian Seitel - Published: 2026-06-05 - Tags: engineering, leadership - URL: https://blog.brianseitel.com/a-founder-is-not-a-king/ > Being a founder confers great power, but it also constricts you. # A Founder Is Not a King ## The Dream Most founders I know have a similar story: they're tired of working for The Man, they're frustrated by poor leadership, they believe they can solve the problem better, faster, and with more heart than the incumbents. They think they can do it all. For entrepreneurs, particularly in the age of AI-driven development, they think that founding their own company can give them all of that. They can be the benevolent dictator that drives a billion dollar valuation. It's a seductive story, one that I've felt myself. You had the idea. You took the risk. You built something from nothing, often while those around you said that it would never work, that you're nuts. That story is so real, so relatable. It's the reason we start companies in the first place. But, to bastardize Sun Tzu, that dream doesn't survive contact with reality, the kind of reality defined by term sheets, employee agreements, customer contracts, and the legal system. The dream says that founding means you answer to no one. That dream is often a nightmare. The counter-intuitive reality is that, as a founder, you answer to more people than almost anyone else in the building. And the consequence of getting that wrong? They're far more personal than any of your employees. ## What You Actually Signed Up For Before I go any further, I need to make a disclaimer: **I am not a lawyer. I am not your lawyer. This is not legal advice. This is a set of observations about what I've learned about where the rights of founders begin and end. That's it.** With that out of the way, let's discuss what you signed up for. When you incorporated your company, you became an officer of a legal entity. That sounds like a title, like a knighthood as an Officer of the British Empire or something. But in many ways, it's a Sword of Damocles above you, a set of obligations that constrain your actions. Fiduciary duty isn't a bunch of buzzwords on a contract. It's not a technicality. It means you are legally required to act in the best interest of the company. Not your preferences, not your convenience, not your vision of what the company should be. The company as it actually exists, with its actual stakeholders. Duty of care means you have to act like a reasonably prudent person in your role. Duty of loyalty means you can't subordinate the company's interests to your own. These aren't abstract ideas or fancy words to scare you. They're the basis of lawsuits. Very expensive ones. They're the reason officers get named personally in litigation. Your employees can be fired and walk away. You can be sued. ## The Stack You're Actually At the Bottom Of The org chart might show you at the top of the pyramid. You're the Big Boss, the Head Honcho, the King of the Hill. But when you look at the contracts you signed, you see a different story. If you have a board, you're accountable to your board through your shareholder agreements. You're accountable to your investors through the representations you made when they wrote you a check. You're accountable to your employees through labor law, which governs everything from how you can treat them to payments to retaliation. You're accountable to your customers through your contracts. And you're accountable to regulators through statute, whether you've read the relevant ones or not. This is an example where ignorance of the law is not an excuse. Kings answered to no one, and most of them eventually lost their heads. The modern founder has more counterparties with legal recourse than almost any other role in business. The modern crown is mostly decorative. ## A Clean Example Say someone notifies you of a contracted deliverable, one that you are uniquely qualified to resolve. They ask you in person. They ask you in email, in Slack, through a Jira ticket. There's documentation of the deliverable. Months pass. You're reminded occasionally, but you defer. No action is taken. That's not a backlog problem. That's a paper trail of willful negligence, and depending on the nature of those deliverables, it may already be a breach of your contractual obligations to customers, your duties to investors, and potentially various regulatory frameworks. "I'll get to it eventually" is not a defense. Quite the opposite, it's Exhibit A in a lawsuit that will drain you of money, time, your reputation and energy. Nobody had to accuse you of anything. The timeline did it for you. ## The Good News If there's one thing I've noticed about the founders who don't end up in these situations, they've figured out, early, that the obligations aren't a cage. They're a map. When you understand that you have a duty of care, you don't resent folks who tell you something's wrong. You thank them for creating an opportunity to fulfill an obligation you already had, and you may not have even known it. When you understand fiduciary duty, you stop making decisions based on what's convenient for you and start making them based on what's best for the company. That's not a constraint on your vision or your ability to execute. I prefer to think of it as a big flashing neon sign pointing the way to success. It's what successful execution actually looks like. The founders who treat accountability as an affront and an obstacle to their personal playground are the ones who confuse the feeling of having built something with the legal reality of what they built. Those are different things. The company isn't you. _You_ are a steward of _the company_. The best founders I've seen know this. It doesn't make them less bold. It makes them more precise. And like almost all successful people, those with constraints are the most innovative. --- # You Still Have to Know What to Ask - Author: Brian Seitel - Published: 2026-06-01 - Tags: engineering, ai - URL: https://blog.brianseitel.com/you-still-have-to-know-what-to-ask/ > The paradigm shift we need: the LLM prompts ME. # You Still Have to Know What to Ask A few weeks ago, we had a roadmapping meeting at work. Different executives took turns describing their vision of the product eighteen months from now. When it was the CEO's turn, he said something to the effect of: "I want a ChatGPT-style interface. You just hold up your phone and say, 'Tell me how my comment section is doing,' and it figures it out and tells you." I love this vision. I also think it's only half the problem. The other half? In order to use a chatbot, you have to know what question to ask. And a lot of the time, you don't. ## Search vs Browse I've been thinking about this since I spent years building e-commerce search engines, where we called it the Search vs. Browse problem. Imagine going to a grocery store with a shopping list. Thanks to this list that you pre-generated, you know exactly what you need. You zip to the right aisle, grab the item right off the shelf, and scoop it into your cart. Efficient and effective. You got what you needed, and you didn't waste time on anything else. Now imagine going without a shopping list. You're ambling through every aisle, scanning shelves, not looking for anything in particular. Your stomach is growling. Your brain is whirling, trying to put together recipes based on things your eyeballs scan. And then you spot it, a white box gleaming in forest of mediocre grocery products: Fruit Roll-Ups. You haven't had one since you were twelve. But you're an adult now, dammit, and you can buy whatever you want. Into the cart it goes. Now, let's be honest: would you have ever *asked* for Fruit Roll-Ups? No. But browsing the store surfaced a desire you didn't know you had. The entire current paradigm of AI -- the Claudes, the ChatGPTs, the Geminis -- is a search interface. You walk in with a list. You type your query. You get your answer. You move on to the next question. It's extraordinarily powerful... **if** you know what you're looking for. But most of the time, people don't. ## The LLM Should Prompt Me Here's the mental model I keep coming back to, the thing that makes me wonder if we're still in the early days of AI. Right now, I have to pick up my phone, hold a button, and say: "Hey Siri, when's my mom's birthday?" But notice what had to happen first. I had to *think* of the question. I had to already be worried about my mom's birthday, already have it somewhere in my mind, already know that I didn't know, and spend the energy coming up with the question, overcoming the inertia of whatever it is I was doing in the moment, and ask the question. The AI just answered. **I** did the cognitive work of knowing what to ask. Now imagine a different world. Siri just pops up on my phone: "Hey, Brian! Don't forget your mom's birthday is next Tuesday. Based on things she's mentioned to you over the last few months, here are a few gift ideas she might actually like that we can ship in time to get there. Anything jumping out at you?" Or: "You have a board meeting Thursday. I've prepared a draft for you to review." Nobody asked, but it surfaced things I needed to know. And the system knew that. That's the half I'm talking about, the thing that's missing from my CEO's vision. The current paradigm is that *I* prompt the AI. The thing that changes everything -- the actual killer feature -- is when the AI prompts *me*. ## The AI That Knows What I Need Before I Do I've described this to a few people and the response is usually some variation of: "But that's what agentic AI is doing." Maybe. I'll be honest with y'all: everything I've personally interacted with still requires me to initiate. I prompt it, it executes. The oven still nees to be turned on, the calendar still needs to be opened, I still ask the question. What I'm describing is something that's watching, understanding context, developing a model of what I care about -- and then deciding, on its own, that now is the moment to surface something. Not because I asked. Because it figured out I should know. I'm not talking about creepy surveillance and building some sort of clandestine profile of me in order to help me buy my mom Lego flowers. No, that's not what I mean at all. This doesn't have to be privacy-invasive. It can be based on the questions I do ask. I imagine systems that quiz me and develop a profile based on that, or things that learn from the things I explicitly do and from the questions I ask and formulate a model of what I care about. That might already exist somewhere in a lab. But it hasn't reached me yet. And I don't think it's reached most people. Which means there's still a very large, very important problem left to solve. The grocery store is full of Fruit Roll-Ups nobody's thought to ask for yet. --- # When Code is Free, What Do You Measure? - Author: Brian Seitel - Published: 2026-03-29 - Tags: engineering, ai - URL: https://blog.brianseitel.com/when-code-is-free-what-do-you-measure/ > Why the metrics we use to track engineering output are broken in an AI-native world, and what we should be measuring instead. # When Code Is Free, What Do You Measure? The CPO of Ramp recently went on YouTube to hype their "AI-native" approach: 50% of their PRs are AI-generated. With 200 engineers and 25 PMs, their output is tremendous. It comes across as really, really impressive. But he doesn't stop there. He goes on to tell us that PMs vibe-code, operators vibe-code, sales folks vibe-code. Everyone is encouraged to vibe-code solutions to their problems. During the interview, he demos a feature being built in real-time. While he talks, code appears, a PR is submitted, automatically reviewed, and deployed. "Hopefully this works," he says. "I'm not sure if this worked." It did. He then spends the rest of the interview as if it had been a foregone conclusion, stating confidently that "if you're not using Claude Code, you're behind." When pressed on ROI by the interviewer, he demurred: "I haven't done the math, but if I can submit 500 PRs a month, there's no expense that makes that not worth it." (paraphrasing) Translation: he's not measuring the right things. Neither is anyone else. ## A Concrete Example Don't get me wrong. I'm a big fan of Claude Code. I'm using it to write some software on the side: a Discord clone, or close enough for this example. Claude decided early on that it wanted to use a `map[string]*Session` to keep track of user sessions in the app. The key, Claude decided, will be the `username`, and the value is the user's session, which includes the TCP connection. This is fine. It's not what I would do, but it's fine. Later, I decided that I wanted a certain admin role to be held by multiple users -- an anonymous moderator, if you will -- which means that multiple users could be logged in as the same anonymous moderator. But wait! Our system only allows one session per _username_. Claude Code's suggestion? Rewrite the app to use `map[string][]*Session`, where the key is still the `username` and the value is now an _array_ of sessions. Of course, to accomplish this, everywhere we grab a session we now need to add a for-loop. Trivial for Claude! Oh, and now we need to make sure that when a session is closed, that we delete the appropriate entry in the array. Also trivial for Claude! By the time it was done, it updated nearly 1200 lines of code, announced its completion, and smugly remarked, "Perfect! Ready for the next phase?" At that point I stopped it and said, "Hang on a second. Wouldn't it be smarter to make the key a user ID instead?" I reverted the change (thanks, git), then instructed Claude to do it again, but this time using the user ID as the key instead of the username. Three minutes and 25 lines of code changed later, the fix was in. This was a _simpler_ approach. A _faster_ approach. A _cheaper_ approach. Claude Code would have happily introduced nearly 1200 more lines of code to solve the exact same problem. It would have cost me many multiples of tokens and context. It would have introduced complications down the road. And worse, if Claude Code didn't catch them, those complications themselves would introduce even more complications down the road. Here's the lesson: **bad code compounds.** And you know what Claude Code is not good at? Recognizing that its code is bad. ## When Code is Free, What Do You Measure? The reason the Ramp CPO won't talk about ROI isn't because he doesn't have the numbers. It's because **the numbers everyone tracks don't tell you if AI coding is working**. Traditional engineering metrics assume typing code is the bottleneck: - PRs shipped per month - Lines of code written - Velocity (story points completed) - Time to ship features These made sense when human typing speed was the constraint. But when AI can generate 1200 lines in three minutes, these metrics become _noise generators_. They measure your intake, not your output. The question isn't "how much code did we generate?" It's "how much code did we _keep_?" ## The Metrics That Actually Matter ### **1. Rework Rate** What percentage of AI-generated code gets reverted, refactored, or rewritten within 30/60/90 days? In my example, Claude Code generated 1200 lines that I immediately reverted. If I'd merged that PR, those 1200 lines would have lived in the codebase for maybe a week before I would have had to refactor it when the nested loops became a problem. That's a 100% rework rate. The code was _produced_, but not _kept_. If Ramp is shipping 500 PRs/month and 40% need rework, they're not moving 500x faster — they're moving backwards. Rework isn't just re-doing the work; it's _interrupting_ other work to go back and fix mistakes that compound. **How to measure it**: Tag PRs as `ai-assisted` or `human-written` in your commit message or PR description. After 30 days, check: how many were touched again? That's your rework rate. ### **2. Review Burden** How many human-hours does it take to review AI-generated code vs. human-written code? A PR that takes 3 minutes to generate but 45 minutes to review is net-negative. Especially if the reviewer has to mentally (or literally!) execute the code to figure out whether `map[string][]*Session` is the right choice, or if they just shrug and approve it because "the AI probably knows what it's doing." The second case is worse: you've just shipped technical debt with a stamp of approval. If your senior engineers are spending 80% of their time reviewing and reworking AI PRs instead of building, you haven't gained leverage at all. Instead, you've created a bottleneck. ### **3. Architectural Debt Accumulation** Does AI-generated code introduce complexity that compounds over time? This is the hardest to measure but the most important. The `map[string][]*Session` decision isn't _wrong_. It works! But it spawns for-loops, array deletions, potential race conditions, higher cognitive load for the next person touching that code. That next person might be another AI coding session, which now has to work around the complexity from the first session. Which introduces _more_ complexity. Which the third session has to work around... Proxy metrics: - Lines of code touched per feature (trending up = complexity accumulating) - Time to implement similar features over time (getting slower = debt compounding) - "Refactors required to unblock new features" ### **4. Bug Escape Rate by Source** Do AI-generated features have higher production bug rates than human-written ones? Tag PRs by generation method. Track bugs back to source. If AI code ships bugs at 3x the rate of human code, your "10x velocity" is actually 3x drag. ### **5. The Person A vs. Person B Problem** Here's the invisible metric: _who's using the AI tools?_ Two people use Claude Code: **Person A** sees the `map[string][]*Session` suggestion, pauses, thinks "wait, this introduces nested loops and array management everywhere," and changes it to `map[userID]*Session`. Ships 25 lines of clean code in 3 minutes. **Person B** sees the same suggestion, checks the output, runs it, watches it work, and confidently declares "it works!" then merges 1200 lines. Ships messy code in 3 minutes. Both people generated code 10x faster than they could type. Both feel productive. Both get the dopamine hit. Both think they're winning. But the outcomes are completely different. **Here's what Person B doesn't see:** They don't see that "it works" and "it's good" are not the same thing. They don't notice that the AI introduced three for-loops where zero were needed. They don't realize that the delete-from-array logic has an edge case that will surface in production in three months. They don't understand that they just made the codebase harder to reason about for everyone who touches it next. They _tested_ the code. They _ran_ the code. They _verified_ the code works. And because it works, they assume it's right. At worst, "good enough." **But "works" is not the bar. "Works better than the alternatives" is the bar.** And Person B doesn't know how to evaluate alternatives because they don't have the architectural intuition to generate them. Person B thinks their job is to make the AI's code work. Person A knows their job is to make the AI suggest better code in the first place. The failure is invisible until three months later when Person B's code has metastasized into a tangle of edge cases, and Person A is stuck reviewing the cleanup PRs instead of building new features. Here's the thing, though, the part that the CPOs and the boards and the hype machines keep missing: **Person B usually has no idea they're Person B.** They see code appearing on screen. PRs merging. Velocity trending up. All the signals say "this is working." Most organizations can't tell the difference between Person A and Person B until the codebase is on fire. ## Why "50% of PRs Are AI-Generated" Tells You Nothing When the Ramp CPO brags that 50% of their PRs are AI-generated, my first question is: _who's generating them?_ If it's the 200 engineers using AI as a force multiplier on their judgment -- that is, people who can spot the `map[string][]*Session` trap -- then that's incredible. If it's the 25 PMs, the sales team, the operators vibe-coding their way through features because it feels productive, that's a ticking time bomb. The number doesn't tell you which one you have. But your rework rate does. Your review burden does. Your bug escape rate does. Fair pushback: "Even if 40% is rework, the remaining 60% is still a net win." Maybe. But only if the cost of reviewing, debugging, and unwinding the bad 40% doesn't exceed the value of the good 60%. Most teams aren't measuring either side of that equation. The Ramp CPO didn't talk about ROI because the industry doesn't have a framework for measuring it yet. We're all still counting PRs like it's 1995, when the actual economics have completely flipped. ## What This Means for You If your board is pressuring you to "go AI-native" because Ramp did it, ask them: what does success look like? If the answer is "more PRs" or "faster velocity," you're optimizing for the wrong thing. You're measuring your intake, not your output. The companies that win with AI coding tools won't be the ones that generate the most code. They'll be the ones with the best **taste** for what to keep and what to kill. **Measure what matters: not how much code you generate, but how much you keep.** --- # Long Live the Vibes - Author: Brian Seitel - Published: 2026-03-18 - Tags: engineering, ai - URL: https://blog.brianseitel.com/long-live-the-vibes/ > Why the software development lifecycle isn't dead, and how to think about the role of AI in software development. # Long Live the Vibes (or: SDLC isn't dead, you just automated the easy part) When I was in high school, I worked at a place called the Elastic Corporation of America. It was a manufacturing facility that made elastic bands (eg, bra straps, underwear bands) for brands like Fruit of the Loom, Victoria's Secret, and Hanes. The facility had four departments: Weaving, Dyeing, Finishing, and Shipping. Thread came in one end. Finished elastic went out the other. I worked in Finishing. My job was to take dyed fabric and get it to the exact right shade, stretchiness, and poundage that the brand specified. I'd tie the fabric on one end, let it run through a trough of dye and chemicals, then feed it through a series of massive drums heated to 300°F or higher. The fabric would snake back and forth across these drums until it came out dry on the other side, dropping into boxes. None of this was done by hand. A hundred years earlier, it would've been. But by the time I got there, machines handled the weaving, the dyeing, the drying, the feeding. I didn't rub dye into fabric with my hands. I didn't hold a hairdryer up to it. I didn't haul buckets of water. The machines did all of that. But I still had to read the paperwork to understand what temperature the drums needed, which chemicals went into the trough, how fast the fabric should move. I still had to take samples to my boss so he could evaluate how close we were to spec. If it was off, we'd tweak the chemicals and run it again. And if a machine broke, I had to stop the line, fix it, and throw out the fabric that had been sitting on 300-degree drums too long, because that fabric was ruined. The machines were precise. They were fast. They were repeatable. But they had no idea whether what they were producing was correct. That was my job. ## The part that doesn't automate away There's a narrative going around right now that AI has killed the software development lifecycle. The argument goes something like this: coding agents are so capable that the old stages -- requirements, design, implementation, testing, review, deployment, monitoring -- have collapsed into a single tight loop. Intent in, working code out. The SDLC is dead. Long live the vibes. I think this is wrong, and I think the manufacturing floor is a good lens for understanding why. When industrial automation arrived in manufacturing, it didn't eliminate the production process. It eliminated the manual labor *within* the process. The stages still existed: you still needed raw materials, you still needed to transform them, you still needed quality control, you still needed to ship. What changed was who, or what, performed each step. The lifecycle didn't collapse. The human role within it shifted. You went from doing the work to supervising the work. From pulling cranks to reading specs and adjusting parameters, from producing output to evaluating output. That's exactly what's happening with AI and software development. ## AI automates the mechanical, not the judgment Coding agents are genuinely good at the mechanical parts of software development: generating boilerplate, writing CRUD endpoints, producing test scaffolding, wiring up deployment pipelines. The stuff that, frankly, was always the least interesting part of the job. But the SDLC was never really about those mechanical steps. It was about the judgment calls that happen between them. What should we build? Does this design hold up under the constraints we actually have? Is this code correct? Not just syntactically, but semantically? Does this change break something downstream that the tests don't cover? Are we done? Those questions don't go away because an agent can generate code faster. If anything, they get harder. When an agent generates 500 changes in a day, the question isn't "how do we review all of these?" It's "how do we know which ones matter?" That's not a tooling problem. That's a judgment problem. And judgment is exactly what the SDLC exists to structure. ## Knowing when you're done is the actual job The trickiest part of working in Finishing wasn't running the machines. It was knowing when the fabric was right. Close to spec isn't on spec. Even though the shade on the sample looked fine under the fluorescent lights in the factory, it might look wrong in a retail store. Stretchiness that passes a quick pull test could fail under the brand's more rigorous standards, which meant the fabric would be rejected by the brand's quality control and returned to us, costing us time and money. Getting to "done" required iteration, evaluation, and the accumulated knowledge of what "right" looked like for each brand, each product, each color. The machines couldn't tell me that. My boss could, and over time, I learned to see it myself. When I first started, white was white was white was white. But by the time I left, I could differentiate between mother of pearl and eggshell and ivory, and I could tell you which one was right for any given product. Software works the same way. An agent can generate a feature in minutes. But knowing whether that feature actually solves the problem? Whether it handles the edge cases that matter? Whether it fits into the existing system without creating debt? Whether it meets the actual need and not just the stated requirement? That's the real work. That's what requirements gathering, design review, code review, and QA exist to answer, however imperfectly. The ceremony around those stages might be bloated, sure. Sprint planning might be theater, if you want to put it that way. Story points might as well be astrology, if we're being honest with ourselves. But the underlying questions of what are we building, is this right, are we done? That's the job! That's not just ceremony! ## The lifecycle shifted, it didn't die If I were writing a more honest version of "the SDLC is dead" take, it would be this: the SDLC is shifting away from engineers and toward the people who define intent. When code generation is cheap, the bottleneck moves upstream. The hard part isn't writing the code, just like the hard part isn't weaving the fabric or dyeing it exactly the right color. It's knowing what code to write. It's providing the right context, defining the right constraints, evaluating the output against the actual goal. That sounds a lot like product management to me. Or systems design. Or -- get this -- engineering, just with different tools. The role changes but the lifecycle doesn't disappear. You still need to figure out what to build, how to build it, and perhaps most importantly, when you're done. You still need to evaluate whether what you built is correct. You still need to monitor it in production and respond when it breaks. You might do all of those things faster, with better tools, with agents handling the mechanical parts. But the stages exist because the *problems* they address exist, and those problems don't care how the code was generated or how many PRs you can put up in a day. Calling the SDLC dead because agents can write code is like saying manufacturing died because machines can weave fabric. The weaving was never the hard part. --- # On Hiring - Author: Brian Seitel - Published: 2026-03-01 - Tags: engineering, leadership - URL: https://blog.brianseitel.com/on-hiring/ > Why the traditional hiring process is flawed and how to use your existing team as a benchmark for hiring decisions. ## You're Hiring Wrong In 2016, I sat in a conference room interviewing a highly anxious woman for a QA role. Thirty-minute slot. Within fifteen minutes, I knew: hard no. Not her fault at all. We just needed someone more senior. As I walked out, the next interviewer walked in. I headed back to my desk. My boss looked up, eyebrows raised, two thumbs up. I shook my head. Two thumbs down. Minutes later, the candidate was being escorted out. I panicked. "Wait, did you just cut the interview short because I said no?" "Yes." "But... I don't know how she calibrates against other candidates." "Brian, how many QA folks have you worked with?" "Dozens." "Was she at the top of that list?" "No." He leaned back, arms folded. "There you go." I sat down. Another engineer whispered, "I'm with you, man. We need more signal." But the more I thought about it, the more I realized my boss was right. ## The Secretary Problem There's a famous statistics problem that goes like this: > You need to hire a secretary. Everyone's qualified, everyone's looking. Unlimited candidates, but once they walk out, they're gone forever. You must decide in real time. > > How do you know when to stop and hire? **The solution:** Interview N candidates (say, 100), reject all of them, then rank them. Starting with candidate 101, hire the first person better than your #1. You won't get the best candidate ever, but you'll get someone excellent. ## The Real World "Brian," you might be thinking, "you can't possibly be suggesting that we reject the first 100 candidates we interview before we even think about making an offer. That would be expensive, not to mention a massive amount of time and resources!" Right. Most people say "Interview 5, pick the best." But what if you get 5 mediocre candidates? Then you hire mediocre instead of waiting for amazing. The intuition my boss had was correct: treat each candidate individually. Meet your bar? Hire them. ### So where's the bar? My boss nailed it: I've worked with dozens of QA analysts. Hundreds of engineers. Two dozen managers. Interviewed hundreds more. *That's* my dataset. Who's the best QA analyst I've ever worked with? That's my bar for QA. Best backend engineer? That's my bar. Best PM, manager, VP, recruiter, data scientist? That's my bar. You don't need a pool of candidates for signal. You already have it: your coworkers, past and present. Look around. Who's the best? Alan? John? Stacy? If this candidate is as good or better, hire them. If not? Well, they say good things come to those who wait. --- # On Trust - Author: Brian Seitel - Published: 2025-11-05 - Tags: engineering, leadership - URL: https://blog.brianseitel.com/on-trust/ > Why trust is the foundation of successful engineering and organizational relationships. ## On Trust They say that the most important ingredient in any relationship is trust. It's hard to argue otherwise. How can you have a fulfilling relationship with anyone, if you can't trust anything they say or do? If their actions contradict their words, how can you believe them? This is often spoken in the context of interpersonal relationships, and more specifically romantic ones. That said, it also applies to organizational relationships. In a recent role, there was a huge lack of trust between the Engineering organization and The Business(TM). Over the last 12 years of the company's existence, the Engineering team had struggled to deliver strong, robust features to customers. They struggled so mightily that for many years The Business micromanaged the Engineering organization. They had weekly status update meetings, and while on paper Engineering was a separate organization, in practice the VPs behaved as if they reported to the Head of Marketing, a strong and very capable woman -- albeit not an engineering leader. Trust had eroded over the course of several years to the point where Marketing was the driving force behind what was ostensibly a tech company. When I joined the company, this was perhaps the first dynamic I identified. Within days, I could see that there was no strategic vision, simply a willingness to do whatever Marketing asked. This led to a series of problems that cascaded into a tsunami that ultimately exacerbated the problem altogether: without a solid technical foundation and strong tech-oriented leadership, the entire codebase was a series of hacks and poorly thought out executions on feature work. It took almost a year for that to change. The tech leadership left, and a new order, including myself, took up the mantle of leadership. Our first order of business: re-establish trust. ## The Stack Rank There are many tools that can help with organizational success, but in my view, the biggest problem we had was that Engineering was purely reactionary. We didn't have a plan, and more importantly, we didn't have a strategy. Our prioritization method was what I called The Loudest in the Room. In other words, the last person to run in screaming that their thing was important *became* the most important thing. That clearly isn't going to scale. I partnered up with the Senior Director of Product and we introduced a Stack Rank to the organization. We compiled a list of every feature request that came in, and we ranked them in order of priority, from top to bottom. How you determine priority is a touchy subject, but to keep things as objective as possible, we prioritized on two axes: importance and urgency. Importance is a shorthand for money. If it made us a lot of money, it was important. If it didn't make us any money at all, it was not important. Urgency, on the other hand, is time-based. If we don't do X within Y weeks, we will have Big Problems (TM), and that makes it urgent. If there's no time component, then it's not urgent. Our list started out with 150 items on it. We prioritized the top 35, and then the hard part started: convincing the teams and the business that these were, indeed, the most important tasks. ## The Swarm Prior to my joining the company, the strategy had been what my Product partner dubs the Peanut Butter Approach. We spread our team out across every project imaginable. Each engineer had two, three, even four projects to manage at any given time. Context switching was hell, and post-mortems and ROI calculations were all but impossible. One of the major changes I implemented in my organization was to swarm on the big projects. I decided to maximally staff the most important project. I had twenty-five engineers at my disposal. But few projects are sustainable with that many engineers focused on a single project, so I worked with the managers and determined what the maximal staffing level was. For most projects, it was somewhere between 4 and 6 engineers, or what Bezos would call a two pizza team. The goal was to swarm on the most important projects and finish them as fast as possible. Get them out into production and start reaping the benefits. Then take those engineers and swarm on the next big project. This worked *phenomenally*. We shipped more features in Q3 and Q4 of 2022 than we had in the previous year combined. ## The Final Exam Our business is in the e-commerce space, and specifically, we specialize in products that are in high demand during the holiday season. At least sixty percent (60%!) of our annual revenue occurs in just three weeks in Q4, between Thanksgiving and Christmas. That's... a lot. It also means that we cannot screw up. We cannot have downtime. We cannot have bugs. Due to the lack of trust in prior years, we would go into a code freeze at the beginning of November and stay in it until January. Only bug fixes were allowed to ship during that time, and even then, we valued stability over properly working code. The Business (TM) understandably panicked the closer we got to Thanksgiving, and in return, the Engineering and Product teams panicked, too. But not in 2022. In 2022, because we identified Q4 stability as a number one initiative, we swarmed almost half of our organization on alerting, bug fixes, DB query optimization, and more. We spent late Q3 and early Q4 tightening up our systems, hitting our servers with peak load to ensure we could stand up to that Black Friday and Cyber Monday traffic, and we tested everything out the wazoo. Our goal: to build trust with The Business(TM) that we could stand up to peak traffic without a problem. Because of our swarming on these, we were able to build confidence within our own teams that things would be better. We could see graphs and raw numbers that showed our performance was better than previous years. Exceptions would blow up in our faces, instead of silently surfacing in New Relic and not seen for days. When Q4 came, the office was silent. Our code freeze began, and we... didn't have a whole lot to do. We passed the test. ## Freedom Marketing saw our progress, they saw our commitment and ability to execute, and they stepped back. They let us prioritize our list and bring it to them. As Q4 went smoothly, we were able to take most of our engineers and put them on actual feature work. That meant things at the top of our stack rank! Instead of putting out fires, our engineers were executing on the company's vision. We were making progress. And more importantly, we achieved a certain degree of freedom that had been missing. Instead of being micromanaged by Marketing, Engineering came into its own. ## The Future The company is still in the early days of this newfound freedom. We are constantly updating our stack rank, constantly evaluating which projects are more important than others. But a few things remained the same throughout my tenure: we swarmed on the most important things, we prioritized ruthlessly, and above all, we aimed to earn the trust of the rest of our company. Lesson learned. --- # On Prioritization - Author: Brian Seitel - Published: 2025-11-05 - Tags: engineering, leadership - URL: https://blog.brianseitel.com/on-prioritization/ > Why prioritization is the key to successful engineering and organizational outcomes. Stop me if you've heard this before: a company leader comes into the room and floats an idea with such conviction that everyone drops what they're doing to solve this problem immediately. Then, later, it turns out that it was just a cool idea. There's no value in it whatsoever. I recently started a new role, and that's the first thing I observed. People worked on what was right in front of them, rather than working on the right thing. When a Product person suggests an idea, the team swarms on it. When the VP of Engineering has an idea, the team swarms on it. When an alert goes off, the team swarms on it. One of my reports asked me, "What's the big deal? We're getting things done." I find that analogies are helpful when describing concepts that, for whatever reason, we struggle to see in the moment. And so I gave him a scenario to consider, and I'll share it with you: You take your daughter to the playground for an hour before it's time for dinner and then her bedtime. She's swinging on the swing, happy as can be, when you get a phone call. It's your neighbor. "Hey," he says, "can you help me move a couch? I'll buy you pizza." You say, "I can help you in an hour." Why didn't you yank your kid out of the swing and throw her in the car and blow past all the stop signs on the way home? There's pizza involved, for God's sake! Because, of course, the time with your daughter is more important than helping your neighbor move a couch. The couch will still be there in an hour, the pizza will be there in an hour and a half. It's not urgent. It's not worth interrupting quality time with your daughter. But imagine your neighbor calls and says, "Your wife just tripped over the hose in the yard and hit her head and seems disoriented. I'm driving her to the urgent care." You bet your ass you'd throw your kid in the car and blow past all the stop signs. You've got a wife who needs your help! That's more important! Yet, somehow, when we work in corporate environments, this simple decision making, this straightforward aspect of prioritization seems to escape us. We fight the fires right in front of us, we tackle the tickets that come our way, we chase after the shiny thing. It takes discipline and wisdom to stop and ask ourselves: is this the _right_ thing for me to be working on? Because the chances are the shiny thing, the thing that just crossed your desk, the loudest voice in the room? They aren't that urgent. They can wait til tomorrow. They can wait til next week. Finish the playground trip with your daughter. Finish the project you were working on first. The rest can wait. --- # Decisiveness: The Most Valuable Leadership Skill - Author: Brian Seitel - Published: 2025-10-16 - Tags: engineering, leadership - URL: https://blog.brianseitel.com/decisiveness-the-most-valuable-leadership-skill/ > Why decisiveness is more important than being right, and how to build it as a muscle. I have a friend who spent two years debating whether to leave Boston. Should she move to Denver where the lifestyle fits better, or Columbus where it's more affordable and friends live? Two years of spreadsheets, pros and cons lists, anxiety. I finally told her: "Just pick one. A year from now you'll be mad you didn't move sooner." She's moving in November. ### Here's what I've learned about decisiveness: Indecision is more expensive than the wrong decision. My friend lost two years in a city that made her unhappy. That's the real cost. Not whether she picked the "optimal" city, not whether one place had better food than the other. The real cost was wasted time and emotional fatigue. **Decisiveness compresses your feedback loop**. She'll know in 3 months if her choice works. If not, she can adjust. Meanwhile, two years of deliberation taught her nothing. Look, very few decisions are truly irreversible. You can move again. You can hire someone new. You can change course. Decide now, not later. ### Indecision is stressful I once kept a poor-fit employee too long because he was talented in one area, even though he wasn't doing the job I needed. The team loved him. Firing him felt impossible. A mentor told me: "Just make the call. The second he's gone, you'll never think about him again." He was right. The moment I decided, I could breathe again. The stress evaporated. My team was able to adjust, we hired someone new that was a better fit, and it was full steam ahead. ### Indecision destroys trust and credibility. I spent this summer in a hiring process that included four meetings with the manager, another high-level employee, and a panel interview. The result? Positive feedback across the board. Then four months of silence before being told they went another direction. That manager learned absolutely nothing in those four months that he couldn't have learned in the four business days in which we talked. He just burned time and credibility. Now? I see a huge red flag. Decisiveness is a muscle. Every time you make a decision and survive the outcome, good or bad, you build evidence that your judgment is trustworthy. You learn what right feels like versus wrong. You learn that mistakes happen. You learn that almost every decision is reversible, very few are permanent. You trust yourself. Indecisive people think they're being careful. Really, they're just avoiding discomfort. And that avoidance has a massive cost: wasted time, lost opportunities, and chronic stress. We didn't land on the moon by being conservative. Taylor Swift didn't build a billion-dollar tour by playing it safe with her creative and business choices. Michael Jordan didn't become the greatest basketball player in history by not shooting his shots. Make the decision. Learn from it. Move forward. Don't want, decide now.