Author: Hilda Holland (page 5 of 11)

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.

Let’s stop kidding ourselves. Most standups are just status reports wearing an Agile hat—a trench coat, maybe a fake mustache. We stand in a circle, or huddle in a video grid of half-frozen faces, and recite task lists nobody actually asked for. The scrum master nods along like a dashboard tracking CPU load. The product manager types furiously, probably tallying who said “blocker” three times. And the engineers? We check out the second someone starts describing a Jira ticket number like it’s a war story.

The Ritual That Ate Itself

Standups started with a decent idea: sync the team, surface real problems, keep things moving. But somewhere between the first daily and the thousandth, they mutated into a bureaucratic checkpoint. I’ve watched teams burn fifteen minutes detailing yesterday’s work, today’s plan, and what’s in their way—while the actual work stalls because nobody wants to say the uncomfortable thing out loud. Standups became a theater of productivity, where the performance matters more than the outcome.

Here’s the core problem: when standups are status reports, they serve managers, not teams. Information flows upward, not sideways. I don’t need to know that Dave refactored the authentication module unless it breaks something I’m building. And Dave definitely doesn’t need my ten-minute monologue about debugging a CSS grid issue. We’re not updating a Gantt chart. We’re supposed to be collaborating. But collaboration needs vulnerability, not bullet points.

When “What Did You Do Yesterday?” Becomes a Weapon

I’ve seen engineers prep for standups like they’re defending a thesis. They craft narratives that make their work sound impressive, hide the messy parts, and avoid admitting they spent three hours fighting a YAML indentation error. This isn’t their fault. The format punishes honesty. If you say “I struggled with something dumb,” the room goes quiet. The product manager starts recalculating deadlines. The tech lead files a mental note about your competence. So you learn to say “made progress on” instead of “banged my head against.”

This turns standups into a subtle interrogation. Status-report standups create a culture where visibility trumps value. People optimize for sounding busy rather than being effective. They break tasks into smaller pieces just to have something to report. I once worked with a developer who would deliberately save a finished pull request for the morning so he could announce it at standup. The dopamine hit of acknowledgement was real. The team’s throughput? Not so much.

The worst part is how these standups erode psychological safety. When every day is a mini performance review, nobody admits they’re stuck until it’s too late. Blockers become confessions. And the most valuable conversations—the ones where someone says “I have no idea what I’m doing”—never happen in the circle. They happen in Slack DMs afterward, when the cameras are off.

The Real Engineering Problem Is the Social Contract

Engineering culture treats standups as a technical process when they’re actually a social ritual. We obsess over the format: should we go left to right? Alphabetical? By ticket status? None of that matters if the underlying agreement is broken. The social contract of a standup should be: “We’re here to unblock each other and align on the most important thing.” Instead, the contract is: “We’re here to prove we’re working.”

Signs Your Standup Is a Status Report in Disguise

You can spot the sickness easily. If your standup has any of these symptoms, it’s already dead:

• People talk to the scrum master or manager, not to each other.
• Updates are detailed enough to fill a timesheet.
• Nobody interrupts with “wait, can we pair on that?”
• Side conversations about actual work happen only after the standup ends.
• Quiet engineers say “no blockers” every day because it’s safe.

What’s funny—and by funny I mean infuriating—is that we know this. Every retrospective, someone mumbles that standups feel like a waste. Then we tweak the format: fifteen minutes max! Walking standups! Async standups in Slack! But we don’t change the fundamental purpose. It’s like optimizing a function that returns the wrong value. The bottleneck isn’t the ceremony; it’s the expectation baked into it.

Async Standups: The Coward’s Escape

Some teams flee to asynchronous standups, posting updates in a Slack channel. I get the appeal. No scheduling, no awkward silences, no pressure to perform in real time. But here’s the ugly truth: async standups are just status reports with extra steps. You’re still broadcasting what you did to an audience that mostly doesn’t care. The difference is that now there’s a paper trail. Managers can scroll back and compare Tuesday’s output to Wednesday’s. It’s a surveillance tool dressed as flexibility.

Async standups also kill the one thing that could save synchronous ones: the spontaneous interaction. When someone says “I’m wrestling with the API rate limit,” another engineer can jump in with “oh, I fixed that last sprint, let’s talk after.” That moment can’t happen in a text thread because nobody reads those threads. They skim, they react with an emoji, they move on. You’ve replaced a flawed human interaction with a flawless data entry system.

What Actually Works (No, Really)

I’m not saying kill all standups. I’m saying kill the status-report version. The alternative is a standup that focuses on coordination, not accounting. Here’s what that looks like in practice:

Walk the Board, Not the People

Forget “what did you do yesterday?” Start from the rightmost column of your board—the work closest to done—and ask: “What’s blocking this from shipping?” Then move left. This shifts attention from individuals to flow. It’s immediately obvious if something is stuck because nobody’s touching it. And it stops people from narrating their personal Jira diary.

Make Blockers Emotional, Not Administrative

A real blocker isn’t “waiting for Dave to review my PR.” That’s a coordination delay. A real blocker is “I think our caching strategy is fundamentally broken and I’m afraid to touch it.” Encourage that language. If your team can’t say “I’m scared” or “I’m confused” in a standup, you don’t have a standup problem—you have a trust problem. Fix that first.

Kill the Round-Robin

Not everyone needs to speak. If two engineers are pairing on a feature, one update covers both. If someone’s work hasn’t changed since yesterday, they say “same as yesterday, no new blockers.” That’s five seconds. The goal is to leave the standup with a clear picture of where the project is stuck, not where everyone’s hours went.

Use the 80/20 Rule for Time

Spend 20% of the standup on status and 80% on the one or two items that need immediate coordination. If that means the standup ends in seven minutes, great. If it means three engineers stay behind to debug a deployment issue while everyone else leaves, even better. The standup is a catalyst, not a container.

The Culture Fix Nobody Wants to Admit

Here’s the part where I sound like a grumpy engineering coach: standups are broken because your management culture is broken. If managers demand daily visibility into individual output, standups will always be status reports. You can rename them, restructure them, hold them in VR—it won’t matter. The root cause is a lack of trust. Managers don’t trust engineers to be working. Engineers don’t trust managers to understand the work. And standups become the battleground where that distrust plays out.

The fix isn’t a new agile framework. It’s a hard conversation: “We’re going to stop reporting status to each other and start coordinating work. If you need to know what I did yesterday, look at the commit log.” Some managers will twitch at this. That’s fine. Twitching is a sign of life.

FAQ: Because You’ll Ask These Anyway

“But my team is remote. Don’t we need standups for connection?”

Connection comes from working together on hard problems, not from hearing each other’s to-do lists. If you want connection, schedule a weekly coffee chat or a no-work-allowed hangout. Using standups for social bonding is like using a fire extinguisher for a pillow fight. Wrong tool, messy outcome.

“What if the team likes status-report standups?”

Ask them if they like the standups or the structure. Often, people mistake routine for value. Try an experiment: cancel standups for a week and replace them with a fifteen-minute coordination slot focused only on blockers. Then retro it. Most teams discover they were clinging to a habit, not a help.

“How do I convince my manager to let go of daily status?”

Stop framing it as “let go.” Frame it as “replace with something more effective.” Offer a two-week trial where you replace standup status with a shared dashboard or an end-of-day summary bot. Show that the information still flows, just without the ritual overhead. If the manager resists, you’ve learned something important about their need for control—and that’s a different problem entirely.

“Aren’t you just describing a different kind of standup?”

Yes. I’m describing a standup that does what it was supposed to do: align the team on the work, not on the workers. If that sounds radical, you’ve been in too many bad standups. The ceremony isn’t sacred. The outcome is.

So here’s my plea: the next time you’re in a standup and someone starts reciting ticket numbers like a grocery list, stop them. Gently, maybe. Ask: “Is there something we can help with, or is this just an update?” If it’s just an update, skip it. The team’s collective brainpower is too expensive to waste on verbal Jira exports. Let’s treat engineering culture as the real technical problem—and debug the hell out of it.

The Real Bug Is in the Room, Not the Repository

I’ve been at this long enough to know that most engineering trainwrecks don’t start with a null pointer or a memory leak. They start with a vague nod in standup, a ticket that reads like a ransom note, and a product manager who thinks “just make it work” counts as a technical spec. By the time anyone opens an editor, the dysfunction has already set like cheap concrete. We obsess over linting rules, test coverage, and whether we should use tabs or spaces, while ignoring the bleeding obvious: the way we decide what to build is fundamentally snapped in half.

I’m Fritz, and I treat engineering culture as the actual technical problem. Not the soft-skills nonsense HR peddles, but the hard, repeatable failure patterns that show up long before an IDE is even warm. If your team lives in a permanent state of firefighting, blown deadlines, or shipping features nobody asked for, stop pointing at the tech stack. The rot goes deeper. It’s almost always cultural.

The Ticket That Lied to You

Let’s start with the artifact that’s supposed to connect business needs to technical execution: the user story. In theory, it’s a neat, atomic chunk of work. In practice, it’s a cryptic haiku scribbled by someone who hasn’t talked to a real user since the Obama administration. “As a user, I want a dashboard so I can see my data.” Cool. What data? Why? What decision does it drive? What’s the acceptable latency—two seconds, or two minutes while I go make coffee? That ticket is a Rorschach test. Every developer reads it differently and fills in the blanks with their own pet assumptions.

The dysfunction here is the illusion of clarity. Someone barfed a few words into Jira, threw story points at it in a planning poker ritual that feels more like a séance, and called it a day. The real requirements—the edge cases, the performance constraints, the actual user workflow—are buried in someone’s skull or a five-month-old Slack thread nobody can find anymore. This isn’t a communication gap. It’s a systematic refusal to do the hard thinking before the work starts. Engineers plug the holes with guesses. Those guesses turn into technical debt before a single commit exists.

Estimates as a Weapon of Mass Delusion

Ah, estimation. That ritual where we ask developers to predict the future using gut feeling, peer pressure, and a deck of cards, then act personally betrayed when reality doesn’t cooperate. The dysfunction isn’t that estimates are wrong—of course they’re wrong, we’re building things nobody has built before. The problem is that the org treats them as commitments. A rough guess gets rebranded as a deadline, the deadline morphs into a death march, and soon your velocity chart is being weaponized to flog the team in some quarterly review.

This sets up a perverse game. Developers pad estimates to buy themselves air. Managers slash them in half to look good to their bosses. The final number is political fiction, divorced from any engineering reality. Nobody asks the hard questions: “What’s the riskiest piece of this?” “What can we drop if time gets tight?” Instead we get “How many points is it?” as if complexity can be reduced to a Fibonacci number. The real technical problem is that we’ve built a culture where looking predictable matters more than being effective. And that culture doesn’t start in sprint planning. It starts with how leadership reacts when someone brings bad news.

Architecture by Anecdote

Here’s another classic: the senior dev or tech lead who designs the whole system from their personal collection of war stories. “We’re doing microservices because at my last job the monolith was a flaming dumpster.” Never mind that your startup has three engineers and one customer who barely logs in. “We need a queue-based event system because that’s what the big players do.” Congratulations, you just tacked on six months of infrastructure work for a problem you don’t have, may never have, and probably shouldn’t want.

I call this architecture by anecdote. Decisions happen not by looking at current constraints—team size, traffic, business model—but by cargo-culting some FAANG company’s blog post from 2017. The dysfunction? Nobody feels safe pushing back with actual data. The default move is to over-engineer, because it feels safer and looks juicier on a resume. The result is a sprawling system nobody fully understands, built for a scale you’ll never reach, while your actual product-market fit remains a distant fantasy. The worst part? This gets celebrated as “forward-thinking.” It’s not. It’s resume-driven development, and it’s a cultural cancer.

The Meeting That Should Have Been an Email… But Wasn’t Even That

Meetings are the exhaust fumes of bad process. When you see a calendar choked with “syncs,” “alignment sessions,” and “working groups,” you’re staring at a system that has abandoned written, asynchronous communication entirely. The dysfunction: decisions get made verbally, in real time, and leave behind zero artifacts. So the same decision gets re-litigated every Tuesday because nobody remembers what was actually agreed upon—or worse, the one person who wasn’t in the room blocks everything later because they were never looped in.

This imposes a silence tax. Engineers who can’t or won’t thrive in rapid-fire verbal cage matches get sidelined. Ideas that need quiet, written exploration never surface. The team’s collective memory turns into a five-round game of telephone. The fix isn’t yet another recurring meeting. It’s a bloody-minded commitment to writing things down—design docs, decision records, async video updates. But that takes a cultural shift that treats writing as a core engineering skill, not a distraction from “real work.”

The Hero Complex and Its Body Count

Finally, we need to talk about the hero. The engineer who pulls all-nighters, single-handedly wrestles a production outage into submission at 3 a.m., and gets showered with public praise in the #general channel. The dysfunction here is that the organization rewards firefighting over fire prevention. The hero becomes a bottleneck and a single point of failure, but they’re celebrated because they “get things done.” Meanwhile, the quiet engineer who spent two weeks building proper monitoring, writing runbooks, and simplifying the gnarly bits gets a lukewarm performance review because their impact isn’t dramatic enough for a slide deck.

This selects for exactly the wrong behaviors. It broadcasts to everyone that the path to glory is to let things break and then swoop in with a cape. It actively discourages the unsexy work that stops incidents from happening at all. The most damning part? This hero culture is often cultivated by engineering managers who don’t know what a healthy system looks like. They see a calm, boring on-call rotation and assume nothing is happening, rather than recognizing it as the ultimate success signal. This is a cultural failure, plain and simple. It’s set in stone long before any postmortem doc gets written.

So next time your sprint goes off the rails, don’t just stare at the code. Look at the ticket that kicked it off. Look at the estimate that lied straight to your face. Look at the architecture decision made over a rushed coffee chat. Look at the meeting where the real requirement was mumbled, misunderstood, and lost forever. That’s where the bugs actually live. The compiler can’t catch those. No linter will ever flag “culturally accepted insanity.”

Frequently Asked Questions

Why do engineering teams keep making the same process mistakes?

Because we optimize for local comfort, not global outcomes. Teams settle into broken patterns because it’s easier in the short term—easier to nod along in a meeting than to write a clear spec, easier to pad an estimate than to challenge a ridiculous deadline. The pain of the dysfunction is diffuse and delayed; the pain of fixing it is immediate and personal. Until leadership treats process health as a first-class metric, the path of least resistance leads straight to chaos.

How can I tell if my team’s dysfunction is cultural or just a skill gap?

If a single sharp hire could fix it, it’s a skill gap. If you’ve hired smart people and they’re still producing garbage, it’s cultural. Look at what gets rewarded and punished. Are people celebrated for saying “I don’t know”? Are postmortems actually blameless, or do they turn into quiet finger-pointing sessions? Do decisions get written down anywhere? If the environment punishes transparency and rewards heroics, no amount of training will help. You could parachute in a world-class architect, and they’d burn out inside a quarter.

What’s the one thing I can do today to start fixing this?

Start writing. Before any non-trivial piece of work, force a one-page design doc. Not a novel—just a tight explanation of the problem, the proposed fix, the alternatives you considered, and the risks you can already see. Share it asynchronously, let people rip it apart in comments, and actually resolve those comments before a line of code gets written. This single habit surfaces ambiguous requirements, forces decisions into the open, and leaves a paper trail. It’s not a silver bullet, but it’s the closest thing I’ve found to a circuit breaker for pre-code dysfunction.

Look, I’ve been in this game long enough to know that most software disasters aren’t caused by bad code. They’re caused by the 47-minute Zoom call that happened three weeks before a single line was typed. The one where someone said, “Let’s circle back on the requirements,” and everyone nodded like dashboard bobbleheads. That conversation? That’s where the dysfunction planted its flag.

Engineering dysfunction isn’t a technology problem. It’s a people problem wearing a Jira hoodie. And until we start treating cultural rot with the same rigor we apply to a database migration, we’ll keep shipping garbage and calling it agile.

The Pre-Code Graveyard

Walk into any engineering org and you’ll find the same damn pattern. The project kicked off six months ago. The roadmap looked gorgeous. The kickoff meeting had snacks. But now, two sprints before launch, the team is paralyzed. The backend team hates the frontend team. The product manager is rewriting user stories at 10 p.m. And nobody can explain what “MVP” means anymore, because it’s changed twelve times.

You know what went wrong? Nothing happened during development. Everything went wrong before it. The code is just the corpse.

The Blame-Sharing Ceremony

Every organization has a ritual I call the Blame-Sharing Ceremony. It usually starts with a stakeholder saying, “We need to move fast.” What they mean is, “I already promised this to a customer, so your estimates are now my hostage.” The engineering manager, terrified of looking “not technical enough,” commits to a deadline that was pulled from a motivational poster. Then the senior dev, who saw this coming a mile away, says nothing because they’re busy updating their LinkedIn profile.

This is not a communication breakdown. It’s a cowardice pipeline. And the output is a codebase that smells like fear.

The Architecture Astronaut Landing

Then comes the architecture review. Someone who hasn’t written production code since the Obama administration slides into the meeting with a diagram that looks like a plate of spaghetti and says, “We should consider an event-driven microservices approach.” For a cron job. For a single script. That sends one email a week.

The team, now trapped in a sunk-cost fallacy, spends three weeks building infrastructure that will never scale because the product won’t survive long enough to need it. The dysfunction here isn’t the complexity. It’s the total detachment from business reality. Engineers love to build engines, but nobody asked if the car needs to move yet.

The Real Technical Debt Is Behavioral

We love to talk about technical debt like it’s some inevitable byproduct of speed. But most technical debt isn’t from rushing. It’s from deciding things badly when you had all the time in the world. Choosing a NoSQL database because it was trendy, not because you needed flexible schemas. Splitting into microservices because Netflix does it, not because your team of four can operate them. Writing an abstraction layer so generic it can “support any future use case”—and then never having a second use case.

Those decisions weren’t made in a coding frenzy. They were made in a conference room with a projector and too much confidence.

The “Yes” Culture Tax

One of the most expensive words in engineering is “yes.” Yes, we can add that feature. Yes, we can hit that date. Yes, we can support that edge case. Every “yes” without a corresponding “no” is a withdrawal from the team’s credibility account. Over time, you end up bankrupt. The product becomes a feature junkyard. The team burns out. And management wonders why velocity dropped.

It didn’t drop. It was never real to begin with. The estimates were fiction. The commitments were political theater. The dysfunction was hiding behind a burndown chart that lied as smoothly as a sales deck.

How to Smell the Fire Before the Smoke

The good news? This stuff is detectable. If you know what to sniff for, you can spot a doomed project before the repository is even created. Here’s my personal checklist of pre-code red flags:

• The requirements document is over 20 pages. Nobody read it. Everyone skimmed it and nodded. You’re building on quicksand.
• “We’ll figure out the details in the sprint.” Translation: we haven’t done the thinking, but we’re already late, so let’s pretend agility is the plan.
• No single person can describe the user’s problem in two sentences. If the problem isn’t sharp, the solution will be a blob. A very expensive blob.
• Estimates are given in hours, not days. That level of false precision means someone is trying to control something they don’t understand.
• The word “just” appears in every planning meeting. “We’ll just add a flag.” “We’ll just refactor that later.” “Just” is a four-letter word for “I don’t want to think about it.”

The Meeting That Should Have Been an Email (But Wasn’t)

Here’s a classic scenario. A stakeholder wants a “simple dashboard.” The product manager says, “Sure, we’ll scope it.” They call a meeting. In that meeting, someone mentions “real-time updates.” Another person says, “We should probably support mobile too.” By the end of the hour, the “simple dashboard” is now a cross-platform analytics suite with role-based access control. Nobody asked if the user actually needs any of that. Nobody asked what problem it solves. The scope expanded because people were in a room and felt they needed to contribute something.

This is how projects die before a line of code. The meeting wasn’t a planning session. It was a brainstorming epidemic. And the cure is someone saying, “Stop. What is the one thing that would make this useful?” That person? Usually not in the room.

Fixing It Before It’s Broken

So how do you kill dysfunction before it hatches? You don’t need a workshop or a framework. You need to act like an engineer even when you’re not in front of a keyboard.

First, make decisions reversible. If a choice can be undone easily, don’t spend two weeks debating it. Pick one and move. The real damage comes from locking yourself into a bad choice because you treated it like a permanent tattoo.

Second, ban vague nouns. “Performance,” “scalability,” “quality”—these mean nothing without a number. If someone says, “We need it to be fast,” ask: “What is the acceptable response time under what load?” If they can’t answer, they don’t know what they want. Don’t build it yet.

Third, reward the person who kills bad ideas early. Most cultures celebrate the hero who ships a messy feature on time. Celebrate the person who says, “This feature doesn’t make sense,” in week one. That person saved you months of pain. Buy them a coffee. Give them a raise.

Writing Code Is the Last Resort

I’ve come to believe that writing code should be a last resort, not a first reflex. If you can solve the problem with a conversation, a configuration change, or by simply deciding not to do something, do that. The best engineering I’ve ever done involved deleting requirements, not implementing them. That’s not laziness. It’s discipline.

When you treat code as precious, you treat the decisions around it as critical. And you make sure those decisions aren’t made by a room full of people who are afraid to sound stupid.

FAQ

Why do teams keep falling into these pre-code traps even with experienced engineers?
Because experience doesn’t inoculate you against social pressure. It’s easier to nod along in a meeting than to be the one who says, “This doesn’t make sense.” That takes emotional energy, and most people run out of it by 2 p.m.

What’s the single biggest predictor of project failure before coding starts?
Ambiguous ownership. If you can’t name the one person who will be dragged out of bed at 3 a.m. when the thing breaks, you don’t have a team. You have a committee. And committees don’t ship, they socialize.

Can this cultural dysfunction be fixed from the bottom up, or does it require leadership buy-in?
Leadership buy-in accelerates everything, but bottom-up change is possible if you’re stubborn. Start with your own projects. Ask obnoxiously clear questions in planning meetings. Refuse to estimate until you understand the problem. People will either follow you or get out of the way. Either outcome is progress.