The COVID Hangover Is Killing Your Engineering Velocity

You’ve optimised everything. Your CI/CD pipeline runs in minutes. Your monitoring dashboards would make a NASA control room jealous. Your team uses the latest async collaboration tools money can buy. And yet somehow, that integration that should have taken a week has been bouncing back and forth across time zones for a month.

Here’s a question that might sting: when was the last time you actually walked over to someone’s desk to solve a problem?

As the legendary basketball coach Phil Jackson observed, “The strength of the team is each individual member. The strength of each member is the team.” He won eleven NBA championships not by sending memos between players, but by putting them in the same room, in the same rhythm, solving problems together. We’ve somehow convinced ourselves that engineering is different — that our problems are so complex they require careful asynchronous contemplation rather than two people sketching on a whiteboard.

We’re wrong.

The Async Addiction

Since 2020, we’ve developed what I call the “COVID hangover” — a persistent, low-grade organisational dysfunction left over from when remote work went from emergency measure to default mode. We got very good at asynchronous communication. Too good. So good that we forgot how to work any other way.

Don’t misunderstand me — async has its place. Time zone differences are real. Deep work requires focus. Documentation matters. But somewhere along the way, we crossed a line from “async when necessary” to “async by default.” And that default is costing us dearly.

Consider the typical cross-team collaboration in 2024. You post a question in Slack. The other person sees it two hours later, asks a clarifying question. You respond the next morning. They’re in a meeting all afternoon. By the time you’ve actually understood each other’s context, three days have evaporated. And that’s for a simple question. For anything requiring back-and-forth, iteration, or shared understanding, multiply accordingly.

The physicist Richard Feynman once described the joy of scientific collaboration as “the pleasure of finding things out together.” Notice the word together. Not “the pleasure of finding things out in sequential Slack messages separated by timezone delays and context switches.”

The Experiment

Recently, we ran an experiment. We brought about twenty-five engineers from multiple companies into the same physical space for five days. External partners working on open source tooling, internal teams working on infrastructure adoption. No detailed project plans. No elaborate roadmaps. Just people with related problems in the same room with one simple instruction: walk over and talk to someone.

The philosophy was deliberately low-tech: if you’re stuck, don’t post in a chat channel. Find a person who might know the answer. Sit down together. Figure it out.

What happened? Problems that would have taken weeks of back-and-forth resolved in hours. Knowledge that usually stays trapped in one person’s head spread naturally through pairing and impromptu whiteboard sessions. Engineers who had only seen each other’s names on pull requests suddenly understood each other’s context, constraints, and quirks.

By the end of the week, we’d shipped production changes, contributed fixes back to open source projects, and built prototypes that had been languishing in “we should really do that someday” territory for months. One engineer noted that a blocker they’d been wrestling with via async communication “was fixed within ten minutes” once they could sit next to the right person and actually show them what was happening.

The Math Doesn’t Lie

Let’s do some rough calculations. A typical async exchange for a moderately complex technical question:

Initial message: 5 minutes to composeWait time: 2–8 hoursClarifying question: 5 minutesWait time: 2–8 hoursActual answer: 10 minutesFollow-up: repeat cycleTotal wall-clock time: 1–3 days. Total productive engagement: maybe 30 minutes.

The same exchange in person:

Walk over: 30 seconds“Hey, got a minute?”Actual conversation with back-and-forth: 15 minutesTotal wall-clock time: 15 minutes. Plus, you’ve built a relationship, transferred tacit knowledge, and probably discovered two related issues you didn’t know you had.

As the economist Ronald Coase demonstrated in his work on transaction costs, the friction of coordination often matters more than the work itself. We’ve spent enormous effort reducing the cost of communication — instant messaging, video calls, collaborative documents — while somehow increasing the actual friction of collaboration.

The Pattern We’ve Forgotten

Here’s what struck me most during the week. This is what working used to feel like. Before COVID, when everyone was in the office, you didn’t need special “collaboration weeks” to get people talking. You didn’t schedule “synchronous working sessions.” You just… worked. If you were waiting for a code review, you’d walk over to someone’s desk. If you were stuck on an architecture question, you’d grab the person at the whiteboard next to the coffee machine.

The psychologist Mihaly Csikszentmihalyi, who coined the concept of “flow,” found that collaborative flow states — where a group becomes so absorbed in shared problem-solving that time seems to stop — are among the most productive and satisfying states humans can experience. These states are almost impossible to achieve asynchronously. They require physical or at least synchronous presence, shared context, and the ability to iterate in real-time.

We’ve traded flow for convenience. And we’re paying for it every day in velocity we don’t even know we’re losing.

The Generation That Never Knew

Here’s something that keeps me up at night: I have engineers on my teams who started their careers in 2020 or later. They’ve never experienced anything else. To them, async-first isn’t a pandemic adaptation — it’s just how work works.

I have genuine empathy for them. They’re not doing anything wrong. They’re operating exactly as their environment has taught them to operate. When you’ve only ever known a world where questions go in Slack and answers come back hours later, you don’t know there’s an alternative. You don’t know that the frustration you feel — that vague sense that everything takes longer than it should — isn’t inevitable. It’s a choice we’ve made as an industry, and it’s a choice we can unmake.

We’ve lost a muscle. Collaborative synchronous work — the ability to walk up to someone, establish shared context quickly, iterate in real-time, and reach a solution together — is a skill. Like any skill, it atrophies without practice. For some of our more experienced engineers, the muscle has weakened from disuse. For engineers who entered the industry during or after COVID, the muscle was never developed in the first place.

This isn’t a criticism. You can’t be expected to be good at something you’ve never had the opportunity to practice. But it does mean we need to be intentional about training — or in some cases, training for the first time.

Exercises like our collaboration week aren’t just about shipping code faster. They’re rehabilitation. They’re showing people what’s possible when you’re not waiting for the green dot to appear next to someone’s name. They’re building the reflexes that make someone think “I should walk over and ask” instead of “I should post in the channel and wait.”

The athlete and author Christopher McDougall wrote that “every morning in Africa, a gazelle wakes up knowing it must run faster than the fastest lion or it will be killed. Every morning, a lion wakes up knowing it must outrun the slowest gazelle or it will starve. It doesn’t matter whether you’re a lion or a gazelle — when the sun comes up, you’d better be running.” We’ve spent four years teaching our industry to walk. Now we need to remember how to run.

What Actually Works

I’m not advocating for a return to mandatory office attendance or abolishing remote work. The genie is out of the bottle, and flexibility has real value. But I am advocating for something more intentional: structured periods of intense synchronous collaboration.

Think of it like interval training for your engineering organisation. You can’t sprint continuously — that’s a recipe for burnout. But strategic bursts of high-intensity collaborative work can accomplish what months of steady async effort cannot.

Here’s what we learned actually works (in moderation):

Co-location with purpose. Don’t just put people in a room together. Put them in a room together with a shared problem and the authority to solve it. Remove the blocker of “we need approval from…” by ensuring decision-makers are either present or on-call.

Multiple touch points per day. We ran three stand-ups a day — morning, midday, and end-of-day. This sounds excessive until you realise that the point isn’t status updates, it’s coordination. When you’re moving fast and learning constantly, you need more frequent opportunities to redirect effort.

Shared meals. It sounds trivial, but eating together eliminates the natural breaks where people would normally scatter and context would be lost. Some of the best problem-solving happened over lunch, not at laptops.

Accept productive discomfort. The first day feels chaotic. There’s no detailed plan. People don’t know exactly what they should be working on. That discomfort is a feature, not a bug. It forces people to find problems and swarm them, rather than waiting for work to be assigned.

As one participant put it: “You kind of have to be comfortable being uncomfortable. And then at the end of the week, you look back — look at what all we did. For having very limited planning, we actually knocked so much stuff out.”

The Knowledge Transfer Bonus

There’s a side effect of intense collaboration that’s easy to miss: knowledge transfer happens automatically. When engineers pair on problems, when they work through issues together, when they explain their reasoning out loud — knowledge spreads.

In an async world, knowledge stays trapped. That one engineer who knows how the deployment system really works? They become a permanent bottleneck. The tribal knowledge about why that one service behaves strangely on Tuesdays? It never gets written down, and when that engineer leaves, it’s gone forever.

During our collaboration week, engineers who had never touched certain infrastructure before were contributing meaningful code within days. Not because they attended training sessions or read documentation, but because they sat next to someone who knew and asked questions in real-time. The context transfer that happens through proximity is remarkably efficient.

One engineer described the experience of working directly with maintainers of an open source project: “I never worked with open source owners that can just change stuff… we worked together on improving the lib. That was very cool for me — to see one of the guys that I always see on the internet, meet them in person.” That’s not just productivity — it’s the kind of engagement that makes engineers stay.

The Open Source Dividend

Something else happened that I didn’t fully anticipate. When you bring internal teams together with external partners and open source maintainers, you don’t just consume open source — you contribute back.

During the week, we didn’t just solve our internal problems. We identified bugs in shared tools and fixed them. We improved documentation that will help the entire ecosystem. We made commits to open source repositories that benefit everyone, not just our organisation.

As the software pioneer Eric Raymond wrote in The Cathedral and the Bazaar, “Given enough eyeballs, all bugs are shallow.” But you need those eyeballs in the same place, looking at the same code, at the same time. Async contributions trickle in. Synchronous collaboration floods.

The Leadership Question

If you’re an engineering leader, here’s the uncomfortable question: are you scheduling intense collaboration, or are you just hoping it happens?

Hope is not a strategy. Async work is the path of least resistance. Without deliberate intervention, your teams will default to Slack messages and scheduled meetings and careful documentation — all the trappings of collaboration without the substance.

Creating space for synchronous work requires investment. You have to bring people together, which costs money. You have to carve out time, which means saying no to other things. You have to accept that the first day or two will feel unproductive as people find their rhythm.

But the alternative is watching weeks of async back-and-forth accomplish what could be done in hours. The alternative is knowledge trapped in silos. The alternative is engineers who’ve worked on the same system for years and have never actually spoken.

The Bottom Line

The tools didn’t change during our collaboration week. The technology didn’t change.

What changed was proximity. We put people in the same room, pointed them at shared problems, and got out of the way.

The COVID hangover is real. We’ve forgotten how to work together. Not because we’re worse engineers, but because we’ve optimised so hard for async convenience that we’ve accidentally made actual collaboration harder.

You don’t need special tools for synchronous work. You don’t need new methodologies or frameworks or certifications. You need a room, a whiteboard, and the willingness to accept that sometimes the fastest path forward is just walking over and saying, “Hey, got a minute?”

What takes weeks on Slack gets done in hours when you’re sitting next to each other.

Now, if you’ll excuse me, I need to go schedule next quarter’s collaboration week. The Slack threads are piling up, and I’m starting to think maybe we should just talk instead.