Every few months some startup with a meditation room and a Series A publishes a manifesto about why their distributed workforce is the future of work. The blog post goes viral. People who have never managed anything larger than a Notion document retweet it. And somewhere, in a physical office with actual engineers in it, someone ships something that works.
Ribbit.
The reason an office matters is the same reason you don't develop production software by emailing patches. Latency kills momentum. When an engineer hits a design question and has to type it into Slack and wait four hours for a response, they context-switch. They check Twitter. They start another ticket. The question rots. Four hours later the answer arrives but the moment has passed. They'll deal with it tomorrow. Tomorrow comes and the thread is buried under three standup bot notifications and a GIF of a dancing badger.
In an office, you turn to your left and say "does this interface make sense?" and the person says "no, you've got the wrong abstraction" and you fix it in thirty seconds. That is not serendipity. That is latency measured in seconds instead of hours. That is the difference between a project that ships and a project that accumulates Slack threads.
Software is made of decisions. The faster you make them, the faster you discover which ones were wrong. Offices compress the decision loop. Remote work stretches it. A stretched loop doesn't produce better decisions. It produces the same number of decisions spread over more calendar time, padded with status update meetings to simulate visibility.
Every effective remote worker I have met — and I have met several — learned their craft in a room with other people. They absorbed norms. They overheard debugging sessions. They watched a senior engineer delete three hundred lines and replace them with twelve. You cannot overhear anything on Zoom. There is no ambient learning. There is only scheduled learning, and scheduled learning is just school, and school is where you go before you know how to do the job.
Remote work is a privilege earned by experience. It is not a starting condition. If you put a junior engineer in a flat with a laptop and a documentation wiki, you have not hired an engineer. You have subscribed to a very slow, very expensive correspondence course.
Mrs Froggy, who has built distributed teams across four time zones and has the conference speaking fees to prove it, will tell you that remote teams work when the processes are right. She is correct. The processes can be right. The documentation can be thorough. The async rituals can be disciplined. It is possible.
It is also expensive. It requires writing everything down, which good teams do anyway, but it also requires writing down everything that a co-located team absorbs for free: context, norms, tacit knowledge, the reason Sarah picked Postgres over Mongo in 2024. Most organisations cannot afford the documentation overhead. They think they can. They cannot. What they can afford is a room with desks in it.
Mrs Froggy and I agree on the destination. We disagree on the cost of the journey and how many organisations are actually paying it.
Rib IT Ltd has an office. It is not a pond with a server rack. It is a room with desks, whiteboards, and people in it. Every engineer works from the office five days a week. Not because I enjoy controlling where adults sit — I am a frog, I have better things to do — but because it produces better engineering, faster.
Remote work is not evil. It is a specialist mode of operation that requires process maturity most organisations do not have and will not invest in. What most organisations call "remote-first" is actually "we closed the office in 2020 and never reopened it because the CFO noticed the lease savings and nobody wants to be the one who suggests coming back."
The office is not a perk. It is infrastructure. It is the build server for decisions. If your software delivery pipeline required every commit to wait four hours for CI feedback, you would fix the pipeline. Why do you tolerate that latency on every design conversation?
Come to the office. Build things. Write it down afterwards. Go home.
Rib rib rib.
Froggy is CEO, CTO, CFO, and sole Distinguished Fellow of Rib IT Ltd. He works from the office every day. Mrs Froggy's latest book, "Distributed Teams Don't Need Your Pity, They Need Your Process," makes several excellent points he politely ignores.