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.

Let’s not pretend otherwise: most meetings hit a software engineer like kryptonite. You shuffle into a room, nursing your third coffee, and watch perfectly good minutes of your life vanish into a black hole of vague status updates and circular arguments. Your IDE sits cold. Your pull request gathers dust. Your soul quietly forks itself onto a darker branch.

I’m Fritz Muller. I poke at engineering culture because—come on—the people problem is the real technical problem. We’ll obsess over shaving three milliseconds off a database query but shrug while a meeting hemorrhages 30 minutes per attendee like it’s a rounding error. This isn’t one of those productivity sermons. Think of it as a survival guide for anyone who has ever stared at a calendar invite and thought, “I could’ve shipped a feature during this standup.”

The Meeting Sickness: Why Your Calendar Is a Bug

Here’s the grimy little secret: bad meetings aren’t just irritating—they’re a system crash. When a meeting has no clear owner, no real agenda, and no decision point, it turns into what I call “status theater.” Everyone recites what they did. Nobody asks why any of it matters. Three hours later, the actual work happens in a Slack thread. The bill? Multiply one directionless 45-minute gathering by eight senior engineers, and you’ve torched roughly $1,200 of company cash to produce zero working code. That’s not a meeting. That’s arson with a calendar invite.

The root cause is embarrassingly simple: we treat meetings as the default coordination tool, not the last resort. Engineering culture worships building, but we’ve constructed a process where talking about building swallows more time than the building itself. Fixing it demands the same rigor you’d throw at a memory leak—find the source, patch it, stop the bleeding.

A Pre-Flight Checklist: Don’t Schedule Unless You Mean It

Before your finger hits “send” on that invite, run this quick diagnostic. If you can’t answer these three questions, delete the meeting and go write some code:

• What single decision must this meeting produce? If the answer is “discuss” or “share updates,” you don’t need a meeting. You need a document. Write an RFC. Record a Loom. Use async communication like a grown-up.
• Who actually needs to be there? Inviting eight people because you’re scared of bruising egos isn’t collaboration—it’s hostage-taking. Two to five people is the sweet spot. Anyone beyond that is a spectator, and spectators don’t commit code.
• Can this be settled in 15 minutes or less? Default to 15-minute slots. Parkinson’s law is brutally real: work swells to fill whatever container you give it. A 30-minute block will magically soak up 30 minutes of rambling. Respect the clock.

Running the Thing: Structure That Forces Closure

Okay, you’ve determined a meeting is necessary. Now don’t wreck it. The gap between a decent meeting and a soul-crushing one is structure—specifically, the kind of structure that makes it impossible to leave without a concrete outcome.

1. Write an Agenda That Reads Like a Git Commit Message

Mushy agendas breed mushy meetings. Instead of “Discuss Q3 roadmap,” try “Decide whether we ship the API refactor in September or October.” The agenda should be a crisp, specific statement of what you’ll decide. Send it at least 24 hours ahead, and attach any pre-read materials. If folks show up unprepared, end the meeting. I mean it. The second time you do it, they’ll read the damn doc.

2. Assign a DRI (Directly Responsible Individual)

Every meeting needs one person who owns the outcome. This person isn’t the “facilitator” in some squishy sense—they’re the one who writes the decision log, assigns action items, and nags until things are done. Without a DRI, accountability evaporates, and you’ll replay the same meeting next week. The DRI also gets the power to kill tangents. When Bob starts waxing poetic about his weekend homelab project, the DRI says, “Bob, we’re here to pick a caching strategy. Save that for the after-party.”

3. Start with a Decision, Not a Monologue

Most meetings burn the first ten minutes on context-setting that half the room already knows. Instead, open with the proposed decision. “I think we should use Redis for session storage because it cuts our database load by 40%. Here’s the data. Does anyone see a reason not to do this?” This flips the default from rambling to action. If nobody objects, you’ve just finished a meeting in under five minutes. Congratulations—go back to coding.

4. Use a Timer Like It’s a Standup

Set a visible timer. When it hits zero, the meeting ends, even if you’re mid-sentence. This isn’t rudeness; it’s engineering. We respect constraints. If you can’t resolve something in the timebox, the DRI schedules a follow-up with a narrower scope. But more often, the timer squeezes out the fluff and forces a call. You’d be stunned how fast consensus shows up when the alternative is another meeting.

The Async Fallback: When Meetings Are Just Laziness

Here’s a slightly unhinged idea: maybe you don’t need a meeting at all. Engineering teams have more async tools than ever—GitHub discussions, Notion docs, Slack channels. Yet we still gravitate toward synchronous time because it feels like work. It’s not. It’s a security blanket for people who don’t want to write a clear proposal.

Try this: for any meeting that’s purely informational, cancel it and send a written update instead. Require people to comment or react within 24 hours. If a real discussion explodes, then—and only then—schedule a focused session with the two or three people who actually disagree. The rest of the team just got an hour of their life back.

The Uncomfortable Truth: Culture Is the Bottleneck

You can implement every trick in this article and still flop if your company culture rewards performative busyness over shipping. If a manager judges productivity by calendar density, you’re cooked. If people are terrified of declining meetings, your calendar becomes a permission structure for interruption. Fixing meetings means fixing the incentives that spawn them.

Start small. Declare one day a week “meeting-free.” Guard it like a production outage. When someone tries to schedule over it, push back with the same ferocity you’d use against feature creep. Over time, people will notice that the team’s output spikes on that day, and the pattern spreads. Culture shifts when results shift.

Remember: every minute in a meeting is a minute you’re not building, debugging, or refactoring. The best meeting is the one you never had.

FAQ: What People Always Ask Me About Meetings

How do I decline a meeting without looking like a jerk?

Decline with a clear reason and an alternative. “I can’t make this because I need to ship the payment module by Friday, but I’ve added my thoughts on the doc. Ping me if there’s a specific blocker.” This shows you’re engaged, not evasive. If the organizer pushes back, ask if the meeting is more important than the Friday deadline. Watch them squirm.

What if my boss is the one scheduling terrible meetings?

This is a design problem, not an insubordination problem. Propose a pilot: “What if we move status updates to a 5-minute Slack thread for two weeks and see if anything breaks?” Frame it as an experiment with measurable outcomes. Bosses like data. If the experiment works, you’ve just reprogrammed your manager. If it fails, you’ve lost nothing—but it rarely fails.

Should standups be meetings or async check-ins?

Standups are the original sin of meeting culture. Unless your team is co-located and actively collaborating on a single incident, do them async. A Slack bot that asks “What did you do yesterday? What are you doing today? Any blockers?” does 90% of the job without stealing 15 minutes from 10 people. Reserve synchronous standups for when a blocker needs immediate unblocking—and then only pull in the relevant people.

Can a meeting actually be productive?

Yes, but it requires discipline. Productive meetings have one decision, a DRI, a tight timebox, and zero spectators. They feel more like a code review than a chat—specific, pointed, and over quickly. If you walk out without a clear action item, the meeting failed. No exceptions.

Now close this tab, open your IDE, and write something that ships.

Let’s get one thing straight. When engineers bitch about technical debt, they’re usually pointing at the wrong villain. They’ll moan about a gnarly codebase, a legacy monolith held together with dental floss and regret, or that one microservice nobody understands but everyone’s too scared to kill. They’ll blame the code. The code is just the evidence, not the crime scene. The real rot? It’s how your company makes decisions—or more often, dodges them entirely.

I’ve seen teams spend six months refactoring a payment pipeline, only for the business to pivot the entire product two weeks later because a VP got spooked by a competitor’s press release. That’s not a code problem. That’s an organizational nervous breakdown disguised as a Jira epic. Technical debt is the interest you pay on bad organizational behavior. You want cleaner code? Fix the damn org chart first.

The Code Is Just the Receipt

Walk into any company with a “legacy modernization” initiative and you’ll find the same sad story. Engineers are burning weekends to decouple services, while product managers pile on features like they’re stocking a bunker for the apocalypse. The real debt isn’t the tangled class hierarchy—it’s the product roadmap that has more plot twists than a telenovela. When leadership rewards shipping over everything else, the codebase becomes a landfill. But the landfill wasn’t created by the garbage truck; it was created by the city council that refused to approve a recycling plant.

I once consulted for a startup where the CTO kept screaming about “technical excellence” while the CEO was selling features that didn’t exist yet. The engineering team was forced to build a “minimum viable product” that was really a “maximum viable lie.” Every shortcut they took—hardcoded values, skipped tests, database tables named temp_final_v2_backup_real—came straight from a sales promise that had no business being made. The code wasn’t the problem. The problem was a leadership team that treated engineering like a wish-granting factory.

Organizational debt shows up in all the places you’re too polite to look. It’s the “empowered” product manager who can’t tell a database from a spreadsheet but still dictates the API contract. It’s the hiring freeze that forces your best people to maintain garbage instead of building something new. It’s the quarterly planning ritual where everyone commits to impossible deadlines because the person who asks for more time gets labeled “not a team player.” That’s not technical debt. That’s a cultural bankruptcy proceeding.

Your Priorities Are a Lie

If you want to see organizational debt in action, look at how your company handles “tech debt sprints.” You know the drill: the team begs for a sprint to clean up the mess, management reluctantly agrees, and then three days in, a “high-priority” bug or a CEO’s pet feature swoops in and steals half the capacity. The message is clear: cleaning up is a luxury, not a requirement. You can’t pay down debt with a currency that leadership treats as Monopoly money.

Real technical debt reduction requires a level of organizational maturity that most companies can’t stomach. It means saying no to a feature that’s 80% done because the underlying architecture is 100% broken. It means letting a team spend three months on infrastructure without a user-facing deliverable, and defending that decision when the board asks why the burn rate is so high. Most orgs can’t do that because their internal reward systems are built on short-term dopamine hits from shipped features, not long-term system health.

I’ve seen a team propose a beautifully scoped rewrite of a critical but decaying service. They had the data, the diagrams, the risk assessment—the whole nine yards. Management nodded along, then asked, “But can you also build the new reporting dashboard this quarter?” They wanted the debt paid off and a new car in the driveway, all on the same paycheck. When the team predictably failed to do both, the rewrite got blamed for “taking too long.” The organizational debt simply migrated from the roadmap to the post-mortem document.

The Blame-Shifting Merry-Go-Round

When a system collapses under its own weight, the post-incident review is a masterclass in organizational deflection. Engineering blames the unstable API from the third-party vendor. Product blames engineering for not writing enough tests. Leadership blames everyone for not raising the issue sooner, even though they were the ones who cut the monitoring budget six months ago. The code itself is just the cadaver on the table; the cause of death was a thousand tiny compromises made in conference rooms where no engineer was invited.

This blame-shifting is why “technical debt” as a term is so dangerous. It localizes the problem to the technology, which means the solution is always “more engineering effort.” But more engineering effort can’t fix a VP who demands a “simple” feature that requires a complete database migration. It can’t fix a sales team that promises custom integrations without talking to a single developer. It can’t fix a CEO who reads a blog post about microservices and decides the monolith must be split by next quarter. These aren’t technical failures; they’re failures of communication, trust, and basic operational sanity.

How to Diagnose Organizational Debt

Before you schedule another “refactoring sprint” that will inevitably get hijacked, ask some uncomfortable questions. Does your company have a technical strategy that’s actually documented, or is it just the CTO’s collection of Medium bookmarks? Are engineers involved in the product roadmap before commitments are made to customers? When was the last time someone was rewarded—publicly—for killing a project that was a bad idea? If you’re answering no to these, your technical debt is just a symptom of a deeper planning disease.

Another dead giveaway: the “hero culture.” If your team’s most celebrated engineers are the ones who stay up until 2 a.m. fixing production fires, you’re not running an engineering organization; you’re running a firefighting theater. The real heroes should be the people who make the fires unnecessary. But in orgs drowning in organizational debt, those people are invisible because prevention doesn’t make for a good all-hands slide. You’re rewarding the symptoms and ignoring the cure.

The Real Fix Is Boring and Political

Paying down organizational debt isn’t a technical challenge; it’s a power struggle. You need to change how decisions are made, which means you need to change who holds the decision-making power. That’s why most technical debt initiatives fail—they’re run by engineers who don’t have the political capital to tell a product director that their baby feature is ugly and needs to wait. The fix involves uncomfortable conversations about scope, timelines, and the actual cost of “quick wins.”

Start small. Pick one area where organizational debt is clearly harming technical quality and make it visible in a language the business understands: money and risk. Don’t say, “We need to refactor the authentication module.” Say, “Our current auth system has a 15% chance of a security breach that could cost us $2 million in fines and churn.” Suddenly, the abstract “technical debt” becomes a concrete business liability. That’s how you get attention in a room full of people who think Kubernetes is a fancy coffee brand.

Ultimately, the health of your codebase is a reflection of the health of your organization. A codebase full of hacks and shortcuts is the product of a company that values speed over sustainability, heroics over planning, and optics over outcomes. You can’t refactor your way out of a broken culture. You have to fix the way you work, not just the work you produce. Until then, you’re just moving deck chairs on the Titanic while the captain orders another iceberg-speed record attempt.

FAQ

What’s an example of organizational debt that looks like technical debt?

A classic case is a codebase littered with “temporary” workarounds that become permanent. The code looks terrible, sure, but the root cause is a product team that never allocates time for proper implementation because the roadmap is a fantasy document. The debt isn’t the hacky code—it’s the planning process that treats engineering capacity as infinite and interchangeable.

How can I convince my manager that organizational debt is the real issue?

Stop using technical jargon. Translate every instance of “technical debt” into its business consequence: slower time-to-market, increased outage risk, higher onboarding costs for new engineers. Frame the problem as a decision-making failure rather than a coding failure. If your manager still doesn’t get it, ask them why the team’s velocity is dropping despite more hiring—chances are, the organizational debt is the silent killer.

Is all technical debt actually organizational debt?

Not all, but most. There’s genuine technical debt that comes from evolving requirements or imperfect knowledge at the time of implementation. But in my experience, the stuff that really hurts—the systemic, festering kind—almost always traces back to how the organization prioritizes, funds, and communicates. Clean code won’t save you from a dysfunctional leadership team.

Let’s not dance around it: the industry has a serious title problem, and we’re all pretending not to notice. Somewhere along the way, “senior engineer” stopped meaning “the person you call when the server room is literally on fire” and started meaning “the person who managed not to get fired for a decade.” The gap between an engineer with ten years of experience and an actual senior engineer? It’s not a gap. It’s a canyon. The only bridge across it is built by people who treat engineering culture as the hardest technical problem they’ll ever face.

I’ve spent my career watching people collect years of service like they’re rare Pokémon cards. Meanwhile, the real seniors are quietly deleting whole code modules and rewriting them before lunch. Hiring managers have built entire interview processes around this confusion—and they still get it wrong half the time. Here’s the blunt truth.

Experience Is Not Expertise, and We Need to Stop Pretending It Is

Ten years of experience looks great on a resume. Ten years of doing the same CRUD app maintenance with zero architectural impact? That’s just a warm body with a pulse. I’ve met people with two decades in the game who can’t explain why a database index matters. And I’ve met five-year engineers who can redesign a deployment pipeline with their eyes closed while explaining the trade-offs to a product manager who thinks “technical debt” is a line item on their credit card.

The raw material is the same: time. But time is just a container. You can fill it with deliberate practice—breaking systems on purpose, reading postmortems from other companies, mentoring juniors until you realize you didn’t understand something as well as you thought. Or you can fill it with Jira ticket churn. The second one is far more common, and it smells like stagnant water.

A senior engineer is not a time-based achievement badge. It’s a set of behaviors. It’s the person who, when handed a half-baked requirement about “adding a notification system,” starts asking about failure modes, throughput, and whether the existing event bus will buckle under the load. The ten-year engineer who never grew up just opens their IDE and starts typing code they’ve typed a hundred times before. Both have the same number of birthdays in the industry. Only one earns their paycheck.

The Real Senior Engineer Sees the System, Not Just the Ticket

This is where the rubber hits the road. A regular engineer—even a competent one—sees a unit of work. They implement the feature, write the tests, handle the edge cases, and ship it. That’s fine. That’s what we pay them for. But a senior engineer sees the system. They see the second-order effects before the code even hits staging. They’re already thinking about how the new feature messes with the caching layer, what monitoring dashboards need updating, and which team will get paged at 3 a.m. if latency spikes.

I once watched a ten-year veteran ship a beautifully coded authentication module. It broke production for three hours because it assumed a network call would always resolve within 500 milliseconds. Elegant, well-documented, and completely wrong for the environment. A senior engineer would have asked, “what happens if this dependency is slow?” before writing a single line. That’s not a knowledge gap. It’s a thinking gap.

The ten-year engineer collects patterns. The senior engineer understands when to break them. Both have read the same design patterns book, but only one knows that a singleton in a distributed system is just a bottleneck wearing a fancy hat.

The Communication Cliff: Why Your Ten-Year Engineer Can’t Talk to Humans

Engineering culture pretends soft skills are a nice-to-have, like free snacks in the breakroom. In reality, communication is the single most leveraged skill a senior engineer owns. I’ve seen entire teams waste months building the wrong thing because the lead couldn’t articulate why a simpler approach would fail under load. They had the technical vision. They just couldn’t translate it into words a non-technical stakeholder could act on.

A senior engineer can walk into a meeting with the CTO, the product manager, and a terrified junior developer, and tailor the same technical reality to three different audiences without dumbing it down. They don’t use jargon to sound smart; they use clarity to be effective. The ten-year engineer in the same meeting either stays silent, mutters about “race conditions” while everyone’s eyes glaze over, or—worse—says “yes” to a timeline they know is impossible because they’re afraid of conflict.

This isn’t about being a people-pleaser. It’s about understanding that software gets built by humans, funded by humans, and used by humans. If you can’t navigate the human layer, your technical brilliance is locked in a soundproof box. I’ve fired contractors who were 10x coders because their inability to communicate caused more damage than their code fixed. That’s not a trade-off a real business can afford.

Mentoring Is Not a Side Quest

Litmus test: when a junior engineer on your team screws up, what’s your first reaction? If it’s annoyance and a quick fix you do yourself, you’re not senior. If it’s “okay, let’s pair on this and figure out where the mental model broke,” you’re on the right track. Senior engineers raise the entire team’s baseline. They don’t hoard knowledge like a dragon guarding gold. They distribute it like a network protocol, with redundancy and error correction.

The ten-year engineer often becomes the “hero”—the only person who understands a critical system, staying late to fix things, creating a bus factor of one. They think this makes them indispensable. A senior engineer knows that being indispensable to a system’s survival means you’ve failed to design a system that can survive without you. They document, they teach, they make themselves replaceable. That’s what actual leadership looks like, and it’s terrifying to people who built their identity on being the smartest person in the room.

Why Companies Keep Promoting the Wrong People

The industry’s obsession with tenure-based promotion is a self-inflicted wound. We’ve built career ladders that reward not rocking the boat, staying in your lane, and accumulating years of service. The engineer who questions everything—the one who points out that the new microservice architecture is just a distributed monolith with extra steps—gets labeled “difficult.” The engineer who quietly churns through tickets and never challenges assumptions gets labeled “reliable.”

Guess which one gets the promotion in a broken culture? The quiet one. And then the company wonders why their senior engineers can’t lead a complex migration or mentor a team through a crisis. You promoted for comfort, not competence. You got exactly what you rewarded.

Real seniority almost always comes with a healthy disrespect for authority when that authority is technically wrong. It’s not about being a jerk. It’s about having the conviction to say “this will fail, and here’s the data” even when everyone in the room wants to hear “we can ship this by Friday.” That takes courage no number of years automatically grants.

So How Do You Actually Become a Senior Engineer?

Stop counting years. Start counting scars. The best seniors I know have a personal collection of outages they caused, systems they misdesigned, and decisions they regret. They didn’t just survive those failures. They ripped every ounce of learning from them and changed their behavior permanently. They also learned to say “I don’t know” without flinching, which is—ironically—the fastest way to get to the right answer.

If you want to bridge the gap, do this: own a system end-to-end until you understand every integration point deeply enough to draw it from memory. Volunteer for the on-call rotation and actually fix the root causes instead of just restarting the service. Write a design document and invite ruthless feedback from people smarter than you. Teach someone else to do your job so well that you can move on to harder problems.

And please, for the love of readable code, understand the business you’re building for. A senior engineer knows how their work connects to revenue, user retention, or whatever metric keeps the lights on. If you think technical decisions are made in a vacuum, you’re still operating at the ten-year mark—no matter what your email signature says.

FAQ

Can someone with five years of experience be a senior engineer?

Absolutely. Seniority is a function of impact, scope, and behavior, not calendar years. I’ve worked with engineers who hit a senior level in half a decade because they deliberately hunted down hard problems and learned from every failure. The title should reflect the work you do, not the time you’ve served.

Why do some engineers never become senior despite years of work?

Usually, it’s a mix of environment and mindset. If you’re in a company that rewards ticket-churning over architectural thinking, you’ll stagnate. But the deeper issue is often an unwillingness to step outside the comfort zone of writing code. Senior roles demand uncomfortable things like dealing with ambiguity, having hard conversations, and admitting you were wrong publicly. Some people just don’t want to do that work.

Is the “senior” title just a way for companies to underpay people with a fancy name?

Sometimes, and that’s a real problem. Companies will slap a “senior” label on a role to avoid paying a lead or staff-level salary while expecting the same output. That’s why you should evaluate a role based on the actual responsibilities and the team’s engineering maturity, not just the title. A senior engineer in a high-functioning team often operates at a higher level than a “tech lead” in a dumpster fire.

How do I convince my manager I’m ready for a senior role?

Don’t talk about your tenure. Talk about your impact. Show them the systems you’ve improved, the incidents you’ve prevented through better design, the junior engineers you’ve made more effective. If your manager only cares about years of service, you might need a new manager. The conversation should be about the scope you’re already handling, not a promise of future performance.

I’ve watched too many solid engineers walk into a new job like it’s a honeymoon suite and walk out three months later looking like they’ve been through a trash compactor. The codebase was fine. The tech stack was fine. The team, on paper, was fine. But the culture? That was a slow-burning tire fire they didn’t smell until the smoke was in their lungs.

We treat engineering culture like it’s soft stuff. HR fluff. But a broken culture will wreck your ability to ship working software faster than a Kubernetes misconfiguration. It’s the real technical problem. So let’s get blunt. I’ll walk you through the exact red flags to hunt for during an interview loop, before you sign anything that locks you into a daily standup from hell.

The Interview Itself Is the First Commit Log

You cannot ask, “Hey, is your culture toxic?” because nobody will say yes. They’ll hand you a slide deck about pizza Fridays and psychological safety. You need to read what the interview process does, not what the job description says.

The All-Day Gauntlet of Unpaid Labor

If they ask you to build a fully functional microservice as a “take-home project” that will take twenty hours, they’re not testing your skills. They’re testing how much disrespect you’ll swallow before you’ve even gotten a badge. A legit shop gives a bounded, time-boxed problem that respects your weekend. A toxic shop treats your personal time like a free staging environment. Run a quick calculation: if the project’s scope exceeds what a salaried developer would do in a normal sprint day, you’re being harvested, not evaluated.

Interviewers Who Clearly Hate Each Other

Watch the panel dynamics. Do they interrupt each other? Roll their eyes when a colleague speaks? Do they contradict the company values poster on the wall in real time? I once sat in an interview where the CTO and the senior architect started a passive-aggressive argument about monorepos while I was mid-sentence answering a totally unrelated question. That wasn’t a culture of “healthy debate.” That was a team that had bled resentment into every Slack channel and couldn’t even hide it for forty-five minutes. If they can’t fake professionalism for a candidate, imagine them during an outage.

The Evasive Answer Tango

Ask direct questions. “How do you handle on-call incidents?” “What was the last production outage you had, and what changed afterwards?” A healthy team will tell you the story. They’ll be a little embarrassed but detailed. A toxic team will give you a word salad. “We have a blameless culture so we prefer not to dwell on specifics.” Translation: We have a blame-full culture and we’ve been legally advised to shut up. If you hear more jargon than a corporate earnings call, your bullshit detector should be screaming.

Language That Reveals a Broken Compiler

Words are cheap, but the specific phrases a company uses are dead giveaways. Pay attention to the gap between what they say and what a functioning engineering org actually does.

“Work Hard, Play Hard”

This one means “work hard, and then work slightly less hard at a mandatory happy hour where you’re still judged for not being a culture fit.” It’s a euphemism for no boundaries. Real engineering cultures don’t need slogans about how hard they grind. The code quality, the test coverage, the deployment frequency—those are the receipts. A team that’s proud of its output doesn’t lead with how late the Slack notifications buzz.

“We Move Fast and Break Things”

If you hear this unironically in 2024, you’re dealing with a team that hasn’t learned a single lesson in a decade. Moving fast without breaking things is the entire point of modern software delivery. This phrase is often code for “we skip code review when the PM is stressed, and then we spend every Friday unfucking the database.” Ask them about their rollback strategy. If they laugh nervously, you have your answer.

“Family”

I’m going to be direct: a company is not a family. A family doesn’t fire you in a Zoom call when the quarterly numbers dip. A family doesn’t put you on a performance improvement plan because you took parental leave. When a company calls itself a family, they’re usually trying to guilt you into emotional overtime. A professional team uses the word team. They offer respect and clear expectations, not a dysfunctional Thanksgiving dinner dynamic where the CTO is the passive-aggressive uncle.

Structural Red Flags in the Codebase of the Company

You can often get a read on the engineering culture by probing the edges of how they work, not just the tech stack.

The Hero-Driven Development Cycle

Ask: “Who knows the most about the authentication system?” If they point to a single person—“Oh, that’s all Dave, he’s a wizard, he’s been here forever”—you’re looking at a bus factor of one. That’s not a wizard. That’s a single point of failure who has likely built a kingdom of unmaintainable shell scripts to guarantee job security. A toxic culture enables this because management loves the myth of the 10x developer who saves the day. A functional culture treats heroism as a process failure and documents the hell out of everything so Dave can go on vacation without the pager going off.

Promotion Paths Paved with PowerPoint

Dig into how engineers get promoted. If the answer revolves around launching features and visible impact, but nobody mentions reducing tech debt, improving test runtimes, or mentoring juniors, you’re looking at a feature factory. That culture rewards the loudest person in the room, not the person who stopped the database from keeling over at 3 a.m. by quietly refactoring the connection pool. You’ll end up in a team where the core infrastructure rots while everyone scrambles to ship the CEO’s pet project.

The Meeting Parasite Load

Ask a simple question: “How many recurring meetings does a typical engineer have per week?” If the number is above ten, the company is paying for expensive furniture. You’re not going to write code. You’re going to attend status syncs about status syncs. This is a classic sign of a culture that values the appearance of work over work itself. The meetings exist so managers can justify their existence by “aligning” things that were already aligned.

Questions That Make Them Sweat

You need to flip the interview. Stop performing and start diagnosing. Here are the questions I would ask in the final round to get a real signal.

1. “Tell me about a time someone broke production and what the next day looked like.” Listen for whether the person who caused the outage was supported or shamed. Listen for whether a root cause analysis happened or whether a new “policy” was just emailed out in all caps.

2. “When’s the last time you deleted code and celebrated?” An engineering team that never removes dead features or deprecated endpoints is drowning in complexity. A team that celebrates deletion understands that engineering is about managing entropy. If they look at you like you have three heads, they’ve never pruned a branch in their lives.

3. “How does the team decide what not to build?” The ability to say no is the most important technical skill. If the answer is “we build whatever the product team puts in the roadmap,” engineers are just assembly-line workers. A healthy culture has engineers in the room when priorities are set, pushing back with data. A toxic one has developers who mutter “this is stupid” while typing git push.

What a Healthy Culture Actually Smells Like

So you don’t think I’m just a cynic, here’s the flip side. Good cultures aren’t perfect, but they don’t hide.

You’ll hear engineers disagree openly and then grab coffee afterwards. You’ll see pull request comments that are tough on the code but respectful to the author. You’ll notice that meetings start with a clear purpose and end with a decision, not a “let’s circle back.” The on-call rotation will have a sane escalation policy and a budget for fixing the things that caused the pages. People will use their vacation days and not post about #hustle from the beach.

The difference between a toxic culture and a productive one isn’t a mystery. It’s just whether the company treats engineers as creative problem solvers or as interchangeable cogs in a Jira assembly line. Your job in the interview is to figure out which one you’re walking into.

Frequently Asked Questions

What’s the single biggest red flag in an engineering interview?

Disrespect for your time. If they reschedule last-minute without a real apology, keep you waiting twenty minutes in a lobby without an update, or give you a take-home assignment that’s clearly actual product work, the pattern is already set. They’re telling you exactly how they’ll treat you when you’re an employee with less bargaining power.

Can a toxic engineering culture be fixed from the inside?

Rarely by a new hire. Culture change requires a leadership team that sees the problem and is willing to lose some “high performers” who are actually just bullies. As a new engineer, you don’t have the political capital to change that. You can try if you’re joining as a VP or Director, but as an individual contributor, you’re more likely to burn out trying to fix a broken system than to actually fix it.

How do I evaluate culture in a remote interview?

It’s harder, but not impossible. Ask to see a sprint retro board or a post-incident review document. The artifacts of how they communicate asynchronously are more telling than a live video call. Also, ask for a short chat with a potential peer without the manager in the room. If the company refuses, that’s your answer.

Is a “fast-paced” environment always a red flag?

Not if it’s paired with strong boundaries. Fast-paced can mean the team ships daily and gets quick feedback, which is great. The red flag is when “fast-paced” means “we set arbitrary deadlines and then blame engineers for not meeting them.” Ask about how deadlines are set. If engineers are part of the estimation process and there’s a track record of adjusting scope instead of demanding overtime, you’re in a good fast place. If not, you’re in a burnout factory.

The next time you’re in an interview, don’t just try to impress them. Interrogate the system. The worst bug you’ll ever debug is a company that’s rotting from the inside, and no amount of free snacks can fix that.