A Year of Remote Engineering, Now What

Last June, eight weeks into pandemic remote, I wrote that remote was better for deep work but worse for everything else. The post argued that focused individual contributors were getting more done, that mentorship and cross-team coordination were suffering, and that the hybrid future was going to need to be designed deliberately or it would default to the worst of both worlds.

A year of real data later, that post mostly held. I want to take an honest look at what aged well and what didn't, because the second draft of remote engineering is being written this quarter at every mobile org I know about, and the assumptions we made last summer are now load-bearing decisions for the next decade.

What held up

The deep-work part held. Engineers doing focused individual work, especially on architecture, refactoring, and debugging hard production issues, are shipping more of it than they were in 2019. The discourse confirms this from multiple angles. Cal Newport's New Yorker piece from last May called out software engineering as the function that was unusually well-positioned for remote, because Scrum and Kanban had given engineers structured async workflows years before the rest of knowledge work needed them. His framing held up. When the work is well-defined and the artifact (a PR, a design doc, a runbook) is the unit of coordination, remote engineering is materially better than open-office engineering for most engineers most of the time.

The other thing that held: the people who hated remote were largely the people whose jobs were 80% coordination, and the people who loved it were largely the senior individual contributors who had been quietly resenting the open-office for years. That bimodal reaction has not narrowed. If anything, it has hardened. Junior engineers and the most coordination-heavy managers are tired in ways the senior ICs are not, and the reasons are structural, not vibes.

What I got wrong, part one: meeting creep is eating the deep-work win

In June 2020 I assumed the meeting load would decline as teams adjusted. The exact opposite happened.

Microsoft Research's "New Future of Work" report from last month is the most rigorous one-year-in document I have read. They synthesize fifty-plus internal studies. Among other things, they document that the natural transitions between meetings (the walk from one conference room to another, the elevator ride, the bio break) have collapsed into back-to-back Zoom calls with no buffer. People are running at higher meeting density than they were in 2019. The deep-work hours per engineer have not gone up the way the calendar-time available for deep work suggested they should.

The Future Forum survey work from Slack (October's Remote Employee Experience Index, and the January 2021 "Hybrid Rules" followup) confirms the meeting-load story from a different angle. The deep-work surplus is being eaten by meetings that exist mostly to perform "we are still a team" anxiety. Status meetings that used to be a quick standup are now thirty-minute calls. Cross-team syncs that used to happen organically at lunch are now formal calendared events. The status-update load went up, not down.

I should have predicted this. The base-rate of any large organization's response to ambiguity is to schedule meetings. Remote made everything ambiguous overnight. Of course meeting load went up.

The fix is not "fewer meetings." Telling teams to have fewer meetings is the same kind of advice as telling them to write better code. The fix is structural. Async-first defaults, written decisions, recording the meetings you do have so people who weren't there can catch up without scheduling another one. The teams that have done this work are noticeably calmer than the teams that haven't.

What I got wrong, part two: mid-level engineers are losing more than I expected

This is the one I underestimated badly.

In June 2020 I worried about new hires onboarding and about senior-junior mentorship. I treated mid-level engineers as basically fine. They have the skills, they know the codebase, they can mostly do their work. Remote should not hurt them much.

A year in, the mid-levels are the population I am most worried about. Not because their on-paper output dropped. It hasn't. The problem is what I would call career-development loss: the work that grows a mid-level engineer into a senior engineer is not the same work that mid-level engineers can do alone in their home offices.

Microsoft Research's report has a passage I keep going back to. They document that junior employees specifically struggled to "gain turns at talk or have their presence noticed" in remote meetings, making hierarchies more conspicuous, not less. The data is on juniors, but my hypothesis from watching my own teams is that the pattern extends up to mid-level. I cannot prove that with cited data yet. I am calling out the pattern I am seeing because the implications, if it holds, are large enough that the engineering leadership conversation needs to start now. Mid-level engineers in 2019 grew by being in the room when senior engineers made architecture calls, by overhearing the cross-team friction conversations, by being asked to weigh in on something that wasn't formally their problem because they happened to be at the table. None of that happens reliably in a remote org. You have to deliberately design it back in, and most teams haven't.

I am watching mid-level engineers on the iOS teams I have visibility into stagnate at the mid-level in ways they would not have in 2019. They are still shipping. They are not stretching. The structural growth path that used to be automatic has become something a manager has to actively engineer, and the managers who are good at engineering it are rare.

This is the failure mode that worries me most for 2021. If the cohort of engineers who would have been the seniors of 2024 instead spends 2021 and 2022 stuck at mid-level because nobody designed the growth conditions for them, we are going to have a senior pipeline problem that doesn't show up for three years and is structurally hard to fix when it does.

The hybrid that should not happen

The two-track hybrid is the version I most want to argue against. The model where some people come to the office and some don't, and meetings happen in conference rooms with three people in person and four people dialing in from home. This is the worst design.

Dropbox's Virtual First announcement from October is the cleanest articulation of why. The post makes the case that traditional hybrid creates two different employee experiences and disproportionately affects performance and career trajectory along the in-person-vs-remote line. Virtual First's solution is to make individual work remote by default and use physical Studios for collaboration only, with everyone in the same modality at the same time. I think the framing is right and I think the execution is going to be the hard part.

Future Forum's January data backs the structural concern. Workers who are remote while their managers are co-located feel pressure to prove they're working at materially higher rates than co-located workers. That's proximity bias measured. If you let hybrid default to "show up if you want," the people who show up will be disproportionately rewarded over time, and the people who don't show up will increasingly be the populations with the most reason to want flexibility: parents, caregivers, people with disabilities, people who can't afford to live close to the office. The equity argument that ran through Future Forum's REEI is not abstract. It is what happens when you let hybrid evolve without designing it.

The honest case for some in-person time

I'm not going to land the post as "everyone should be fully remote." That's also wrong.

There is real value in some amount of in-person collaboration that I have not been able to replicate remotely in twelve months of trying. The off-site that resets a team. The whiteboard architecture session for a hard design problem. The week of intense pair-programming when a complex system is being built. These are not impossible remote. They are noticeably worse remote. The teams that have done deliberate quarterly in-person off-sites during the pandemic windows when health conditions allowed are visibly stronger than the teams that haven't.

The model I would design for 2021 if I were running a mobile platform team: remote-default for all individual work, in-person quarterly for two-to-three-day off-sites with explicit collaboration goals, and a deliberate effort to design mid-level career growth conditions back into the remote workflow. None of these are revolutionary. All of them are hard to execute well.

What I'd tell engineering leaders this quarter

Three things, in the order of leverage.

Audit your mid-level career development. Specifically: which of your mid-level engineers grew into senior responsibilities in the last twelve months, and what specific work did they do that grew them. If the honest answer is "fewer than I expected and I don't really know what worked," that is the conversation to have with your skip-levels this quarter.

Cut the meeting load deliberately. Pick a quarter to do a meeting purge. Cancel everything that doesn't have a clear async-decision alternative. Re-add only what actually needs to be live. Most teams discover that a meaningful fraction of their meeting time was performance, not work.

Decide on hybrid before it decides for you. If your eng leadership has not made an explicit hybrid policy by Q3, the policy will be made by the loudest senior engineers showing up and quietly pulling the org with them. That is the proximity-bias trap. Make the call deliberately or you will get the worst version by default.

Where I land

The June 2020 take held on the big claim. Remote engineering is better for deep work and worse for the parts of engineering that aren't deep work. The shape that's emerged in twelve months is sharper than I had it: meeting creep is eating the deep-work surplus, and the career-development pipeline for mid-level engineers is the structural problem that's going to bite in 2024.

The teams that design for those two specific failure modes this year are going to look very strong in three years. The teams that don't are going to find themselves with the same mid-level population they had in 2019, three years older, and a thin senior bench they didn't see coming.

Year two is not "go back to normal." It is "design the thing intentionally," and most organizations have not started.