Most engineering feedback is a polite waste of breath. It’s either a sugar-coated nothingburger that leaves the recipient confused, or blunt-force trauma that sends them straight to LinkedIn. The real technical problem in our culture isn’t the stack—it’s how we talk about each other’s work without leaving a crater.

I’m Fritz Muller, and I’ve spent more time debugging human systems than code. Here’s the uncomfortable truth: if your feedback doesn’t change behavior, you’re just having a chat. And if it burns trust, you’re not a leader—you’re a liability.

The Feedback Paradox: Why We Suck at This

Engineers are trained to spot defects. We’re excellent at finding the one misplaced semicolon in a thousand lines of code. That same brain, applied to a colleague’s pull request or presentation style, becomes a weapon. We confuse “accurate” with “helpful.” We think pointing out what’s broken is the same as fixing it.

The paradox is simple: feedback must be honest enough to matter and safe enough to hear. Most of us pick one. The passive-aggressive architect who writes “interesting approach” in a PR review has chosen safety. The senior dev who says “this is garbage” during standup has chosen honesty. Both fail. One preserves a fake peace; the other wins a battle and loses the war.

The Trust Battery Concept

Think of trust as a battery. Every interaction either charges or drains it. When the battery is low, even mild criticism feels like an attack. When it’s high, you can say almost anything. The mistake is delivering feedback without checking the charge level first. If you’ve never acknowledged someone’s good work, your first negative comment will short-circuit the relationship.

I once watched a CTO dismantle a junior engineer’s system design in a public Slack channel. Technically, every point was correct. The design had scalability holes you could drive a truck through. But the CTO had never publicly praised that engineer for anything. The trust battery was at zero. The engineer quit within a month. The feedback was accurate. It also destroyed a promising career trajectory because the delivery was calibrated for a robot, not a human.

The Behavior-Specific Feedback Loop

Vague feedback is emotional litter. “You need to be more proactive” is a feeling, not a directive. “You didn’t update the runbook after the last incident, which meant the on-call person spent two hours guessing” is a behavior. One invites defensiveness. The other invites a specific fix.

The loop I enforce on my teams is painfully simple:

1. Observe the specific action. Not the person’s character, not their intentions—the observable thing they did or didn’t do. “You interrupted Priya three times during the design review.”
2. Describe the impact. Not your feelings—the concrete consequence. “That meant her concerns about the database schema weren’t heard until we’d already committed to the wrong indexing strategy.”
3. Request a change. Make it a clear, doable action. “Next time, let her finish her point before jumping in. If you disagree, jot a note and circle back.”

This isn’t soft. It’s precise. It strips out judgment and leaves only the mechanics of improvement. When I give feedback this way, there’s nothing to argue about. Either you interrupted or you didn’t. Either the schema was wrong or it wasn’t. The conversation stays on the event, not the ego.

Why “Radical Candor” Gets Misused

Somewhere along the line, the concept of radical candor got hijacked by people who just wanted to be rude. They heard “challenge directly” and ignored “care personally.” The framework isn’t a license to unload. It’s a two-axis model: if you’re not investing in the relationship, your directness is just obnoxious aggression.

I’ve seen managers start feedback sessions with “I’m just being radically candid” and then deliver a monologue about someone’s shortcomings. That’s not candor. That’s a performance review disguised as courage. Real candor is a conversation. It starts with a question like “How do you think that meeting went?” and then shuts up long enough to hear the answer.

Timing and Setting: The Invisible Factors

Feedback delivered in public is punishment. I don’t care if you frame it as a “teaching moment.” If there are witnesses, the recipient’s brain flips into self-preservation mode. They’re not processing your words—they’re managing their reputation. Save it for a private channel or, better, a face-to-face conversation.

Timing is equally critical. Feedback given right after the event is gold. Feedback given three weeks later during a formal review is a betrayal. If you sat on a problem until the quarterly review, you weren’t trying to help—you were building a case. I tell my teams: if you can’t deliver feedback within 48 hours, ask yourself why you’re hoarding it.

The 24-Hour Rule for Emotional Feedback

There’s an exception. If you’re angry, wait. Hot feedback is almost always poorly framed. I’ve sent drafts of furious messages, then deleted them the next morning. The core issue was real; the wording was radioactive. Give yourself a day to separate the emotion from the observation. Then deliver the observation cold and clean.

Receiving Feedback Like a Functioning Adult

Giving feedback is half the equation. The other half is your own reaction when the mirror is turned on you. Most engineers I know have a brittle relationship with criticism. We’re used to being the smartest person in the room, and feedback threatens that identity.

My rule is brutal: when someone gives you feedback, your only job for the first two minutes is to listen and ask clarifying questions. No defending. No explaining. No “well, actually.” If you jump straight to justification, you’re telling the other person their observation isn’t valid. You’re training them to never speak up again.

Try this script: “Thanks for telling me. Can you give me an example of when I did that?” Then stop. Let the silence sit. Your brain will scream at you to argue. Ignore it. You can decide later whether the feedback is accurate. In the moment, your only task is to understand.

When Feedback Is Wrong

Sometimes feedback is genuinely off-base. The person misunderstood your intent, or they’re projecting their own insecurities. Even then, don’t dismiss it outright. Wrong feedback often points to a communication gap. If someone thinks you’re being dismissive, maybe you’re not explaining your reasoning clearly. The feedback about you might be inaccurate, but the feedback about their experience of you is always real. Address that experience, not the accusation.

Feedback in Code Reviews

Code reviews are the most frequent feedback channel in engineering, and we’ve normalized a toxic culture around them. Nitpicking variable names is not feedback—it’s bike-shedding. Dumping ten comments on a PR without a single positive note is not thorough—it’s demoralizing.

I enforce a simple structure: every PR comment that identifies an issue must also suggest a solution or ask a genuine question. “This is wrong” is a complaint. “This could cause a race condition because of the async call on line 34—what if we move the await up?” is collaboration. The first makes you a critic. The second makes you a colleague.

And for the love of everything, leave approval comments that are specific. “Looks good” is worthless. “The refactor on the payment module is clean—much easier to test now” tells the developer exactly what they did right. It charges the trust battery so that when you do flag a problem, it lands on fertile ground.

Separating Style from Substance

Too many code review comments are about personal preference disguised as objective truth. Unless your team has an agreed-upon style guide, your opinion on spacing versus tabs is just noise. Flag bugs, logic errors, and architectural concerns. If it’s a stylistic nit, either automate it with a linter or let it go. Your aesthetic preferences are not feedback.

Cultural Damage and Repair

Broken feedback cultures don’t fix themselves. They fester. People stop speaking up in meetings. PRs get rubber-stamped. The loudest voice wins by default. I’ve walked into teams where the official value was “blameless culture” but the reality was a silent blame-fest where mistakes were whispered about in DMs.

Repair starts with one person modeling the behavior. When a senior engineer says, “I was wrong about that approach—thanks for catching it,” they give everyone else permission to be imperfect. When a manager asks for feedback on their own decisions and then visibly acts on it, they demonstrate that feedback isn’t a trap.

If you’re in a team where feedback is broken, don’t wait for permission. Start small. Give one piece of behavior-specific, positively-framed feedback to a peer this week. Ask for feedback on something you did, and receive it without a flinch. Culture isn’t a top-down decree. It’s the sum of tiny, repeated actions.

FAQ

How do I give feedback to someone more senior than me?

Frame it as sharing your perspective, not delivering a verdict. “I noticed something in the planning meeting that I wanted to share—can I run it by you?” Seniority doesn’t mean infallibility. If the senior person reacts poorly to respectful, specific feedback, that’s a them problem, not a you problem. Document the exchange anyway.

What if I’ve already damaged trust with someone?

You can’t retroactively fix a bad delivery, but you can own it. Go to the person privately and say, “I think I handled that feedback badly. I should have been more specific/private/timely. Can I try again?” This isn’t groveling—it’s demonstrating that you care more about the relationship than being right. Trust can be rebuilt, but only if you’re willing to admit the initial failure.

How do I know if my feedback actually changed behavior?

Watch, don’t ask. After delivering feedback, note whether the specific action shifts within the next two weeks. If you said “please update the runbook after incidents” and the next incident still has no runbook update, your feedback didn’t land. Follow up: “Hey, I noticed the runbook wasn’t updated after last night’s outage. What got in the way?” This turns a missed expectation into a joint problem-solving session, not a second scolding.

Can written feedback ever be as effective as spoken?

Written feedback is permanent and prone to tone misinterpretation. A comment like “rethink this” in a PR can read as curt dismissal when you meant it as collaborative brainstorming. For anything with emotional weight, deliver it verbally—or at least start there. Use text for documenting agreements, not for initiating difficult conversations. If you must write, read it aloud before sending. If it sounds cold, it will read colder.

The engineering culture problem isn’t a mystery. We’ve just convinced ourselves that technical skills excuse human clumsiness. They don’t. Feedback is a skill, not a personality trait. You can learn it, practice it, and measure it by whether the people around you actually change what they do. If they don’t, your feedback method is broken—and that’s the real bug you need to fix.

Look, most engineering feedback lands about as well as a code review that just says “LGTM” while the architecture is held together with hope and a sticky note. We’ve all been there. You sit down with someone, try to tell them something they need to hear, and suddenly you’re the villain in a performance review drama. Or worse, you’re the person who said nothing, and now the same broken pattern has shipped to production for the sixth time.

Here’s the thing nobody wants to admit at standup: the way we talk to each other about work is a technical problem. Not a soft-skills seminar. Not a “let’s hold hands and share feelings” exercise. I’m talking about the actual systems, protocols, and failure modes of human communication inside an engineering culture. And most of you are running legacy code in your brain when it comes to giving someone a piece of critical input.

This isn’t about being nice. It’s about being surgically precise. I’ve seen teams where the “blunt” engineer leaves a trail of resentment so wide you could drive a sprint retrospective through it. I’ve also seen teams where everyone is so terrified of conflict that bugs get renamed “known behaviors” and shipped with a shrug. Both are trust-failures. Both cost you velocity, quality, and the ability to look your colleagues in the eye.

So let’s fix the damn protocol.

The Feedback OS Is Corrupted

Most people treat feedback like a ticket they file against another human. They wait until the bug is reproducible, document the expected vs. actual behavior, and then assign it a priority level that only exists in their own head. The recipient opens this ticket and immediately goes into defensive triage mode. “Cannot reproduce.” “Working as intended.” “Won’t do.”

This model is broken because humans are not Jira. We don’t process emotional payloads through a REST API. When you frame feedback as a defect report, you’re triggering every insecurity circuit that person has. Their brain starts scanning for evidence that you’re wrong, that you’re biased, that you don’t have the full context. And the actual behavior change you wanted? Buried under a pile of mental stack traces.

The real problem is that feedback is often delivered without any shared understanding of what “good” looks like. It’s like telling a junior dev their code is “not clean” without ever defining your team’s architecture principles. You’re expecting them to read your mind, and then you’re surprised when they get defensive. That’s not a communication failure on their part. That’s you shipping an undocumented API and getting mad when the client sends a malformed request.

Define the Schema Before You Send the Payload

Before you ever open your mouth to give someone feedback, you need to ask yourself one question: what is the specific, observable behavior I want to change, and what is the observable behavior I want to see instead? If you can’t articulate that in a way a robot could validate, you’re not ready to talk to a human.

“You need to be more proactive” is garbage feedback. It’s a vague judgment wearing the skin of helpfulness. “In the last three sprint plannings, you didn’t raise any concerns about the technical scope, and we ended up with unplanned work that delayed the release” is actual data. That’s something a person can look at and think, “Okay, I can change that.”

This is not about being pedantic. It’s about giving the other person a spec they can implement. Engineers are builders. We understand inputs, outputs, and acceptance criteria. When you give feedback that looks like a poorly written user story, you’re insulting their professional intelligence. When you give feedback that looks like a clear bug report with reproduction steps, you’re showing respect for their ability to fix things.

The Intent-Impact Gap

Here’s where a lot of well-meaning engineers screw up. They assume that because they didn’t intend to cause harm, the other person shouldn’t feel harmed. That’s like saying because you didn’t intend to introduce a race condition, the production outage shouldn’t count. The impact is what the system experienced, not what you meant to deploy.

When you give feedback, you have to acknowledge this gap explicitly. Not with some performative “I’m sorry you feel that way” nonsense. I mean actually saying: “I know you were trying to move fast and unblock the team, and I respect that intent. The impact, though, was that we lost two days debugging because the commit messages didn’t explain the context. Can we figure out a way to keep the speed without losing the traceability?”

That sentence does more psychological heavy lifting than a month of “communication training.” It separates the person’s identity from the behavior. It validates their intentions while being unflinching about the consequences. And it positions the two of you as collaborators solving a shared problem, not as judge and defendant.

Trust Is a Cache That Invalidates Easily

Engineering teams run on trust. It’s the cached credential that lets you merge code without every line being scrutinized by a committee. But trust is a distributed cache with terrible invalidation logic. One bad interaction can poison the entire system, and rebuilding it takes exponentially longer than tearing it down.

The fastest way to corrupt the trust cache is to give feedback that attacks identity instead of behavior. “You’re disorganized” is an identity attack. “Your project board hasn’t been updated in two weeks, and it’s making dependency tracking harder for the team” is behavioral feedback. The first one makes someone want to prove you wrong. The second one makes someone want to update their project board.

Another trust-killer: giving feedback only when things go wrong. If the only time you talk to someone about their work is to point out flaws, you’ve trained their nervous system to associate your voice with threat. That’s not feedback. That’s a conditioning experiment, and you’re the negative stimulus. Regular, specific positive feedback isn’t fluffy team-building crap. It’s building up a reserve of goodwill so that when you do need to deliver something hard, the relationship can absorb the load.

Timing Is a Performance Characteristic

Feedback delayed is feedback denied. The longer you wait after an observed behavior, the more the memory degrades, the context gets fuzzy, and the emotional charge dissipates into weird resentment. You ever had someone bring up a thing you did three months ago in a performance review? It feels like an ambush because it is an ambush. You’ve been sitting on data that could have helped the person adjust in real time, and instead you saved it as ammunition for a formal meeting.

The sweet spot for behavioral feedback is typically within 24 to 48 hours. Long enough that you can gather your thoughts and check your own emotional state. Short enough that the event is still fresh and actionable. If you’re angry, wait until you’re not. Feedback delivered in anger is just data corruption with extra steps.

The Architecture of a Good Feedback Conversation

Let’s get tactical. Here’s a structure that actually works, tested across more messy team dynamics than I care to count.

1. Set the context without drama. Don’t schedule a “serious talk” with a cryptic calendar invite. That’s the professional equivalent of “we need to talk” from a partner. Just say: “Hey, I wanted to chat about something I noticed in the last sprint. Got 15 minutes?”

2. Lead with the observation, not the conclusion. “I noticed that in the last three code reviews, your comments were focused exclusively on formatting issues. I didn’t see any feedback on the logic or architecture choices.” This is a fact. It’s not an opinion. It’s not a judgment. It’s a camera recording.

3. Describe the impact on the team or the work. “The effect is that some design decisions that could have been caught early made it into the codebase, and we’re now refactoring them under deadline pressure. I think you have the experience to catch those things, so I’m wondering what’s getting in the way.”

4. Ask a genuine question and shut up. The silence after you ask “What’s your perspective?” is the most important part of this whole protocol. You have to actually listen. Not prepare your rebuttal. Not wait for your turn to talk again. Listen. The other person might have context you’re missing. They might be burned out. They might be dealing with something outside work that’s draining their cognitive capacity. Or they might just disagree with your assessment, and that’s data too.

5. Agree on the next behavior, not the next feeling. “So going forward, can we try having you focus on one architectural comment per review, even if it’s just a question?” This is a lightweight contract. It’s testable. Next sprint, you can both look back and see if it happened.

This structure works because it respects the other person’s agency. You’re not issuing a command. You’re presenting data, describing its system-level effects, and inviting collaboration on a fix. That’s engineering. That’s debugging a process, not a person.

When the Feedback Recipient Is the System, Not the Individual

Sometimes the behavior you need to change isn’t one person’s fault. It’s a team norm that nobody has named. Everyone knows that the standups run 25 minutes and are mostly status theater. Everyone knows that the on-call rotation is a sacrificial ritual. But nobody says it out loud, because saying it out loud feels like accusing your friends.

In these cases, the feedback needs to be directed at the system, not at any single individual. “I’ve observed that our retrospectives tend to produce action items that nobody follows up on. The impact is that we keep having the same conversations each sprint. I’d like to propose that we assign a single owner to each action item and review them at the start of the next retro.”

This is still feedback. It’s still pointing at a gap between expected and actual behavior. But by framing it as a systemic issue, you avoid triggering anyone’s personal defenses, and you position yourself as someone who’s trying to improve the team, not tear down a teammate.

FAQ: Engineers Asking the Hard Questions

What if the person gets defensive no matter how carefully I phrase it?

Defensiveness is often a fear response, not a rational argument. If someone’s amygdala is running the show, no amount of logical framing will land. In that case, pause the content of the feedback and address the dynamic directly: “It seems like this is hitting a nerve, and I don’t want to push if this isn’t a good time. Can we take a break and come back to it?” That gives them a chance to regulate. If they still can’t engage, the trust cache is probably already corrupted, and you have a deeper problem that a single feedback conversation won’t fix.

How do I give feedback to someone more senior than me?

Same protocol, different power dynamic. Lead with curiosity: “I noticed X, and I wanted to understand your thinking because it seemed different from what I expected.” You’re not telling them they’re wrong. You’re seeking to understand their model. If there’s a real problem, the data will speak for itself. And if you’re wrong, you learn something. Either way, you’ve demonstrated that you’re paying attention and thinking about the system, not just your own tickets.

Can written feedback via Slack or email ever work?

Written feedback strips out tone, facial expression, and the ability to read the room in real time. It’s a high-latency, low-bandwidth channel for an interaction that requires nuance. Avoid it for anything that has emotional weight. The only exception is when you’re following up on a verbal conversation to document what was agreed. A quick “Thanks for the chat earlier. Just to confirm, we’re going to try X going forward” can be useful. But leading with text is like deploying straight to prod without a staging environment. You might get lucky, but the blast radius is huge when it fails.

What if I’m the one receiving feedback badly? How do I get better?

First, recognize that the physiological reaction—racing heart, tight chest, urge to explain—is just your body doing its thing. It’s not a signal that you’re under attack. Breathe. Remind yourself that feedback is data about how your actions are landing, not a verdict on your worth as a human. Ask clarifying questions that are actually clarifying, not disguised counterarguments: “Can you give me a specific example?” “What would success look like in that situation?” If you need time to process, say so: “I want to think about this before I respond. Can I come back to you tomorrow?” That’s not weakness. That’s professional maturity.

Giving feedback that sticks is a technical skill. It’s about designing a message that can survive the noisy, emotionally lossy channel between two human brains. It’s about respecting the person enough to give them a spec they can actually build against. And it’s about understanding that the real product you’re all shipping isn’t just code—it’s the culture that writes the code. If you treat that culture like a legacy monolith that nobody dares to refactor, you’ll get exactly the bugs you deserve.

Now go break something, fix it, and talk to your teammates like the capable adults they are.

Let’s not pretend. Most engineering feedback is either a sugar-coated nothingburger that leaves the recipient confused, or a blunt-force trauma session that sends them straight to LinkedIn’s “Open to Work” feature. The real technical problem in this industry isn’t Kubernetes scaling or microservice latency—it’s that we’re collectively terrible at telling each other when we’re screwing up. I’ve watched brilliant teams implode not because of bad code, but because of bad conversations. So here’s my unfiltered take on how to give feedback that actually changes behavior, without making people hate you—or themselves.

The Feedback Paradox: Why We’re So Bad at This

Here’s an uncomfortable observation: most engineers would rather refactor a 10,000-line legacy monolith than give a teammate honest feedback. We’re trained to optimize systems, not relationships. So when someone’s behavior is the bug, we either ignore it until the whole team crashes, or we deploy a patch so aggressive it breaks everything else. Trust evaporates. Resentment festers. The person either doesn’t change, or changes in all the wrong ways—getting defensive, withdrawn, or passive-aggressive.

The root cause is embarrassingly simple: we treat feedback as a judgment instead of a tool. A judgment says “you are bad.” A tool says “here’s a lever that might work better.” That distinction isn’t just semantic—it’s the entire game. Frame feedback as a tool, and you’re collaborating on a problem. Frame it as a judgment, and you’re just being an asshole with extra steps.

Step One: Diagnose Before You Prescribe

Picture a junior dev who pushes a commit that breaks the build. The lazy feedback is “Don’t break the build, idiot.” The slightly-better-but-still-lazy version is “Please run tests locally before pushing.” Both miss the point entirely. Why did they skip the tests? Were they rushed? Did they not know how to run them? Is the test suite so glacially slow that everyone bypasses it and they just got unlucky today? If you don’t understand the system that produced the behavior, your feedback is just noise.

Before you open your mouth, do five minutes of debugging. Ask yourself: What’s the actual gap? Is it knowledge, motivation, environment, or clarity? If the person doesn’t know the expectation, that’s a clarity problem—and it’s probably your fault for not documenting it. If they know but lack the skill, that’s a knowledge gap—and screaming won’t magically upload information into their brain. If they have the skill but don’t do it, that’s a motivation or environment issue. Maybe the test suite takes 45 minutes and their manager is breathing down their neck. Your feedback needs to target the root cause, not the symptom.

The “Three Whys” Drill

Steal this from Toyota. When you spot a behavior you want to change, ask “why” three times. Not to the person—to yourself, first. “Why did they skip code review?” Because they were in a hurry. “Why were they in a hurry?” Because the sprint deadline was a fantasy. “Why was the deadline a fantasy?” Because the product manager promised a feature without talking to engineering. Now your feedback isn’t about the individual—it’s about the process that set them up to fail. That’s a conversation people can actually engage with instead of just surviving.

Step Two: Make It About the Work, Not the Worker

This is where most feedback jumps the shark. The moment you say “You are disorganized,” you’ve made it personal. Their brain flips into fight-or-flight mode. They’re not listening to your solution; they’re constructing a legal defense. Instead, anchor everything to observable behavior and its impact. “The last three pull requests had missing test coverage, which caused two production rollbacks.” That’s a fact. It’s not about their character—it’s about a pattern with consequences.

Engineers respect data. Give them data. “I’ve noticed that in standups, you often interrupt others. Yesterday it happened three times, and two people stopped sharing updates afterward.” Now you’re not saying “you’re rude.” You’re saying “here’s a specific action, here’s the frequency, here’s the effect on the team.” That’s a bug report, not a personal attack. And we’re actually good at bug reports.

Drop the Sandwich Method

The “compliment-criticism-compliment” sandwich is a lie. People see through it instantly. It trains them to dread praise because they know a “but” is lurking around the corner. It also dilutes the message. If you need to pad criticism with fake niceties, you’re not confident in your feedback—or you’re trying to manipulate emotions instead of solving a problem. Just be direct. “Hey, I want to talk about the code review delays. This is important because it’s blocking the team. Can we figure out what’s getting in the way?” No sugar, no venom. Just clarity.

Step Three: Co-Create the Solution

Feedback without a path forward is just complaining. The goal isn’t to make someone feel bad—it’s to change a behavior. And behavior change sticks when the person owns the solution. So after you’ve laid out the observation and impact, shut up and ask: “What do you think is going on here?” or “How would you approach fixing this?”

This does two things. First, it checks your diagnosis. Maybe you missed something. Maybe they’re dealing with a personal crisis, or the tooling is even worse than you thought. Second, it engages their problem-solving brain—the part that actually enjoys debugging. When they design the fix, they’re invested in it. They’re not following orders; they’re improving a system. That’s a completely different psychological state.

If they’re stuck, offer options, not commands. “One thing that’s worked for others is setting a personal reminder to run tests before pushing. Or we could pair on setting up a pre-commit hook. What sounds useful?” You’re a consultant, not a dictator. And frankly, you’ll get better results.

Step Four: Time It Like a Deploy

Timing is everything. Giving feedback when someone is stressed, hungry, or publicly embarrassed is like deploying on a Friday afternoon—you’re begging for an outage. The best feedback happens in private, soon after the event, when both of you are calm. “Soon” means within 24-48 hours. Wait longer, and the details get fuzzy, the emotional charge fades, and it feels like you’ve been nursing a grudge.

Also, ask for permission. Not in a weird, formal way—just a quick “Do you have a few minutes to talk about something I noticed in the sprint review?” This respects their autonomy and lets them brace mentally. If they say no, respect that, but schedule a time. Forcing feedback on someone who’s not ready is a power move, not a help move.

Public Praise, Private Criticism

This rule is ancient for a reason. Criticizing someone in front of the team multiplies the shame by the number of eyeballs. Even if your words are perfect, the context poisons them. Save behavioral feedback for one-on-ones or private chats. Conversely, when someone does something right, say it loudly and in public. That builds a culture where feedback isn’t feared—because most of it is positive and visible.

Step Five: Follow Up or It Never Happened

One conversation rarely changes a habit. People need reinforcement, reminders, and sometimes course corrections. A week after the feedback, circle back. “How’s the test-running habit going? Anything still getting in the way?” This shows you’re not just dumping criticism and running—you’re actually invested in their improvement. It also gives you a chance to catch regressions early, before they become patterns again.

If they’ve improved, acknowledge it specifically. “I noticed your last three PRs had full test coverage and were on time. That’s made a real difference for the team’s velocity.” This isn’t flattery—it’s closing the feedback loop. It tells their brain “this new behavior is noticed and valued,” which is how habits actually stick.

When Feedback Goes Wrong: The Recovery Protocol

Sometimes you’ll screw up. You’ll be too harsh, too vague, or too public. The person will shut down or push back. Don’t double down. Don’t apologize so profusely that it becomes about your guilt. Just reset. “I think I delivered that poorly. Can we rewind and try again? What I actually care about is X, and I want to make sure we’re on the same side.”

This works because it models the very behavior you’re asking for: owning mistakes and fixing them. If you can’t take feedback on your feedback, you have no business giving it.

Building a Feedback Culture That Doesn’t Suck

Individual skill matters, but the environment matters more. If your team’s culture punishes honesty, even the best feedback techniques will fail. Here’s how to shift the culture from fragile to anti-fragile—where feedback actually makes the team stronger.

Normalize “Feedback” as a Neutral Word

In most teams, the word “feedback” triggers anxiety because it’s code for “you’re in trouble.” Change that. Start using the word for positive observations too. “Feedback on your presentation: the architecture diagram was crystal clear.” Make it routine. In one-on-ones, ask “What feedback do you have for me?” and take it seriously. When leaders model receiving feedback without defensiveness, it gives everyone else permission.

Kill the “Nice” Culture

“Nice” is the enemy of good. Teams that prioritize being nice over being honest end up with secret resentments and passive-aggressive code reviews. I’m not saying be a jerk—I’m saying be kind. Kindness is telling someone the hard truth because you respect them enough to believe they can handle it. Niceness is lying to them to avoid an awkward moment. Choose kind.

Make Feedback a Process, Not an Event

Annual performance reviews are where feedback goes to die. By the time you’re discussing something that happened in March, it’s November, and everyone has forgotten the context. Feedback should be continuous, lightweight, and tied to specific work. Code reviews, sprint retros, and project post-mortems are natural feedback mechanisms—use them. A retro where everyone says “what went well” and “what could be better” is feedback training wheels. It depersonalizes the conversation and makes improvement a team sport.

FAQ: Your Feedback Fears, Addressed

What if the person gets defensive no matter how I phrase it?

Defensiveness is often a sign of fear—fear of being judged, fear of consequences, or fear of looking incompetent. If it happens consistently, the problem might be the relationship, not the feedback. Have you built enough trust? Do they believe you’re on their side? If not, pause the feedback and work on the foundation. Ask them about their goals, their frustrations, what support they need. Once they see you as an ally, feedback becomes collaboration. If they’re still defensive, it might be a them-problem—but you can only control your half.

How do I give feedback to someone more senior or powerful?

Same principles, but with extra care on timing and framing. Senior people often get less honest feedback because everyone’s intimidated. That’s a disservice. Frame it as “I want to help you be even more effective” rather than “you’re doing something wrong.” Use data and impact on the team or project—senior folks usually care about those. And if they react poorly, that tells you something important about whether you want to keep working there.

Is it ever okay to give feedback in writing instead of face-to-face?

Yes, if it’s thoughtful and private. Some people process written feedback better because it gives them time to absorb without the pressure of an immediate reaction. But written feedback can also feel cold or permanent. If you go this route, be extra clear about your intent, use specific examples, and always offer to discuss in person afterward. Never give critical feedback in a public channel—that’s just a digital public shaming.

What if the behavior doesn’t change after multiple feedback sessions?

Then it’s no longer a feedback problem—it’s a performance or fit problem. Document the pattern, the feedback you’ve given, the support you’ve offered, and the lack of change. At that point, you’re not having a coaching conversation; you’re having a consequences conversation. “We’ve talked about this three times. The impact on the team is X. If this doesn’t change by Y date, we’ll need to move to Z.” It’s not personal—it’s protecting the team. And honestly, if someone can’t or won’t change a behavior that’s hurting the team, they might need a different team.

Feedback isn’t a soft skill. It’s a core engineering practice—like testing, like monitoring, like incident response. You don’t skip tests because they might hurt someone’s feelings. You don’t ignore a production bug because it’s awkward to mention. Treat behavioral issues with the same rigor you’d treat a memory leak. Diagnose, instrument, fix, verify. Do that, and you’ll build a team that doesn’t just ship code—it ships a culture where people actually grow.

Look, I’ve been around long enough to know most software architecture arguments are just theatre. You’ve got the whiteboard warriors sketching perfect hexagons while the rest of us wonder if they’ve ever actually deployed to production. But there’s one thing that separates the adults from the children in engineering, and it’s not your fancy event-sourcing pattern. It’s whether anyone—including you, six months from now—can figure out what the hell you were thinking.

Architecture decisions are social constructs. They’re bets we place with spotty information, and the only real currency is how well we communicate those bets. Without documentation that doesn’t make people want to bang their heads on the desk, your brilliant design is just a ghost haunting the codebase, scaring new hires and pushing senior engineers toward a drinking problem during on-call.

The Architecture Decision Record: Your New Best Friend

I’m not talking about that auto-generated wiki some intern set up three years ago and nobody’s touched since. I’m talking about Architecture Decision Records—ADRs—a practice that’s been around since Michael Nygard wrote about it in 2011. If you haven’t read his original post, stop everything and go find it. I’ll wait.

ADRs are like the medical charts of your system. They lay out the context, the decision, and the fallout. Not the marketing fluff, not the aspirational architecture diagram that looks like a subway map designed by a committee of unicorns. Just the cold truth: “We chose option X because option Y would’ve meant rewriting half the monolith, and Bob was on vacation.” That’s the kind of honesty that saves necks.

Here’s the thing about engineering culture: we’re obsessed with being right, but we’re allergic to being understood. We’ll burn three weeks arguing Kafka versus RabbitMQ, but we won’t spend three hours writing down why we picked one. Then six months later, someone new joins, stares at the mess, and kicks off a Slack thread that replays the entire debate from scratch. That’s not engineering; that’s Groundhog Day with more caffeine.

What an ADR Actually Looks Like

It’s not a novel. It’s not a design doc that tries to predict the next five years of product roadmap. A decent ADR has four parts:

• Title: A short name that doesn’t sound like a marketing bot spat it out. “ADR 001: We’re using PostgreSQL because we’re not insane” works fine.
• Context: What problem were we solving? What constraints were we under? Was the CTO breathing down our necks because he read some blog post about microservices? Write it down.
• Decision: What did we actually choose? Be specific. “We will use a relational database with read replicas” isn’t a decision; it’s a wish. “We will deploy PostgreSQL 14 on AWS RDS with at least two read replicas in us-east-1” is a decision.
• Consequences: What got better? What got worse? Did we trade consistency for availability? Did we make the frontend team cry? Own it.

That’s it. You can slap on a status and a date if you’re feeling fancy, but the core is four sections that force you to think like an adult. I’ve seen teams stick ADRs straight into their repo next to the code, using a simple markdown file. No special tools, no Confluence pages that need a VPN and a prayer to access. Just text files that survive reorgs and tooling migrations.

Why Most Documentation Fails (And It’s Mostly Your Fault)

Let’s be honest: most documentation is written for the wrong crowd. Engineers write docs for themselves, or for some mythical architect who’s going to review the system with a checklist. But the real audience is the poor soul who joins the team in two years, opens the repo, and has zero clue why there’s a Redis cluster that seems to do nothing but cache cat memes.

Documentation fails when it’s too generic. “We follow microservices best practices” isn’t documentation; it’s a LinkedIn post. It fails when it’s too detailed, describing every class and method as if the code itself didn’t exist. And it fails most spectacularly when it’s out of date, because nothing kills trust faster than a diagram showing services that were decomissioned during the Obama administration.

The fix is simple, but it demands a culture shift. You need to treat documentation as part of the architecture process, not an afterthought. When you make a significant decision—say, choosing a message broker or deciding to split a service—writing the ADR is part of the work. It’s not something you do on Friday afternoon when your brain is fried. It’s the thing you do before you start coding, because if you can’t explain the decision clearly, you probably don’t understand it yourself.

The Real Technical Problem Is Ego

Here’s where I get blunt. The biggest barrier to decent architecture documentation is the ego of senior engineers. We’ve all met that person—the one who designs a system in their head, bangs it out in a caffeine-fueled sprint, and then acts annoyed when anyone asks questions. “Read the code,” they say, as if the code is Tolstoy and not a pile of spaghetti held together by hope and a few integration tests.

That attitude is a liability. It creates knowledge silos that turn into bus factors. When that engineer leaves—and they will, probably for a job with better pay and better snacks—they take the architecture with them. The rest of the team is stuck with a system nobody understands, and you start seeing commits that just add comments like “// don’t touch this, it breaks everything.”

Good documentation is an act of professional humility. It says, “I made this decision with the information I had, and I’m writing it down so you can judge me later.” It’s the opposite of job security through obscurity. It’s also the only way to have honest technical discussions. When a decision is written down with its context and consequences, you can argue about the trade-offs instead of arguing about what someone remembers from a meeting six months ago.

From ADRs to Living Documentation

ADRs are just the start. Once you’ve got a habit of writing down decisions, you can build a lightweight documentation system that actually survives contact with reality. The key is to keep it close to the code and make it easy to update. I’ve seen teams use a /docs folder in the repo with a simple index, or a static site generator that pulls from markdown files. The tool doesn’t matter as much as the discipline.

One pattern I like is the “decision log” that’s part of the project’s README or a dedicated page. It lists every ADR with its status—proposed, accepted, superseded—so anyone can see the history of the system’s architecture at a glance. When a decision gets reversed or replaced, you don’t delete the old ADR; you mark it as superseded and link to the new one. That way, you’ve got a trail of how the thinking evolved, not just the final state.

This also helps with onboarding. Instead of handing new engineers a 50-page wiki that was last updated during the Trump administration, you hand them a list of decisions that explain why the system looks the way it does. They can read the ADRs, dig into the code, and actually get the trade-offs without having to corner a senior engineer in the kitchen and beg for context.

When Good Documentation Goes Bad

There’s a dark side to this, and I’ve seen it play out in teams that get too religious about documentation. You know the type: they turn ADRs into a bureaucratic process with templates, review boards, and a requirement that every decision be signed off by an “architecture council” that meets once a month and mostly argues about lunch orders. That’s not documentation; that’s performance art.

Documentation should be lightweight enough that it doesn’t feel like a chore. If writing an ADR takes more time than the decision itself, you’re doing it wrong. The goal is to capture the essence of the decision, not to produce a legal document you could submit as evidence in court. I’ve seen one-page ADRs that are more valuable than 30-page design docs because they actually get read and updated.

Another failure mode is documentation that’s too focused on the “what” and not the “why.” A diagram that shows service A calling service B is useless without context. Why does it call it synchronously? Why not use a queue? What were the latency requirements? The “why” is the part that ages well; the “what” is going to change next sprint anyway.

The Culture Shift Nobody Wants to Talk About

Here’s the uncomfortable truth: if your team doesn’t value documentation, it’s because your engineering culture has a problem. Not a tooling problem, not a process problem—a culture problem. Somewhere along the way, someone decided that writing things down is less important than shipping features, and now you’re paying the price in production incidents and wasted meetings.

Fixing this starts with leadership. If your tech lead or CTO doesn’t write ADRs and doesn’t ask for them, nobody else will. But it also requires a shift in how we evaluate engineering work. Right now, most performance reviews are based on code shipped, bugs fixed, features delivered. Nobody gets promoted for writing documentation that prevents a disaster two years later. That’s a failure of incentives, and it’s why most documentation is a wasteland.

I’ve seen one team experiment with making ADRs part of their definition of done. Before a story is complete, any significant architectural change had to have an ADR written and reviewed. It wasn’t heavy—just a quick check that the decision was documented. At first, people grumbled, but after a few months, it became a habit, and the team’s collective understanding of the system improved hugely. They spent less time in meetings explaining things and more time actually building.

What Happens When You Ignore This

Let me paint you a picture. You’re called into a production incident at 3 a.m. The database is melting, and nobody knows why. You trace the issue to a caching layer that was added two years ago by an engineer who’s now at a startup in Berlin. There’s no documentation, just a commit message that says “added cache.” The config is a mess of magic numbers, and nobody knows what happens if you tweak them. You spend four hours debugging, and by the time you fix it, you’ve lost a year of your life to stress.

That’s not a hypothetical. That’s a Tuesday in most engineering orgs. And it’s entirely preventable if someone had written down why the cache was added, what the eviction policy should be, and what the expected failure modes are. Instead, you’ve got a system held together by tribal knowledge and prayer.

The cost of bad documentation isn’t just the incident itself; it’s the slow erosion of trust in the system. Engineers start adding defensive code because they don’t understand the original intent. They duplicate functionality because they’re scared to modify existing components. The codebase becomes a museum of abandoned decisions, and nobody wants to be the curator.

FAQ: Because You Probably Still Have Excuses

“We’re too busy shipping features to write documentation.”

You’re too busy to save yourself time later? That’s like saying you’re too busy driving to change the oil. Documentation isn’t overhead; it’s an investment that pays off every time you avoid a redundant meeting or a production fire. If you’re constantly in crunch mode, that’s a sign your architecture is already a mess, and documentation is the first step to digging out.

“Our system changes too fast for documentation to keep up.”

Then your documentation is too detailed. Stop trying to document the current state of the code; document the decisions and the principles behind them. Principles don’t change every sprint, even if the implementation does. If your architecture is truly evolving that fast, ADRs for each significant change will actually help you track the evolution instead of losing the thread entirely.

“Nobody reads the documentation anyway.”

Nobody reads it because it’s useless. If your documentation is a graveyard of outdated PDFs and auto-generated nonsense, of course nobody reads it. But if you write ADRs that are concise, honest, and close to the code, people will read them—especially during incidents or onboarding. I’ve seen teams where new hires devour the ADR log because it’s the only thing that actually explains the system. Make it good, and they will come.

“Can’t we just use AI to generate documentation?”

No. Absolutely not. We’re not going there. Documentation is about human judgment and context, not about auto-generating paragraphs from code comments. If you’re relying on a tool to explain your decisions, you’ve already lost the plot.

The Bottom Line

Your architecture decisions are only as good as the documentation around them because architecture is a social activity. It’s about aligning a group of humans around a shared understanding of a system that’s too complex for any one person to hold in their head. Without that shared understanding, you don’t have an architecture; you have a collection of accidents held together by duct tape and hope.

So do yourself a favor. Next time you make a significant decision, write it down. Not in an email, not in a Slack thread that will vanish into the void, but in a file that lives with the code. Make it short, make it honest, and make it something your future self would thank you for. Because when the on-call pager goes off at 3 a.m., you’ll want to know why the hell someone chose that message queue, and you’ll want to know it fast.

Architecture isn’t about being right. It’s about being understood. And that starts with documentation that doesn’t treat your teammates like mind readers.

You’ve seen this scene a thousand times. The room goes dead quiet when the senior architect unveils the new system design. Nods all around. One junior developer opens her mouth, thinks better of it, closes it. The decision gets made in thirty seconds, and everyone walks out knowing it’ll detonate in six months. Nobody says a damn thing. This isn’t harmony. It’s a funeral with free snacks.

I’m Fritz Muller. I’ve spent my career watching engineering teams either hum or implode based on one factor that never makes it onto a slide deck: how they fight. The best teams argue like hell. The worst ones sit in polite, terrified silence. If your team never has a real argument, you aren’t running an engineering organization. You’re running a hostage situation where the captives have agreed to pretend everything’s fine.

The Silence Is the Problem, Not the Loud Voices

Most managers think a quiet team is a productive team. They hear raised voices and immediately reach for the conflict-resolution playbook. Wrong instinct. Silence in an engineering context almost always signals fear, not agreement. When nobody pushes back on a technical decision, it doesn’t mean the decision is solid. It means people have calculated that speaking up costs more than staying quiet.

I once worked with a team that never argued. The lead was a brilliant jerk who’d been there forever, and everyone else was either too junior or too burned out to challenge him. Code reviews were a joke. “LGTM” on pull requests that introduced subtle race conditions. Architecture decisions got made in his head and handed down like stone tablets. The product shipped on time for two years, and then it didn’t. The accumulated technical debt was so massive the whole thing cratered during a routine scaling event. The postmortem was a masterpiece of passive language: “The system exhibited unexpected behavior.” No. The system did exactly what a pile of unexamined assumptions told it to do.

The silence wasn’t just awkward. It was expensive. The company lost millions in downtime and customer trust because nobody felt safe saying, “I think this is a terrible idea.” That’s the real price tag on a conflict-free zone.

Good Arguments Are a Technical Skill

Here’s where people get twitchy. They think I’m advocating for screaming matches and personal attacks. I’m not. I’m talking about the kind of argument rooted in data, trade-offs, and the shared goal of not building garbage. Engineering is a discipline of constraints. There is no perfect solution. Every choice means giving something up. If you’re not arguing about what to give up, you’re not doing engineering. You’re doing coloring-book time with a keyboard.

A healthy technical argument has a few hallmarks. It’s about the work, never the person. It’s specific: “This caching strategy will fail under read-heavy loads because of how we handle cache invalidation” rather than “Your design sucks.” It assumes good intent on both sides. And it ends with a decision, even if that decision is “we need more data.” The goal isn’t to win. The goal is to find the least-bad option and understand exactly why it’s least-bad.

I’ve been in arguments that lasted two hours and ended with the entire team changing direction. Those were the best meetings. Not because I “won” or “lost,” but because the final product was better than what any single person brought to the table. The argument itself was the design process. You can’t replicate that with a document and a comment thread. You need the friction.

The Manager’s Role in Making Arguments Safe

This is where leadership usually faceplants. A manager who shuts down disagreement because it’s “inefficient” or “negative” is actively destroying the team’s ability to do their jobs. Your role isn’t to prevent arguments. It’s to make them productive. That means you model the behavior: admit when you’re wrong, ask genuinely dumb questions, and never punish someone for a well-reasoned objection.

I once had a CTO who would say, in every design review, “Someone tell me why this is stupid.” He meant it. He’d sit there and wait. The first few times, it was excruciating. Then people realized he actually wanted to hear the flaws. The quality of our architecture improved overnight. Not because we hired smarter people, but because we stopped pretending our first ideas were good.

If you’re a manager and your team never argues, you have a problem. It might be you. Do you get defensive when challenged? Do you reward agreement and punish dissent subtly through promotion decisions or meeting dynamics? Do you treat technical debate as a personal attack? Fix that first. The silence isn’t about them. It’s about the environment you’ve created.

When Arguments Go Wrong

Let’s be clear: not all arguments are useful. I’ve seen teams where arguing became performance art. The loudest person wins. Decisions get made based on who can talk longest without breathing. That’s not engineering. That’s a dominance display dressed up as collaboration.

Bad arguments come in a few flavors. The bike-shedding session where everyone debates a trivial detail to dodge the hard problem. The ad hominem fest where technical criticism turns into “you always do this.” The martyr act where someone takes every piece of feedback as a personal wound. These are toxic, and they need to be killed immediately. A good technical lead can spot the difference in seconds: is this about the system or about someone’s ego?

I once watched a senior engineer filibuster a meeting for forty-five minutes because he didn’t want to admit he’d misread a requirement. He argued about edge cases that didn’t exist, questioned the monitoring setup, brought up a completely unrelated outage from three years ago. Everyone knew what was happening. Nobody called it out. The meeting ended with a vague action item and zero progress. That’s the flip side of silence: noise that substitutes for thinking.

Building a Culture That Values Disagreement

You can’t just tell people to argue more. That’s like telling someone to “be spontaneous” on command. You have to build the scaffolding that makes disagreement safe and expected. Start with the rituals. In your design reviews, require at least one person to play the role of skeptic. Rotate the role so it’s not always the same grumpy senior dev. In code reviews, normalize comments that question the approach, not just the syntax. “Why did you choose this pattern?” is a better comment than “Looks good.”

Psychological safety is the buzzword, and it’s a buzzword for a reason. Without it, you get exactly the behavior that kills projects. People need to know that saying “I don’t understand” or “I think we’re wrong” won’t get them labeled as difficult or incompetent. This isn’t about being nice. It’s about being effective. A team that can’t surface problems early is a team that will ship those problems to production.

I’ve seen teams where the quietest person had the most critical insight and never said it until the retrospective, when it was too late. That’s a system failure, not a personal one. The system trained them to stay quiet. Fix the system.

What Silence Costs You

Let’s do the math on silence. When a bad decision goes unchallenged, you don’t just pay for it once. You pay for it in the implementation time, the debugging time, the refactoring time when it inevitably breaks, the on-call pages at 3 a.m., the lost trust from customers, and the morale hit when your best engineers leave because they’re tired of cleaning up preventable messes. The upfront “efficiency” of avoiding a two-hour argument is a lie. You’re just deferring the cost with compound interest.

I worked on a project where the initial database schema was designed by someone who’d never operated a database at scale. Several engineers knew it was wrong. Nobody said anything because the designer was a founder. Eighteen months later, we spent six months and a small fortune migrating to a new schema while the product was live. The postmortem should have been a single sentence: “We were too scared to argue.”

Silence is also a talent killer. The best engineers want to work where their brains matter. If they’re in an environment where they can’t challenge ideas, they’ll leave for one where they can. You’ll be left with the people who are comfortable never rocking the boat. And those people will happily steer the boat into an iceberg while complimenting each other on the smooth sailing.

How to Start Fighting (Productively) Tomorrow

If you’re reading this and realizing your team is a silent disaster, don’t panic. You can fix it. Start small. In your next team meeting, when someone proposes a solution, ask: “What’s the worst thing that could happen if we do this?” Make it a ritual. Don’t let anyone leave until at least one real risk is on the table. It’ll feel forced at first. That’s fine. Rituals feel forced until they become habits.

If you’re an individual contributor, you have more power than you think. The next time you disagree with a decision, say so. Frame it around the work: “I’m worried about this approach because of X. Can we talk through that?” You’ll be terrified the first time. Do it anyway. If you get punished for it, update your resume. That place is doomed, and you don’t want to be there when the music stops.

If you’re a leader, audit your own reactions. The next time someone challenges you, notice your first instinct. Is it to defend? To dismiss? To listen? Your team is watching that instinct. They’re learning from it. If you can’t take a punch to your ideas without flinching, you’re the reason they’re silent.

FAQ

Isn’t arguing just going to slow everything down?

Yes, in the short term. A good argument takes time. But it saves vastly more time than it costs. The alternative is shipping a broken system that takes weeks or months to fix. The question isn’t whether you spend time. It’s whether you spend it up front, when it’s cheap, or later, when it’s spectacularly expensive.

What if someone on the team just can’t handle disagreement without getting personal?

Then you have a performance problem, not a culture problem. Technical debate requires emotional regulation. If someone consistently turns disagreements into personal attacks, they need direct feedback and, if it continues, a different job. One person’s inability to argue professionally can poison an entire team.

How do I know if my team’s silence is a real problem or just everyone being in agreement?

Look at the outcomes. Does your team consistently ship with major bugs that were “obvious in hindsight”? Do postmortems reveal that several people had concerns but didn’t raise them? Do you hear grumbling in one-on-ones that never surfaces in group settings? If yes, the silence is a problem. Genuine agreement comes with specific, enthusiastic reasoning. Silence comes with vague nods.

Can remote teams have productive arguments, or does this only work in person?

Remote teams can absolutely argue well, but it takes more deliberate effort. You need clear norms: cameras on when possible, no multitasking, structured turn-taking so the loudest voice doesn’t dominate the Zoom call. Written async debate in documents can actually be better than real-time because it forces people to articulate their reasoning more clearly. The medium doesn’t matter as much as the safety and the norms.

Here’s the bottom line. Engineering is a team sport played with logic and constraints. If your team can’t argue, you’re not playing the sport. You’re just dressing up in the uniform and hoping nobody notices you’re standing still. The best teams I’ve ever been on were loud, opinionated, and occasionally uncomfortable. They also shipped the best work I’ve ever seen. The worst teams were polite, quiet, and consistently mediocre. Choose your discomfort.

Most engineering meetings unfold like a bad play nobody bought tickets for. First, someone drops a 60-minute block on your calendar called “Sync on Q3 deliverables” and you feel a little piece of your soul detach. Then twelve people shuffle into a room or a Zoom grid, and the opening seven minutes vanish while Dave hunts for the right dongle. Finally, you stumble out knowing less than when you walked in, and your IDE glares at you from the screen like a disappointed parent. I’m Fritz Muller. I’ve clocked fifteen years watching smart engineers perfect the thousand-yard stare under flickering fluorescent lights. The meeting isn’t the villain here—lousy process is. Let’s talk about how to run one that doesn’t treat builders like furniture.

The Default Meeting Is a Bug, Not a Feature

Let’s not kid ourselves: most calendar invites are panic attacks dressed up in Outlook. Somebody realizes they need three decisions, has no clue who owns them, and invites half the engineering org as a comfort blanket. You end up with a roomful of expensive brains silently toting up the context-switching tax. Yank a developer into a 30-minute meeting and you’ve probably incinerated a full hour of flow. The research on programmer productivity backs this up, and it’s not subtle. If your meeting lacks a clear outcome, you’re not collaborating—you’re just burning payroll in real time.

The fix starts before you even touch the scheduling tool. Frame your agenda as a list of decisions to be made, not “topics for discussion.” Can’t name at least two concrete outcomes? Delete the invite. Fire off a pre-read—three bullet points, tops—so nobody walks in cold. And for God’s sake, use the “required” versus “optional” attendee fields like an adult. Every optional body you drag into that room is another person silently composing your villain origin story.

Who Actually Needs to Be There?

I’ve witnessed standups with eighteen people. Eighteen. That’s not a standup; it’s a hostage situation with sticky notes. Here’s the rule: if someone’s presence won’t directly change the outcome, don’t invite them. Send them the notes instead. Decision-makers and the people doing the actual work are mandatory. Everyone else is a tourist, and tourists derail conversations with context-free questions because they don’t know the terrain. Stop letting tourists buy tickets to your meetings.

There’s a special circle of developer hell reserved for people who invite engineers “just to listen.” No. Just no. If you need an engineer to listen, record the damn thing and send a timestamped summary. Their time is better spent wrangling a compiler, and you know it. Deep down, you absolutely know it.

Start Like You Mean It

First five minutes: name the decision that needs to be made, the constraints, and who owns the final call. This isn’t a TED talk; spare us the throat-clearing. If you’re facilitating, your job is benevolent dictator, not everyone’s buddy. Cut off the ramblers. If someone’s been muted or silent for ten minutes, they’ve either checked out or they’re fixing a prod bug under the table—pull them in or cut them loose.

Timebox everything. I don’t care if the CTO is waxing poetic about horizontal scaling; when the clock hits zero, you move. Use a visible timer. It’s not rude—it’s basic respect. The engineer in the corner with a deadline in three hours will mentally send you a thank-you note.

The Agenda That Actually Works

Here’s my template. Take it, tweak it, pretend you invented it:

• 0:00-0:05: Decision to be made and why it matters. No context firehose, just the stakes.
• 0:05-0:15: Options and trade-offs. No solutioning yet—just “here’s what we could do and what it would cost.”
• 0:15-0:25: Discussion. Only people with skin in the game speak. If you’re repeating yourself, sit down.
• 0:25-0:30: Decision and owner. Who does what by when. That’s the whole enchilada.

If you can’t wrap the decision in 30 minutes, the issue isn’t the clock—it’s that you skimped on the pre-work. Slice it into smaller decisions or book a follow-up for the one dangling thread. Never, ever let a meeting slosh past its end time because “we’re so close.” Close isn’t a decision. Close is a vibe, and vibes don’t merge pull requests.

Kill the Status Update Meeting

Status updates should be async. Full stop. If your team needs a weekly circle where everyone recites a miniature diary entry, you’ve got a management failure, not a collaboration gap. Use a shared doc, a Slack channel, or a project board. If someone hits a blocker, they can yank the relevant people into a 15-minute huddle. The standup isn’t group therapy; it’s a coordination checkpoint, and it should die the instant it becomes a verbal status report.

I once parachuted into a startup that hosted a two-hour, all-hands engineering meeting every Monday. Two hours. Fifty engineers. The first hour was project leads reading slides that had already landed in everyone’s inbox the night before. The second hour was “Q&A,” which was really just two architects relitigating a database schema from a project that got shelved six months prior. We axed the meeting, shoved updates into a Loom channel, and handed engineers back something like 100 collective hours a week. Productivity ticked up, sure, but the real win was that people stopped looking like they needed a sick day by Tuesday morning.

Remote Meetings Are Worse (Unless You Fix Them)

Remote meetings take every bad habit and put it on a highlight reel. The “quick question” that inhales ten minutes. The person on mute who’s clearly unloading a dishwasher. The screen share that accidentally flashes seventeen open tabs, including a Reddit thread on lawn care. Rule one: cameras on for decision meetings, optional for info dumps. Yes, it’s tiring, but non-verbal cues matter when you’re hashing out an architecture call. Rule two: use a digital whiteboard or a shared doc everyone can see and scribble on. If I can’t see what you’re pointing at, I just assume you’re ad-libbing.

And please, for the love of decent audio, test your rig beforehand. The first five minutes of a remote meeting should not be a symphony of “Can you hear me?” and “My VPN is throwing a tantrum.” If you’re running the thing, join five minutes early and drop the agenda link in chat. If you’re an attendee, do the same or brace for my side-eye through the screen.

Decisions Over Discussion: The Engineer’s Creed

Engineers are trained to chase problems down rabbit holes, which means they’ll happily optimize a meeting into a black hole of edge-case spelunking. Your job as facilitator is to stop that. When someone says, “Well, what about if the user is on a 3G connection, in a tunnel, during a solar flare?”, you say, “That’s an edge case. We’ll document it and deal with it if it actually happens. Next.” The goal is a decision, not a mathematical proof.

This is where engineering culture gnaws its own leg off. We worship thoroughness, so we let meetings morph into deep-dives that scratch the curiosity of two senior engineers while the other six people question their life choices. Save the deep-dive for a design review. A decision meeting is for picking a path and assigning the work. If you need a deep-dive, schedule it separately and only invite the folks who’ll touch the code.

When to Actually Have a Meeting

Run this checklist before you even think about sending the invite:

• Does this need real-time, back-and-forth talk? If it’s one-way info, send an email.
• Is the decision so urgent and tangled that async would cause real delay? If not, use a doc.
• Do you need simultaneous input from several people? If it’s just two people, hop on a call—don’t drag a room into it.
• Can you state the desired outcome in one plain sentence? If no, you’re not ready.

Nine times out of ten, the meeting could’ve been a well-structured document. That tenth time, it should clock in at 30 minutes or less, with a hard stop and a named owner. If you can’t manage that, you’re not facilitating a meeting; you’re performing a ritual, and rituals don’t ship software.

The Follow-Up That Prevents the Next Meeting

A meeting without a written summary is just a chat that evaporates by lunch. Within an hour, fire off an email or Slack message that covers: the decision that got made, who’s doing what by when, and any open questions you tabled. No more than five sentences. If you can’t boil it down to five sentences, the meeting was a mess, and you need to tighten it up next time.

That summary also doubles as your accountability receipt. I’ve watched teams re-litigate the same decision across three consecutive meetings because nobody bothered to write it down. That’s not collaboration; that’s a memory leak. Write it down, pin it somewhere visible, and if someone tries to reopen it without fresh data, you can politely point to the record and suggest they go write some code instead.

FAQ: Meeting Survival for Engineers

Q: What if my manager insists on daily standups that are just status reports?
A: Pitch a one-week trial of async standups in a Slack channel. Show them the reclaimed time. If they push back, ask what information the live standup delivers that a written update can’t. Often, the standup is a security blanket for anxious managers. Gently suggest a 15-minute, twice-weekly sync instead and use the freed-up time to actually build things. If that fails, accept that some hills aren’t worth dying on and use the standup block to mentally refactor your codebase.

Q: How do I handle the person who always derails meetings with tangents?
A: Deploy a parking lot. At the top of the meeting, point to a spot—physical or digital—where off-topic ideas go to wait. When someone veers off, say, “Good point. Let’s toss it in the parking lot and circle back if we have time.” You won’t have time, and they’ll eventually get the hint. If they don’t, pull them aside privately. “Your tangents are burning about $400 in productivity per meeting. Mind saving the deep musings for the design doc?”

Q: Is it ever okay to code during a meeting?
A: Only if the meeting is genuinely irrelevant to you and your attendance was forced. But honestly, it’s better to decline the invite or ask if you can drop. If you’re coding with one ear half-open, you’re neither coding well nor listening well—you’re just putting on a multitasking puppet show. Be straight with your manager: “I can’t add value here, and I’ve got a critical bug breathing down my neck. Can I catch the notes afterward?” A decent manager will say yes. A bad one will make you sit there, and in that case, you have my blessing to quietly noodle on that neglected side project.

Q: What’s the ideal meeting size for a decision meeting?
A: Jeff Bezos had the two-pizza rule—if two pizzas can’t feed the group, it’s too big. I’d tighten that further: five people max for a decision meeting. One decision-maker, one facilitator, and up to three domain experts. Any more and you’re in town-hall territory, where the loudest voice wins and the quietest engineer mentally checks out. If you need wider input, gather it beforehand and bring the synthesis to the table.

Meetings aren’t the enemy of engineering culture. Unstructured, bloated, ego-driven meetings are. Treat a meeting like you’d treat a code review: be precise, be brutal about waste, and always, always demand a clear output. Your colleagues’ time is the priciest resource your company has. Spend it like you would a capped AWS budget—with an actual plan and a hard limit. Now go delete something from your calendar and write some code.

There’s a specific flavor of despair that hits when your manager slides a spreadsheet across the table and says, “Your commit count is down this quarter.” You stare at the numbers, and somewhere in the back of your mind, a tiny Fritz is screaming into the void. Because you know what those numbers don’t show: the three weeks you spent untangling a race condition that crashed production only on Tuesdays, the architecture overhaul that deleted 4,000 lines of spaghetti, or the ten hours you sat with a junior dev explaining why their O(n²) loop was a war crime against CPUs.

Engineering culture has a measurement problem. And no, I’m not talking about fuzzy stuff like “happiness” or “collaborative spirit”—I wouldn’t touch those words with a ten-foot patch cable. I’m talking about the hard, supposedly objective metrics that make managers feel like they’re running a factory floor instead of a team of humans who type for a living. Lines of code. Number of commits. Velocity points. These numbers aren’t just wrong; they’re actively destructive. They turn smart people into point-chasing hamsters and make codebases worse than a PHP script from 2003.

What Happens When You Measure the Wrong Thing

Let’s get one thing straight: measuring output isn’t inherently evil. Goodhart’s law gets quoted so often in tech circles it’s basically a meme, but people still ignore it. “When a measure becomes a target, it ceases to be a good measure.” You’d think after decades of software pileups, we’d have learned. But nope. Every few years, some exec reads a book on manufacturing efficiency and decides engineers are just assembly-line workers with nicer chairs.

Incentivize lines of code, and you’ll get lines of code. Lots of them. Devs will inflate boilerplate, dodge abstractions, copy-paste entire functions, and soon your codebase looks like it was typed by a drunk Markov chain. Incentivize commit count, and you’ll get micro-commits. “Fixed typo.” “Added comment.” “Removed whitespace.” The git history becomes a landfill of noise that makes git blame useless and git bisect a form of self-harm.

I once worked on a team with a brilliant senior dev who realized his quarterly review depended on commit count. Within two weeks, he’d automated a process that split every logical change into six separate commits. His numbers went through the roof. The codebase? No better. The team? Not shipping faster. But the spreadsheet looked fantastic. That’s not engineering. That’s performance art for middle management.

The Invisible Work That Actually Matters

Most engineering work is invisible to simple metrics. Debugging a memory leak that only manifests when the moon is in retrograde? Zero lines added—maybe even negative lines if you delete the offending garbage. Mentoring a junior engineer who’s about to quit because they feel incompetent? Zero commits. Designing a database schema that won’t explode in two years? Maybe a few SQL files, but the real work happened in your head, on a whiteboard, or in a heated Slack thread at 11 PM.

These activities are the difference between a team that survives and one that thrives. But they don’t show up in a burndown chart. They don’t generate green squares on GitHub. So they get devalued. Over time, the engineers who do this invisible work either stop doing it—why bother?—or they leave. What’s left is a crew of optimization bots who churn out code like it’s a bodily function, and a codebase that rots from the inside out.

Commits as a Status Symbol

Look at any developer’s GitHub contribution graph. Those little green squares are basically a Fitbit for typing. People game the hell out of them. They’ll push meaningless commits on weekends to keep a streak alive. They’ll fork repos and commit README changes just to paint the lawn green. I’ve seen people write scripts that auto-commit a timestamp to a private repo every day. That’s not productivity. That’s a cry for help.

The commit-count culture sets up a perverse incentive. It rewards activity over impact. A developer who spends a week researching a library, reading docs, and then writes a ten-line integration that solves the problem perfectly? That’s a “lazy” week on the spreadsheet. Another dev who spends that same week writing 2,000 lines of their own half-baked implementation that breaks in production? That’s a hero. The spreadsheet says so.

I remember a project where we had to migrate a massive legacy database. The engineer who did the work spent two weeks analyzing schemas, writing migration scripts, testing rollback procedures, and documenting everything. Total lines added: maybe 200. Total commits: 12. Meanwhile, a dev on a parallel track wrote a feature with 3,000 lines of React components and 50 commits. Guess who got the promotion? The React cowboy. The migration engineer saved the company from a data-loss catastrophe, but nobody saw it because the work didn’t “show up.”

Why Velocity Points Are Also Nonsense

Agile teams love story points. They’re supposed to be abstract, relative estimates of effort. But give it three sprints, and some product owner is dividing points by hours and asking why velocity dropped from 30 to 28. Same disease, different skin. Points become a currency, and engineers start negotiating them like they’re haggling at a bazaar. “This ticket is at least an 8.” “Can’t we split it into three 3s?” Congratulations, you’ve turned software development into a game of Fibonacci poker.

The real crime is that velocity gets compared across teams. Team A has a velocity of 50, Team B has 30. Therefore, Team A is “faster.” No, Team A just inflates their estimates. Or they’re working on simpler tasks. Or they’ve got a senior dev who can crank out boilerplate at lightning speed. Velocity is a team-internal calibration tool. The moment you expose it to sunlight, it turns into a vampire and starts sucking the honesty out of planning.

The Deeper Problem: Engineering Culture as a System Failure

Here’s where I get blunt. The obsession with measuring engineers by lines of code or commits isn’t just a management mistake. It’s a symptom of a broken engineering culture that doesn’t understand itself. We’ve let people who can’t read code define what “good” code looks like. We’ve let project managers who’ve never debugged a null pointer set the standards for technical work. And we’ve accepted it because, honestly, it’s easier to nod along than to explain why a ten-line refactor took three days.

Engineering isn’t manufacturing. You can’t count widgets because the widgets don’t exist. Software is abstract, creative, and often counterintuitive. The best code is the code you don’t write. The best engineer is often the one who deletes the most. But deletion is a negative metric. It makes the line-count go down. It makes the commit history look like a retreat. In a culture that worships addition, subtraction is a sin. And that’s why we have codebases with 17 layers of abstraction for a CRUD app.

This culture problem feeds itself. Managers hire for “output” because that’s how they’re evaluated. Engineers optimize for those metrics because that’s how they get paid. The codebase gets worse, which creates more work, which requires more hiring, which means more managers who only understand output. It’s a doom loop. And the only way out is to blow up the metrics entirely and start measuring what actually matters: outcomes, not output.

What Good Measurement Might Look Like

I’m not naive. I know organizations need some way to evaluate performance. So here’s a radical idea: measure the things that correlate with actual success. Did the feature ship on time and not break? Did the bug fix stay fixed? Did the team’s technical decisions reduce future maintenance burden? These are hard to quantify, sure. But so is code quality, and we don’t throw up our hands and stop trying.

One angle is to track customer outcomes. Did the work lead to faster load times? Fewer support tickets? Higher conversion? Engineers should be tied to the business impact of their work, not the volume of their typing. Another is peer review. Let the people who actually understand the work evaluate it. If three senior engineers say someone is doing great work, that’s worth more than a thousand green squares. It’s messy, subjective, and human. Exactly like engineering.

Some teams treat “negative line count” as a badge of honor. A refactor that removes 10,000 lines of dead code gets celebrated. A commit that simplifies a complex module gets a shout-out in standup. This flips the incentive: instead of rewarding addition, you reward clarity and simplicity. It takes a strong technical lead to push this culture, but when it works, it’s something to see.

What This Does to Engineers’ Brains

Let’s talk about the psychological toll. When you tell a creative, problem-solving human that their value is a number on a dashboard, something breaks. They start optimizing for the number instead of the problem. They stop thinking about architecture because architecture doesn’t commit. They stop refactoring because refactoring looks like standing still. They stop caring, because the system clearly doesn’t care about them.

I’ve seen brilliant engineers burn out because their deep work was invisible. They’d spend months designing a system that would save years of effort, and their reward was a mediocre review because their “velocity” was low. Meanwhile, the person who shipped a half-baked feature got a bonus. The message is clear: don’t do the hard stuff. Ship fast, break things, let someone else clean up. And then we wonder why technical debt is a trillion-dollar problem.

This is how you lose your best people. Not through layoffs or bad pay, but through a slow erosion of purpose. When engineers feel like assembly-line workers, they start acting like assembly-line workers. They clock in, crank out code, and clock out. Innovation dies. Ownership dies. And the company slowly becomes a place where mediocrity is the only survival strategy.

The Manager’s Dilemma

I have some sympathy for managers caught in this mess. They’re often under pressure from above to “prove” their team’s productivity. They don’t have time to read every pull request. Metrics feel like a lifeline—a way to show executives that the engineering department isn’t just a black hole of salary dollars. But the answer isn’t bad metrics. The answer is better storytelling. A good engineering manager can translate technical work into business terms without resorting to line counts. “We reduced page load time by 40%,” “We eliminated a class of bugs that caused 200 support tickets a month,” “We shipped feature X which drove a 5% increase in signups.” That’s what executives understand. Not commit graphs.

If you’re a manager and you’re reading this, here’s your homework: spend a week not looking at any metric. Instead, talk to your engineers. Ask what they did. Ask what was hard. Ask what they learned. Then go tell that story upward. It’s harder than copying a number from Jira, but it’s the actual job. Metrics are a crutch, and the crutch is breaking your team’s legs.

FAQ

Why do companies keep using lines of code if it’s so bad?

Because it’s easy. Counting lines of code or commits takes zero effort—you can pull it from a tool in seconds. Understanding the nuance of engineering work takes time, technical knowledge, and trust. Many organizations lack all three. There’s also an inertia problem: these metrics have been around for decades, and replacing them requires cultural change that most companies are too lazy to attempt. The irony is that the effort saved on measurement gets spent tenfold on fixing the bad code those metrics incentivized.

What’s a better way to measure individual engineer performance?

Focus on outcomes and impact, not output. Look at what the engineer’s work actually achieved: did it solve a user problem, reduce technical debt, improve system reliability, or help the team move faster? Peer feedback from other engineers is often more accurate than any metric because it captures the invisible work. Some teams use a lightweight regular review where engineers write a short summary of their impact, which gets calibrated in a group discussion. It’s not perfect, but it’s better than pretending commit counts mean anything.

Do story points in Agile have the same problem?

Absolutely. Story points were designed to be a relative estimation tool for a team to plan their own work. The moment they’re used to compare teams or evaluate individuals, they turn toxic. Engineers start gaming estimates, inflating point values, or arguing over whether a task is a 5 or an 8 instead of just doing the work. The core issue is the same as with lines of code: a metric meant for internal calibration gets hijacked as a performance indicator, and everyone loses.

What if my manager insists on using these metrics for my review?

You have a few options, none of them fun. First, try to educate: share articles, data, or anecdotes about how these metrics backfire. Frame it as helping the team, not criticizing the manager. If that fails, document your actual impact in a “brag doc”—a running list of your contributions, especially the invisible ones. Bring that to your review and make the case that your work matters even if the numbers don’t show it. If the organization still won’t listen, that’s a strong signal that the culture is broken, and you might want to polish your resume. Life’s too short to be a hamster on a wheel.

The bottom line: measuring engineers by lines of code or commits is like judging a chef by how many pots they dirty. It misses the point entirely, rewards the wrong behavior, and makes everyone miserable. The fix isn’t a new tool or a better formula. It’s a shift in how we think about engineering work—from factory output to creative problem-solving. Until that shift happens, we’ll keep getting the software we deserve.