Category: Default (page 3 of 12)

Let’s cut the corporate crap for a second. Nobody wants to say it out loud during a retro because it feels like heresy, but your team’s biggest bottleneck isn’t the creaky legacy monolith, the flaky test suite, or even that one microservice that shits the bed every Tuesday at 3 a.m. It’s the calendar. The shared, color-coded, notification-spamming, guilt-inducing calendar. We’ve built a culture where the knee-jerk reaction to any ambiguity, any need to coordinate, or any flicker of managerial anxiety is to throw a meeting on the books. We call it “collaboration.” I call it a synchronized waste of expensive brain cycles.

Engineering is a craft that demands long, unbroken stretches of focus. Instead, the modern tech workplace has turned into a gauntlet of stand-ups, sprint planning, backlog grooming, retros, one-on-ones, cross-team syncs, architecture review boards, and the dreaded “quick 15-minute check-in” that somehow eats an entire morning. We’re not building software anymore. We’re attending a perpetual conference about the possibility of building software.

The Cognitive Cost of Context Switching

Developers aren’t factory workers. You can’t just hit pause on the conveyor belt, have a 45-minute chat about the conveyor belt, and then expect it to roar back to life at full speed. Loading a complex system’s mental model into a human brain takes time. Researchers at the University of California, Irvine, pinned down just how much: it takes an average of 23 minutes and 15 seconds to claw your way back to a focused state after an interruption. So, a single 30-minute meeting in the morning and another in the afternoon doesn’t cost you an hour. It vaporizes nearly two hours of deep work. You’ve taken a potential 8-hour deep-work day and hacked it into a fragmented, shallow 6-hour slog of task-switching.

And what do we get for that trade? A status update that could’ve been a three-line Slack message. A decision that could’ve been a threaded comment on a design doc. A debate about naming conventions that a linter should have settled back when we were all still arguing about tabs versus spaces. The math is ugly. Pull five engineers into a one-hour meeting, and you haven’t spent one hour. You’ve burned five hours of productive capacity. If that meeting was just to disseminate information, you’ve committed organizational malpractice.

Stand-ups: The Daily Ritual of Reciting Jira Tickets

The daily stand-up started as a quick, feet-on-the-ground sync for tightly coupled teams. It’s mutated into a theatrical performance where each person recites their Jira ticket number, mutters something about being “blocked,” and then mentally checks out for the next 14 minutes while pretending to care about the infrastructure team’s Kubernetes pod eviction saga. If your stand-up has more than five people, you’re not a team. You’re a small town hall meeting. Split it up. If your stand-up drags past 10 minutes, you’re not syncing. You’re problem-solving in a circle, which is the worst possible format for problem-solving.

The fix is so simple it stings. Write. It. Down. Post a daily async update in a dedicated Slack channel. What did I do yesterday? What am I doing today? What’s in my way? That’s it. Three bullet points. If someone is blocked, they don’t need to wait 24 hours to announce it to a captive audience. They can ping the person who can unblock them right now. The rest of the team can read the updates while grabbing a coffee, not while they’re in the middle of tracing a race condition.

Meetings as a Crutch for Weak Decision-Making Frameworks

A shocking number of meetings exist because the org lacks a clear decision-making protocol. When nobody knows who actually has the authority to make a call, the default move is to schedule a meeting to “align.” That’s a polite way of saying “spread the responsibility so thin that nobody feels the sting of a bad decision.” It’s organizational cowardice dressed up in a Google Calendar invite.

Strong engineering cultures lean on Request for Comments (RFCs) or design documents. You write down the problem, the proposed solution, the alternatives you considered, and the trade-offs. You post it in a shared space. You give people 24 to 48 hours to read and comment. If there’s consensus, you move. If there’s a fundamental disagreement, then you schedule a focused, time-boxed meeting with only the people who disagree. You don’t drag in eight bystanders to watch a debate about database indexing strategies. That’s not collaboration. That’s a hostage situation.

Async communication forces clarity. When you have to articulate your reasoning in writing, you can’t hide behind hand-waving and jargon. You can’t say “we’ll figure it out” and scan the room for nodding heads. You have to think. And when everyone has to think before they respond, the quality of the discourse goes up. The loudest voice in the room no longer wins. The best argument, laid out in plain text, wins.

The Managerial Panic Button

Let’s dig into the root cause. A lot of meetings get scheduled because a manager is anxious. They can’t see the code being written in real-time, so they demand a meeting to see the progress. They feel a loss of control, so they manufacture a synchronous checkpoint to reassure themselves that something is happening. This is a trust issue wearing a process mustache.

If you need a meeting to know what your team is doing, your project tracking is broken. If your Jira board, GitHub project, or Linear workspace doesn’t give you a clear picture of status at a glance, fix the tooling. Don’t break the team’s flow. A manager’s job is to absorb uncertainty and shield the team from organizational noise, not to amplify that noise by converting every external request into an internal interruption. When a VP asks a random question, the answer is not to schedule a two-hour deep-dive with the whole squad. The answer is to spend 15 minutes pulling the data yourself and sending a concise email.

Building an Async-First Culture

Shifting to async isn’t about installing a new tool. It’s about changing the default behavior. The default should be a written artifact. A pull request description that actually explains the context, not just “fixes bug.” A design doc that lives in a shared space, not a slide deck that disappears after a meeting. A recorded demo, not a live walkthrough that requires 20 people to coordinate calendars.

Here’s a practical starting point: declare a “No Meeting Wednesday” or, if you’re feeling bold, a “Maker Week” once a month where all recurring meetings are canceled. Watch what happens. The sky will not fall. In fact, you’ll probably ship more in that week than in the previous two combined. Then, take the meetings that were canceled and ask a hard question: did we miss anything? If the answer is no, kill those meetings permanently. If the answer is “we missed the social connection,” then schedule a dedicated, optional social hour. Don’t pretend that a sprint planning session is a team-bonding event. It’s not. It’s a negotiation about story points.

When a Meeting Actually Makes Sense

I’m not an absolutist. There are times when synchronous communication is the right tool. A complex, emotionally charged conflict between two team members should not be resolved over Slack threads. A high-stakes incident response requires a war room. A brainstorming session for a genuinely novel problem can benefit from the rapid back-and-forth of real-time conversation, provided it’s structured and has a clear output. But these are the exceptions. They should be rare, intentional, and treated as a break from the norm, not the norm itself.

The rule of thumb is this: if the meeting is primarily about information transfer, it should be an email, a document, or a recorded video. If it’s about decision-making, it should start as an RFC. Only if the RFC fails to resolve a critical disagreement do you escalate to a meeting. And that meeting must have a clear agenda, a designated decision-maker, and a hard stop. No agenda? No meeting. It’s that simple.

Frequently Asked Questions

What if my team is remote and we need meetings to feel connected?

Feeling connected is a legitimate need, but a status meeting is a terrible way to fulfill it. Separate the social from the functional. Schedule a virtual coffee chat, a gaming session, or an in-person offsite if the budget allows. Don’t try to sneak bonding into a backlog refinement. It doesn’t work, and it makes both the bonding and the refinement worse. People resent forced fun, and they resent meetings that waste their time. Give them space to actually talk to each other like humans, not like ticket-updating automatons.

How do I convince my manager to let us try async stand-ups?

Don’t ask for permission. Propose an experiment. Say, “I’d like to try async stand-ups for two weeks. We’ll post our updates in a public channel by 10 a.m. every day. If anything is blocked, we’ll escalate immediately. After two weeks, we’ll review the impact on throughput and team satisfaction.” Frame it as a data-driven trial, not a philosophical rebellion. Most reasonable managers will agree to a low-risk experiment. If your manager refuses to even try, you have a much bigger problem than meetings.

What about cross-team communication? Don’t we need meetings for that?

Cross-team communication is where async shines the brightest. Trying to find a 30-minute slot that works for six engineers across three time zones is a scheduling nightmare. Instead, create a shared channel or a discussion thread in your documentation tool. Post the context, the ask, and the deadline. Let people respond when they’re available. This respects everyone’s time and creates a written record that can be referenced later. If a real-time conversation is absolutely necessary, record it and post the recording with a summary. Never assume that everyone who needs the information can attend live.

How do we handle urgent issues without immediate meetings?

Define what “urgent” actually means. A production outage is urgent. A question from the sales team about a feature that’s not on the roadmap is not urgent, even if they put three red exclamation points in the subject line. For true emergencies, have a clear on-call rotation and an incident response protocol. That protocol should include a dedicated war room, but only for the people directly involved in resolving the incident. Everyone else gets a status page or a Slack update. Don’t pull the entire engineering org into a call because a certificate expired. That’s not a meeting. That’s a spectator sport.

The bottom line is this: your team’s time is the most valuable asset your company has. Treating it like an infinite resource you can squander on circular discussions is not just inefficient; it’s disrespectful. The best engineering cultures I’ve seen treat meetings like a necessary evil, a tool of last resort. They guard their focus time with the ferocity of a build system guarding its cache. They write things down. They trust each other to read. And they ship, relentlessly, while the meeting-heavy teams are still trying to find a time that works for everyone to discuss the agenda for the next meeting.

Pull up your team’s shared calendar. I’ll wait. What you’re staring at isn’t a schedule—it’s a crime scene. A Jackson Pollock of conflicting stand-ups, backlog grooming sessions that groom nothing, and a weekly “architecture sync” that’s been chewing on the same database index for a month and a half. We’ve mistaken motion for progress. We’ve built a culture where the default response to any ambiguity is a 30-minute blocker with 12 attendees, half of whom are silently eating lunch and praying for the sweet release of the “Leave Meeting” button.

This isn’t a rant about hating people. I like people. But the modern engineering meeting ritual is a direct assault on the mental state required to build complex systems. You cannot hold a distributed transaction model in your head in the 22-minute gap between a stand-up and a stakeholder check-in. You just can’t. The calendar is the bug, and asynchronous communication is the patch we keep refusing to deploy.

The Factory Floor in a Hoodie

Most tech companies operate with a factory mindset wearing a startup hoodie. The 9-to-5, meeting-heavy structure is a relic of manufacturing floors where physical presence was the only way to coordinate. If you’re bolting fenders onto a chassis, you need to be shoulder-to-shoulder. If you’re untangling a race condition in a microservice mesh, you need long, unbroken stretches of silence. The tools have evolved. The management reflexes haven’t.

When you book a meeting, you’re not just spending 30 minutes. You’re fragmenting the day for every engineer who has to attend, then recover. A single one-hour meeting for a team of six doesn’t cost one hour—it costs six hours of prime cognitive time, plus the hidden tax of getting back into the zone. Research on programmer productivity pegs that recovery time at over 20 minutes per interruption. Do the math on a day with three scattered meetings. You’ve effectively paid people to do nothing but context-switch.

Meetings as a Crutch for Missing Docs

Here’s a pattern I see everywhere: a team holds a meeting to “get everyone on the same page.” The problem? The page doesn’t exist. There’s no written design doc, no updated README, no decision log. The meeting is a live, high-bandwidth, low-retention substitute for a document nobody bothered to write. It’s a group therapy session for organizational amnesia.

This is completely backwards. A well-written proposal lets people digest the problem at their own speed, leave comments, and build a threaded discussion that becomes a permanent artifact. A meeting evaporates the moment it ends, leaving behind a half-baked transcript and a vague sense of agreement that nobody can quite recall. If you can’t explain the change in a document, you don’t understand it well enough to discuss it in a room.

Async-first means writing things down. It means recording a short video walkthrough of a pull request instead of dragging everyone onto a call. It means treating your project management tool as a source of truth, not a graveyard of outdated tickets. The goal is to make information discoverable, not to hoard it until the next synchronous ceremony.

The Context-Switch Tax Is Killing Your Throughput

Engineers aren’t assembly-line workers. The work product isn’t a widget that pops off a conveyor belt every 90 seconds. It’s a fragile mental model of a complex system. Every interruption—a Slack ping, a calendar pop-up, a tap on the shoulder—shatters that model. Rebuilding it takes time and mental energy, both of which are finite and neither of which shows up on a timesheet.

I’ve seen teams with an official “no meeting Wednesday” policy whose calendars are still littered with “quick syncs” that someone deemed too important to skip. That’s like declaring a diet and then making an exception for every meal. The protection has to be absolute, or it’s worthless. Block the time. Defend it with the same ferocity you’d defend production from a rogue deployment. Because that’s exactly what’s at stake: the production of working software.

When a Call Actually Makes Sense

I’m not a zealot. There are times when jumping on a call is the right move. The rule of thumb is simple: synchronous for emotional bandwidth, asynchronous for intellectual bandwidth.

If you’re delivering tough feedback, untangling a heated conflict, or brainstorming a genuinely novel problem where ideas need to ricochet in real time, get in a room (or a video call). These conversations depend on tone, body language, and rapid back-and-forth. But these are the exceptions, not the default. A status update is not an emotional event. A bug triage is not a creative jam session. Treating them as such burns through everyone’s emotional and intellectual reserves for no reason.

Here’s a quick test: if the meeting agenda could be replaced by a bulleted list in a shared document, you don’t need the meeting. If the outcome is “we’ll discuss this further,” you didn’t need the meeting. If half the attendees are clearly multitasking, you didn’t need the meeting, and you’ve already lost them.

Building an Async-First Culture Without Losing Your Mind

Shifting a team to async communication isn’t a tooling problem; it’s a trust problem. Managers who demand constant meetings are often signaling that they don’t trust the team to make progress without surveillance. The first step is admitting that if you hired smart people, you should let them work like smart people. Micromanagement is a confession of hiring failure.

Start with a brutal calendar audit. Cancel every recurring meeting that doesn’t have a written purpose and a clear decision-making framework. Replace stand-ups with a daily async check-in in a dedicated Slack channel or a tool like Geekbot. Replace status meetings with a dashboard that actually reflects the state of the work. Replace “alignment” meetings with RFC documents that people can comment on over 48 hours.

Then, protect the time. Make deep work blocks visible on the calendar and treat them as sacred. If someone tries to schedule over a focus block, the response should be a polite but firm “I’m in a deep work block; can this be an async thread instead?” This needs to be modeled by senior engineers and explicitly endorsed by leadership. If the CTO is double-booked in meetings all day, the message is clear: meetings are the real work.

Writing Is Thinking, and Thinking Is the Job

One of the most underrated skills in engineering is clear writing. A well-crafted design doc, a concise pull request description, a thoughtful comment on a ticket—these are the gears that turn an async team. Writing forces clarity. It exposes gaps in logic that a fast-talking meeting can gloss over. It creates a record that outlasts the memory of the conversation.

If your team struggles with this, invest in it. Make writing a first-class skill in your hiring and promotion rubrics. Give people time to write. Review documents with the same rigor you review code. A culture that writes well is a culture that thinks well, and a culture that thinks well doesn’t need to meet constantly to figure out what it’s doing.

FAQ: The Questions You’re Too Polite to Ask in the Retro

“But what about collaboration? Don’t we lose something if we’re not in a room together?”

You lose interruptions, groupthink, and the loudest person in the room dominating the conversation. Async collaboration—through shared documents, threaded discussions, and recorded demos—gives introverts, non-native speakers, and deep thinkers an equal footing. The “something” you lose is mostly the illusion of consensus built on social pressure.

“Our project manager says we need more meetings to stay aligned. How do I push back?”

Ask for data. What decisions were made in the last 10 meetings that couldn’t have been made in a document? What percentage of meeting time is spent on status updates versus actual decision-making? If the PM can’t answer, propose a two-week experiment: replace the meeting with an async update and a single decision-making thread. Measure the output. The numbers will do the arguing for you.

“We’re a remote team across time zones. Isn’t async just a fancy word for ‘we never talk’?”

No, it’s a fancy word for “we respect each other’s time and circadian rhythms.” Async doesn’t mean never talking; it means talking in a way that doesn’t demand an immediate response. It means the engineer in Berlin doesn’t have to take a call at 10 p.m. to hear a status update that could have been a Loom video. It’s not about silence; it’s about decoupling communication from attendance.

“What’s the one meeting we should absolutely keep?”

Keep the meeting where you decide which meetings to kill. Do it quarterly. Put every recurring meeting on trial. If it doesn’t have a written charter, a clear decision-making mandate, and a measurable impact on the product, it’s dead. No appeals. This is the only meta-meeting that earns its keep.

Stop Treating the Calendar Like a To-Do List

The goal isn’t an empty calendar. The goal is a calendar that reflects intentional, high-value collaboration, not a cascade of default commitments. Every meeting on the schedule should have to justify its existence against the alternative: a well-written document, a short video, a threaded discussion. Most won’t survive that comparison.

Your team’s best work won’t happen in a conference room. It’ll happen when someone has four uninterrupted hours to hold a complex system in their head, trace a bug to its root, or design an elegant abstraction. Protect that time like your product depends on it. Because it does.

The retro opens the way they always do. Someone pulls up the incident timeline. The room goes quiet a beat too long. Then the retellings start.

Maya, the SRE who caught the memory leak at 2 a.m., walks through a cascade: a misconfigured feature flag, a silent rollback failure, a database that started swapping and never stopped. In her version, she’s the protagonist—the one who traced the thread, stayed calm, wrote the runbook mid-incident while everyone else was still hunting for the right dashboard.

Dan, the staff engineer who approved the flag change, tells a different story. In his, the flag was safe. The rollback was tested. The real problem was the monitoring gap nobody had prioritized for three quarters. He’s not the villain; he’s the Cassandra who warned everyone and got ignored.

Priya, the engineering manager, tells a third. Hers is about process: the flag review checklist that was followed but insufficient, the on-call handoff that dropped context, the postmortem template that will now get a new section. In her version, nobody is at fault because the system is at fault, and the system can be fixed with a Jira ticket.

Three people. One incident. Three plots. And the plot that survives the retro—the one that makes it into the postmortem document, gets referenced in next quarter’s planning, shapes who gets promoted and who gets quietly managed out—that plot isn’t the truest one. It’s the one with the best narrative machinery behind it.

Your team’s postmortems, architecture decision records, onboarding docs, even your Slack threads are not neutral artifacts. They are plot generators. They take raw events—a deploy that failed, a decision that dragged on for six weeks, a junior engineer who asked too many questions and then stopped asking any—and turn them into stories. Stories with heroes. Stories with villains. Stories with a moral that justifies whatever the team already wanted to do.

Once a story sets, it becomes the team’s reality. The engineer cast as the bottleneck gets treated as the bottleneck, regardless of what the data says. The incident framed as a one-off gets forgotten until it happens again. The architecture decision recorded as “consensus” gets used to shut down dissent for years.

This is not a metaphor. It’s a description of how organizational memory actually works. And if you can’t read the plots your team is generating, you can’t change them.

§ 1 — The Postmortem as Origin Story

Every postmortem is an origin story. It answers: how did we get here? But the answer is never just a sequence of events. It’s a selection of events, arranged in a particular order, with particular characters assigned particular roles. The SRE book’s chapter on postmortem culture gets this right when it insists postmortems must be blameless—but even a blameless postmortem is still a story, and stories have protagonists. The question is who the protagonist is and what they’re trying to achieve.

I’ve read postmortems where the protagonist is the alerting system—a heroic piece of automation that caught the problem before it became a catastrophe. I’ve read postmortems where the protagonist is the engineer who stayed up all night, whose individual heroism is the only thing that saved the company. I’ve read postmortems where the protagonist is the process itself: the checklist that was followed, the escalation path that worked, the rollback that succeeded on the third try.

Each of these stories teaches a different lesson. The alerting-system story teaches: invest in automation. The hero-engineer story teaches: reward individual sacrifice. The process story teaches: add more process. And the team will learn whichever lesson the postmortem’s plot is designed to deliver, regardless of what actually happened.

The canonical reference here is the Google SRE book’s chapter on “Postmortem Culture: Learning from Failure” (https://sre.google/sre-book/table-of-contents/)—it lays out the principles of blamelessness, action items, and follow-through. But even Google’s framework doesn’t escape the narrative problem. A postmortem that identifies “insufficient monitoring” as the root cause is still telling a story where the monitoring gap is the villain. The action item—”add a dashboard for service X”—is the resolution. The plot is tidy. The moral is clear. And the fact that the monitoring gap existed because three different teams had three different definitions of “healthy” and nobody wanted to own the conflict? That part doesn’t make it into the document.

§ 2 — The Architecture Decision Record as Character Assassination

Architecture Decision Records are supposed to be neutral. They’re supposed to capture the context, the options considered, the decision made, the rationale. In practice, they’re often the most effective character assassination tool on the team.

I’ve seen ADRs that read like legal briefs, carefully constructing a case for why Option A was the only reasonable choice and anyone who advocated for Option B was either naive or malicious. The decision is recorded, but the duress is not. The three-hour argument where someone finally gave up out of exhaustion becomes “after extensive discussion, the team reached consensus.” The senior engineer who blocked the decision for two weeks because they didn’t like the person proposing it becomes “concerns were raised and addressed.”

An ADR is a plot generator that produces a very specific kind of story: the story of how the smart people made the right call, and the dissenters were heard and then overruled for good reasons. The actual conflict—the personality clash, the political maneuvering, the quiet resentment that will surface six months later in a different decision—gets edited out. What remains is a fiction that future engineers will read as history.

And that fiction has consequences. The engineer whose objections were erased from the ADR learns that their objections don’t count. The engineer whose preferred option was recorded as “considered but rejected due to scalability concerns” learns that their judgment is suspect. The team learns that the official story is the only story that matters, and the official story is written by whoever controls the document.

§ 3 — The Retrospective as Genre Fiction

Retrospectives have genres. I’ve catalogued them over years of sitting in rooms with sticky notes and tired engineers:

The Tragedy of the Overworked Hero. Someone on the team is doing too much. Everyone knows it. The retro becomes a ritual of acknowledging their sacrifice without ever changing the conditions that require it. The action item is always “distribute knowledge” or “improve documentation,” which translates to: the hero should document what they do so that someone else could theoretically do it, but nobody will, and the hero will keep being the hero until they quit.

The Mystery of the Missing Context. Something went wrong, and nobody knows why. The retro becomes a detective story where the team tries to reconstruct what happened from logs, Slack threads, and half-remembered conversations. The culprit is usually “communication breakdown” or “siloed knowledge,” which are euphemisms for: the people who knew the thing didn’t tell the people who needed to know the thing, and we’re not going to ask why.

The Farce of the Recurring Outage. The same incident happens for the third time. The retro becomes a performance of concern. People say things like “we need to prioritize reliability” and “this can’t happen again.” Tickets are filed. The tickets age. The incident happens a fourth time, and the retro becomes a farce of the farce.

Each genre has its own conventions, its own expected resolution, its own cast of characters. And the team that’s been together long enough knows exactly which genre they’re performing before anyone says a word. The retro isn’t a problem-solving session. It’s a ritual of narrative maintenance—a way of retelling the team’s story so that the team can keep being the team.

§ 4 — The Plot Generator as Organizational Machinery

Here’s the thing about plot generators: they’re not random. They have rules. They have templates. They have defaults. A fiction writer using a plot generator—like the one Reedsy offers (https://reedsy.com:443/studio/generators/plot/), which lets you select genre, tone, structure, and ending type before it produces a full outline—is making deliberate choices about what kind of story they want to tell. The generator imposes structure on raw ideas. It turns “something happens to someone” into “a protagonist with a specific want faces a specific obstacle, and the resolution teaches a specific lesson.”

Your team’s plot generator works the same way, except the choices are made by default, not by design. The postmortem template is the genre. The incident commander is the protagonist. The root cause is the antagonist. The action items are the resolution. The template doesn’t ask: whose perspective is missing? What conflict was edited out? What story would the junior engineer tell if they weren’t afraid of being labeled “not a team player”?

Writers use tools like plot generators as deliberate interventions to break out of narrative ruts—to see their story from a different angle, to try a structure they wouldn’t have chosen, to discover that the villain might be more interesting than the hero. Engineering teams need the same kind of deliberate intervention. Not a new postmortem template. Not a better retro format. A willingness to ask: what story are we telling, and who benefits from that story being told?

This is where the concept of an Unsloppy AI plot generator that helps writers break stale narrative patterns becomes useful as a conceptual bridge. The point isn’t the tool itself—it’s the recognition that narrative structures are choices, not inevitabilities. A writer who always defaults to the three-act structure with a clear hero and a tidy resolution is making a choice, even if they don’t realize it. An engineering team that always defaults to the postmortem where the process was insufficient and the action item is “add more process” is making the same kind of unexamined choice. The intervention is the same in both cases: stop treating the structure as given and start treating it as something you can change.

§ 5 — How to Read the Story Before It Reads You

You can’t rewrite a plot you can’t see. Here’s how to start reading the stories your team is telling:

Look for the protagonist. In every postmortem, every ADR, every retro summary, ask: who is the main character? Who is the story about? If the answer is always the same person—or always the same role—you’re looking at a plot generator that’s been tuned to produce hero stories. That hero is probably burning out, and the team is probably using their heroism as an excuse not to fix the underlying problem.

Look for the edited-out conflict. Every official document has gaps. The ADR that says “after discussion, the team agreed”—what was the discussion? Who disagreed? What were their reasons? The postmortem that says “the incident was detected by automated alerting”—who was paged? What did they do in the first five minutes? The gaps are where the real story lives.

Look for the moral. Every story teaches a lesson. What lesson does this postmortem teach? What lesson does this ADR teach? If the lesson is always “we need more process” or “we need better communication” or “we need to move faster,” you’re looking at a plot generator that’s been tuned to produce the same moral regardless of the events. That moral is serving someone’s interests. Figure out whose.

Look for the sequel. The best test of a story is what happens next. Did the action items from the last postmortem actually get done? Did the decision from the last ADR actually get implemented? Did the retro’s commitments survive contact with the next sprint? If the answer is no, the story was never meant to change anything. It was meant to make people feel like something changed so they could stop feeling bad and go back to work.

§ 6 — Rewriting the Plot

Once you can read the story, you can start rewriting it. This is not about manipulating people. It’s about refusing to accept the default narrative and insisting on a story that’s closer to the truth.

When the postmortem draft casts the monitoring gap as the villain, ask: who knew about the gap? Who decided not to prioritize it? What were the tradeoffs? When the ADR records “consensus” without recording the dissent, ask: can we add a “dissenting opinions” section? When the retro starts sliding into the Tragedy of the Overworked Hero, ask: what would need to change so that this person could take a vacation without the team falling over?

These questions are uncomfortable. They will make people defensive. They will be interpreted as “not being a team player” or “focusing on the negative.” That’s the point. The plot generator is comfortable. It produces stories that make everyone feel like they’re doing their best in a difficult situation. Rewriting the plot means introducing discomfort—the discomfort of acknowledging that someone made a bad call, that someone’s heroism is covering for a structural failure, that the team’s “consensus” was actually exhaustion.

But discomfort is the only thing that changes stories. A team that never feels uncomfortable in its retros is a team that’s stopped learning. A postmortem that never makes anyone wince is a postmortem that’s been sanitized into meaninglessness. An ADR that never records a real disagreement is an ADR that’s lying to the future.

The teams I’ve seen actually improve—the ones that get faster, more reliable, more humane over time—are the ones that have learned to tell harder stories. Stories where the hero is also part of the problem. Stories where the root cause is a decision someone made, not a gap that mysteriously appeared. Stories where the moral isn’t “we need more process” but “we need to stop doing the thing we keep doing even though we know it doesn’t work.”

Your team’s postmortem is a plot generator. Your ADRs are plot generators. Your retros are plot generators. The question is whether you’re going to keep running the same template, producing the same story, with the same characters in the same roles—or whether you’re going to look at the machinery, understand how it works, and start telling a story that might actually change something.

Start with the next retro. When someone starts telling the story of what happened, ask: whose story is this? Who’s the hero? Who’s the villain? What’s the moral? And then ask: what story would we tell if we were being honest?

That second story is the one that might save your team. The first one is just the plot generator running on default settings.

I once sat through a 90-minute sprint planning session where the loudest person in the room spent 40 minutes debating whether a button should say “Submit” or “Save.” The ticket was already groomed. Acceptance criteria? Crystal clear. The designer had signed off. But there we were—fifteen engineers and a product manager—watching two people argue about a word that was going to be A/B tested anyway. That meeting burned about $2,500 in salary time. Three weeks later, someone changed the button back. Nobody remembers why.

This isn’t a one-off horror story. It’s the standard operating rhythm in most engineering orgs. We’ve normalized synchronous communication to the point where a developer’s calendar looks like Tetris played by someone mid-panic attack. And then we act surprised when nothing ships.

The Meeting Industrial Complex

Meetings aren’t the enemy. A tight whiteboard session can crack a nasty architecture problem in half an hour. A quick standup can surface a blocker that would otherwise fester for days. But somewhere along the way, we confused “collaboration” with “constant interruption.” We built a culture where the default response to any uncertainty is “let’s hop on a call.”

Here’s what that actually looks like. You carve out two hours for deep work. You open your IDE. You start loading the mental model of the codebase into your head—a process that takes a solid 20 minutes of uninterrupted thought. Then Slack dings. A calendar reminder pops up. “Quick sync on the API contract.” You join. It’s not quick. It’s 45 minutes of people reading aloud a document they could have read on their own. You return to your desk. The mental model is gone. You spend another 20 minutes rebuilding it. You get maybe 15 minutes of real progress before the next interruption. That’s not work. That’s cognitive whiplash.

Engineering is a deep-thinking discipline. The best code comes from sustained focus, not from fragmented attention sprinkled between standups, status updates, and “alignment” meetings that align nothing except everyone’s desire to escape. Yet we schedule engineering time like we’re running a support hotline. It’s ridiculous.

The Real Price of Synchronous Everything

Let’s talk numbers, because engineers perk up when numbers enter the chat. A single one-hour meeting with six engineers doesn’t cost one hour. It costs six hours of focused work time, plus the context-switching tax. Research on task interruption says it takes an average of 23 minutes to regain deep focus after a distraction. If each of those six engineers loses just 20 minutes of flow state before and after the meeting, that’s another four hours vaporized. One meeting. Ten hours of real work, gone. Now multiply that by the number of recurring meetings on your calendar this week. Feel sick yet?

But the damage goes deeper than time. Meetings breed performative productivity. People talk to be heard, not to move work forward. Decisions get made by whoever shouts loudest, not whoever thought hardest. Introverts, careful thinkers, and anyone who needs time to process information get steamrolled. The meeting ends with a vague consensus nobody actually agreed to, and everyone leaves drained. This isn’t collaboration. It’s group therapy for the indecisive.

Async Communication Is a Skill, Not a Tool

When people hear “async-first,” they picture Slack messages at 2 a.m. and a chaotic trail of threads nobody reads. That’s not async. That’s just synchronous communication with a time delay and worse formatting. Real async communication is structured, thoughtful, and designed for consumption by humans who aren’t occupying the same mental space as you.

An effective async update has a clear decision requested, context that doesn’t assume the reader attended the last three meetings, and a deadline for input. It’s not a brain dump. It’s a crafted artifact. Writing it forces clarity. Reading it allows processing time. The result? Better decisions made by people who actually had a moment to think.

This shift demands a cultural change, not just a tool swap. It means rewarding written communication skills. It means managers stop reaching for “can we jump on a quick call” as their first resort. It means treating uninterrupted time as sacred, not as empty space to fill with another sync.

Which Meetings to Kill First

Not all meetings deserve the axe. But plenty do. Start with the ones that exist purely out of habit.

Daily Standups That Are Just Status Dumps

If your standup is a round-robin where each person recites what they did yesterday and what they’ll do today, kill it. That information belongs in a channel, a thread, or a tool. The only reason to stand in a circle—physical or virtual—is to surface blockers and coordinate unblocking. If nobody has a blocker, end the meeting in 90 seconds. If people are just reporting status to a manager, that manager needs to learn to read.

Planning Meetings That Should Be Documents

Technical planning doesn’t need a conference room. It needs a collaborative document, a deadline for comments, and a final review window. Async planning produces better designs because people have time to think through edge cases instead of nodding along to avoid extending the meeting. The loudest-voice problem disappears. The document becomes the source of truth, not someone’s hazy memory of what was said.

“Sync” Meetings That Sync Nothing

If a meeting title contains the word “sync,” “alignment,” or “touch base,” assume it’s worthless until proven otherwise. These meetings are often therapy sessions for managers who feel out of the loop. The cure is better written updates, not stealing an hour from six engineers. If a manager can’t stay informed through async channels, the problem is the manager’s information diet, not the team’s communication frequency.

Building an Async-First Engineering Culture

Shifting to async isn’t about installing a new tool. It’s about changing defaults. The default for sharing information becomes a document, not a meeting. The default for getting feedback becomes a comment thread with a deadline, not a calendar invite. The default for decision-making becomes a written proposal with a clear owner, not a group discussion that diffuses responsibility.

This requires explicit norms. Here are a few that actually work:

• No-meeting blocks. Every engineer gets at least four contiguous hours per day with zero meetings. This is non-negotiable. It’s protected by the team, not just by individual calendar blocks that others ignore.
• Writing-first proposals. Any technical decision affecting more than two people starts as a written document. Discussion happens in comments. A meeting only happens if the async thread deadlocks—and that should be rare.
• Decision deadlines. Async discussions need end dates. “Please provide input by Thursday 5pm. Decision will be made Friday morning.” Without deadlines, async threads become zombie discussions that stagger on forever.
• Recording and notes for any meeting that survives. If a meeting absolutely must happen, it gets recorded. Written notes get posted within two hours. People who weren’t there can catch up without scheduling a second meeting to recap the first one.

The Manager’s Role in Killing Meetings

Managers are often the biggest source of unnecessary meetings. Not because they’re malicious, but because their job involves coordination and they default to the easiest coordination method: getting everyone in a room. Breaking this habit requires managers to do harder work. Writing clear context. Reading threads thoroughly. Trusting that work is happening even when they can’t see it in real time.

A good engineering manager in an async culture spends more time editing documents than attending meetings. They amplify signals, not noise. They protect their team’s focus time like a bouncer at an exclusive club. If someone tries to schedule a meeting that could be an email, the manager pushes back. If a stakeholder demands a “quick sync,” the manager asks for an agenda and a written summary first.

This is uncomfortable at first. People will complain that they feel “out of the loop.” That’s a sign the written communication isn’t good enough yet, not a sign that you need more meetings. Fix the writing. Don’t add the meeting.

When Meetings Actually Make Sense

Let’s be fair. Some problems are genuinely synchronous. Complex debugging sessions where two brains on one screen find the bug faster. High-stakes incident response where seconds matter. Relationship-building conversations where tone and trust can’t be conveyed in text. Creative brainstorming where the energy of rapid back-and-forth sparks ideas that wouldn’t emerge in a comment thread.

The key is intentionality. A meeting should be the exception, not the rule. It should have a clear purpose, a tight agenda, and a defined outcome. It should end the moment that outcome is achieved, not when the calendar slot expires. And it should be scheduled sparingly, like a surgery, not like a daily vitamin.

What Happens When You Actually Cut Meetings

Teams that go async-first report the same things. Ship velocity increases. Engineers report higher job satisfaction. Design quality improves because people have time to think. Decisions stick because they were made deliberately, not in a rushed Zoom call where half the participants were checking Slack.

But the most interesting change is cultural. The team stops equating responsiveness with competence. The engineer who replies to a thread six hours later with a thorough, well-reasoned analysis is valued more than the one who fires off a half-baked opinion in real time. Deep work becomes the norm, not a luxury. The calendar stops being a weapon and starts being a tool.

This doesn’t mean the team goes silent. It means communication becomes richer, more deliberate, and more respectful of everyone’s time and cognitive load. The loudest voice loses its power. The best ideas win. And that button text debate? It happens in a document, takes ten minutes of reading, and ends with a decision that everyone can reference later. No meeting required.

Frequently Asked Questions

Won’t async communication slow down decision-making?

Only if you measure speed by how fast someone says something, not by how fast a good decision gets made and implemented. Synchronous meetings create an illusion of speed—a decision is “made” in 30 minutes—but that decision often unravels over the following days as people realize they didn’t actually agree or think through the implications. Async decisions take slightly longer to reach but dramatically less time to stick. Net speed goes up.

How do we handle urgent issues without meetings?

Urgent issues get urgent channels. A dedicated incident Slack channel with clear roles, a running document, and an optional voice bridge for those actively debugging. The key distinction: only people directly working the problem are synchronous. Everyone else follows along async. This prevents the common disaster pattern where fifteen people join a call and fourteen of them are just watching.

What if our company culture just loves meetings?

Culture is just a collection of habits reinforced by what leaders tolerate. If your company “loves meetings,” it’s because nobody with authority has said “this is wasteful” and meant it. Start small. Kill one recurring meeting and replace it with a written update. Show the results. Engineers will defend the new free time with their lives. Culture changes when the alternative is obviously better, not when someone gives a presentation about it.

Don’t junior engineers need more face time for mentoring?

Yes, mentoring benefits from synchronous interaction. But that’s a one-on-one or small group activity, not a team-wide meeting. Pair programming, scheduled office hours, and dedicated mentoring sessions are valuable. Dragging six junior engineers into a planning meeting where they say nothing is not mentoring. It’s hazing.

Here’s a scene. You stumble on a job listing for a senior backend developer. The description is a clean, honest brief: they need someone to refactor a monolithic payment system before it buckles under traffic, tune PostgreSQL queries that currently run longer than a lunch break, and probably untangle ten years of spaghetti left behind by engineers who fled into management. You read it and think, “Yeah, I can do that. I’ve done that. I still have the scars.”

You apply. What comes next isn’t a conversation about indexing strategies or the trade-off between eventual consistency and screaming at your monitor. What comes next is a gauntlet of puzzles that feel like they were designed by someone who skimmed a hiring book once and then got creative with the torture. You’re asked to invert a binary tree on a whiteboard while three engineers stare at you, silently judging your handwriting. You get a take-home assignment to build a miniature social network, complete with a chat feature, because apparently the company’s actual product isn’t enough work for anybody. You sit through a “cultural fit” interview where someone asks which animal you’d be, and you have to fight the urge to say “a vulture, because I’m circling this process.”

This is technical hiring right now. It’s a cargo cult of complexity, a ritual performance that has almost completely detached from the actual job. We’re not testing for competence. We’re testing for endurance, for a narrow kind of trivia recall, and for the ability to smile while being hazed. The problem isn’t just that these processes are annoying. The problem is that they actively select for the wrong people and filter out the exact engineers you claim you need.

The Whiteboard Theater

Let’s start with the classic: the whiteboard coding interview. The premise is simple. Strip an engineer of their tools—no IDE, no Stack Overflow, no docs, no quiet room, no time to think—and ask them to solve an algorithmic puzzle that has nothing to do with the job. Then judge their fitness for a role building maintainable, production-grade systems based on this performance.

This is like testing a chef by making them butcher a live pig in the dining room while you watch, then hiring them to run your pastry station. The skill being tested is not the skill being bought. The environment is a parody of the actual work environment. The pressure is fake. And the problems are often pulled straight from a canon of puzzles that have been circulating for years, which means you’re not even testing problem-solving ability—you’re testing whether the candidate recently crammed “Cracking the Coding Interview” or grinded LeetCode until their eyes bled.

I’ve watched brilliant systems engineers, people who can debug a kernel panic at 3 AM while half-asleep, get rejected because they couldn’t reverse a linked list on a whiteboard in 20 minutes. When, in the entire history of paid employment, has anyone ever needed to reverse a linked list from memory while a stranger watches? The standard library exists. The internet exists. The ability to say “I’d look that up” exists, and it’s a sign of wisdom, not weakness.

The whiteboard interview doesn’t test engineering. It tests performance art. It selects for people who are good at whiteboard interviews. And then we wonder why our teams are full of people who can recite Dijkstra’s algorithm but can’t write a maintainable module to save their lives.

The Take-Home Project That Ate My Weekend

Then there’s the take-home assignment. On the surface, this seems more reasonable. “Here’s a small problem, go solve it on your own time, with your own tools, and we’ll discuss it.” Sounds fair. Sounds like it might actually resemble work.

But in practice, these assignments metastasize. I’ve seen “small” take-home projects that are essentially unpaid consulting gigs. “Build a URL shortener with analytics, a REST API, an admin dashboard, and deploy it to AWS with a CI/CD pipeline.” That’s not a weekend project. That’s a product. And you’re supposed to do it after your actual job, while also maybe seeing your family or sleeping.

The unspoken expectation is that you will spend 20, 30, 40 hours on this thing. The company gets free labor, a dozen candidates all building variations of the same system, and the hiring manager gets to pick the one who had the most free time and the least boundaries. It’s a filter for desperation, not skill. The best engineers I know would look at a 40-hour take-home assignment and laugh, then go back to their actual lives. The ones who complete it are often the ones with something to prove—which isn’t always bad, but it’s not the same as being good at the job.

And then, after you submit your meticulously crafted project, what happens? In many cases, nothing. You get ghosted. Or you get a one-line rejection two weeks later. No feedback. No discussion. Your weekends, sacrificed to the hiring gods, vanish into the void. This isn’t just disrespectful; it’s a signal that the company doesn’t value your time, which is a pretty good preview of what working there would be like.

The Cultural Fit Inquisition

Ah, culture fit. The phrase itself should make your skin crawl. Ostensibly, it’s about ensuring a new hire won’t disrupt the team’s harmony. In practice, it’s a euphemism for “is this person like us?” And “like us” often means “went to the same schools, shares the same hobbies, and won’t challenge our comfortable assumptions.”

I’ve sat in on culture fit interviews where the questions were so vague and subjective that the decision came down to whether the candidate seemed “sharp” or “enthusiastic” or “a good hang.” These are not job criteria. These are vibes. And vibes-based hiring is how you build a monoculture of agreeable mediocrity.

The irony is thick enough to spread on toast. We claim to want diversity of thought, but we hire for conformity of personality. We say we want people who will push back, who will tell us when we’re wrong, but we reject anyone who doesn’t laugh at our jokes or who seems a little too intense about code quality. The best engineers I’ve worked with were often prickly, opinionated, and deeply weird. They cared about the work, not about being your drinking buddy. And they were invaluable precisely because they didn’t fit the mold.

When you hire for culture fit, you’re not building a team. You’re building a clone army. And clone armies are great at following orders and terrible at innovation.

The Trivia Gauntlet and the Hazing Ritual

Some companies favor the trivia approach. You sit in a room, or on a video call, and a panel of engineers fires questions at you like a verbal pop quiz from hell. “What’s the difference between a process and a thread?” “Explain the CAP theorem.” “What’s the time complexity of a hash map lookup?” “How does garbage collection work in the JVM?”

These questions have answers that can be memorized in an afternoon. They test recall, not understanding. They test whether you’ve recently reviewed a “Top 50 Interview Questions” blog post, not whether you can design a system that handles 10,000 requests per second without catching fire.

And then there’s the hazing element. The questions get harder, more obscure, until the candidate breaks. The panel isn’t trying to find the candidate’s ceiling; they’re trying to find the floor, and then push them through it. It’s a dominance display. “Look how much smarter we are than you.” It’s the engineering equivalent of a fraternity paddle, and it selects for people who are either good at trivia or good at pretending to be humble while being humiliated. Neither of those traits correlates with being a productive colleague.

What We Should Be Testing

So if all of this is broken, what does a sane hiring process look like? It looks like the actual job. Shocking, I know.

If you’re hiring someone to refactor a payment system, give them a small, anonymized piece of a payment system and ask them to refactor it. Pair with them. Let them use their tools. Let them talk through their thought process. Watch how they navigate ambiguity, how they ask questions, how they handle not knowing something. That’s the job. That’s what you need to evaluate.

If you’re hiring someone to lead a team, have them lead a discussion about a real technical decision your team is facing. See how they listen, how they synthesize different viewpoints, how they handle disagreement. Don’t ask them to estimate how many golf balls fit in a school bus. That’s not the job. That’s a party trick.

If you’re hiring someone to write maintainable code, look at code they’ve written. Ask them to walk you through a project they’re proud of and a project they’re not proud of. Listen to how they talk about trade-offs, about mistakes, about what they’d do differently. That tells you more about their engineering judgment than any whiteboard puzzle ever could.

The goal of an interview should be to simulate the work, not to simulate a hazing ritual. It should be collaborative, not adversarial. It should respect the candidate’s time and intelligence. And it should be designed by people who actually do the job, not by people who read a book about how Google did it in 2007.

The Real Cost of Bad Hiring Processes

Bad hiring processes aren’t just annoying. They’re expensive. They waste the time of your existing engineers, who have to sit in on these circus acts instead of doing actual work. They drive away good candidates who have options and self-respect. And they select for a very specific kind of engineer: the kind who is good at interviews.

Being good at interviews is a skill. It’s a skill that correlates loosely, at best, with being good at engineering. It correlates strongly with having a lot of free time to practice LeetCode, with being early in your career before burnout sets in, and with being willing to tolerate arbitrary nonsense without complaint. None of these are the traits you want in a senior engineer who will own critical systems and tell you when you’re being an idiot.

The engineers you actually want are the ones who will look at your six-hour take-home project and say, “No, thank you.” They’re the ones who will push back on your whiteboard puzzle and ask, “How is this relevant to the work I’d be doing?” They’re the ones who have enough experience and enough options that they don’t need to jump through your hoops. And by designing a process that filters them out, you’re left with the hoop-jumpers. And then you wonder why your codebase is a mess and nobody will tell you the truth.

The Fix Is Cultural, Not Procedural

Here’s the uncomfortable part. The reason these hiring practices persist isn’t that nobody knows better. It’s that they serve a psychological function. They make the interviewers feel smart. They create a barrier to entry that makes the club feel more exclusive. They provide a false sense of rigor, a checklist that can be pointed to when a hire goes wrong: “Well, they passed the algorithm gauntlet, so it’s not our fault.”

Fixing this requires admitting that our process is theater. It requires humility from the people designing and conducting interviews. It requires saying, “I’m not sure how to test for what we actually need, but I’m willing to figure it out instead of defaulting to what everyone else does.” That’s an engineering problem. It’s a design problem. And it’s exactly the kind of problem we claim to be good at solving.

Start small. Pick one role. Design an interview loop that mirrors the actual work. Use real problems, not puzzles. Pair with the candidate. Give them a laptop, not a whiteboard. Pay them for take-home work if it’s more than a couple of hours. Give feedback, even if it’s brief. Treat candidates like humans whose time matters. See what happens.

I’ll tell you what happens. You start hiring engineers who can actually do the job. Your team gets stronger. Your interview process becomes a selling point instead of a warning sign. And you stop wasting everyone’s time on a ritual that benefits no one except the people who sell interview prep courses.

FAQ

Why do companies still use whiteboard interviews if they’re so bad?

Because they’re easy to standardize and hard to challenge. A whiteboard puzzle gives a numerical score, or at least a pass/fail signal, that feels objective. It lets companies process hundreds of candidates without thinking too hard about each one. It’s the fast food of hiring: consistent, scalable, and nutritionally void. Changing it requires effort and a willingness to trust human judgment, which terrifies large organizations.

What’s a better alternative to the take-home project?

A paid, time-boxed work simulation. Give the candidate a real, scoped problem that takes 2-3 hours. Pay them for their time. Let them use their own environment. Then have a conversation about what they built, why they made certain choices, and what they’d do with more time. This respects their schedule, tests the actual skills, and gives you a much richer signal than a 40-hour unpaid marathon ever could.

How do you assess “culture fit” without turning it into a popularity contest?

Define what you actually mean by culture. If you mean “shares our values around code review and testing,” then ask about their experiences with code review and testing. If you mean “communicates well during disagreement,” then have a structured discussion about a contentious technical decision and see how they handle it. Make it about behaviors, not personalities. And if you can’t define your culture in terms of observable behaviors, then your culture is just “people we like,” and you should admit that and deal with the consequences.

Isn’t it risky to skip the hard technical screening? What if we hire someone who can’t code?

The risk is that your current screening doesn’t actually prevent that. Plenty of people who pass whiteboard gauntlets and trivia quizzes still can’t code their way out of a paper bag when faced with a real system. A work-sample test—where you watch someone code a real problem in a real environment—is a far better guard against incompetence than any puzzle. And if you’re worried about missing something, remember that you have a probation period. That’s your safety net. Use it.

Look, I get it. Hiring is hard. It’s scary. A bad hire can set a team back months. But the solution isn’t to add more filters; it’s to add the right filters. And the right filters look a lot like the job you’re hiring for. Everything else is just noise, ego, and wasted weekends. Let’s stop pretending that making someone suffer through an irrelevant gauntlet tells us anything useful. Let’s start treating hiring like the engineering problem it is.