We're a month into fully remote enterprise delivery. Not by choice. The novelty is gone. The adrenaline is gone. What's left is the reality of delivering complex software for enterprise clients from our living rooms, spare bedrooms, and in one case, a garden shed. Here's what we've learned about what actually works.
What You Need to Know
- Remote enterprise delivery works, but it requires deliberate structure that co-located teams take for granted
- Asynchronous documentation became more important than any single tool
- The biggest failure mode is communication degradation, not productivity loss
- Client relationships need more intentional contact, not less
The Tools That Survived
We tried a lot in the first week. Slack. Zoom. Microsoft Teams (for clients who mandated it). Miro for whiteboarding. Loom for async walkthroughs. Notion for documentation.
A month in, the stack has simplified. Not because tools are bad. Because too many tools fragment attention.
Slack for quick communication. Channels per project, strict threading, no DMs for anything project-related. If it's in a DM, it doesn't exist for the team.
Zoom for synchronous meetings. Cameras on by default. Not to monitor people. Because facial expressions carry information that voice alone doesn't. When someone is confused in a design review, you can see it.
Git and CI/CD didn't change at all. Our deployment pipeline doesn't care where we are. This was the easiest part of the transition, which tells you something about the value of investing in good engineering infrastructure before you need it.
74%
of NZ businesses adopted new digital tools during lockdown
Source: MBIE, Digital Boost Survey, April 2020
The Rituals That Work
Morning Standup (15 Minutes, Non-Negotiable)
Same time every day. Video on. Three questions: what did you do yesterday, what are you doing today, what's blocking you. We've done standups for years. Remote made them essential rather than useful. It's the only guaranteed moment when the whole team sees each other.
Async Design Reviews
We stopped doing synchronous design reviews. Instead, the designer records a five-minute Loom walkthrough of the design, posts it in the project channel, and the team comments over the next four hours. The quality of feedback improved. People have time to think before responding instead of reacting in real time.
The best remote meetings are the ones you replace with a document. Save the synchronous time for decisions that need discussion.
John Li
Chief Technology Officer
Friday Retros (30 Minutes)
End of every week, the team reviews what worked and what didn't. These existed before. Remote made them sharper. There's less social padding on video calls, which means people get to the point faster. We've made more process improvements in the last month than in the previous quarter.
What Broke (And How We Fixed It)
Spontaneous Architecture Discussions
In the office, our best technical decisions happened informally. Someone would sketch on a whiteboard. Three people would gather. A decision would emerge in twenty minutes. Remote killed that pattern.
The fix: scheduled "open architecture" sessions twice a week. No agenda. Anyone can bring a problem. It's not the same as spontaneous discussion, but it's a deliberate substitute. The first few sessions felt forced. By week three, they were generating real value.
Junior Developer Mentoring
Our junior developers learn by proximity. Sitting next to a senior developer, watching how they debug, hearing their thought process in code review. That ambient learning disappeared entirely.
We paired each junior with a senior for daily thirty-minute sessions. Not code review. Pairing. Working on the same problem together, screen shared, talking through decisions. It takes senior time. It's worth it. Losing a junior developer to isolation and stalled growth costs more.
Client Visibility
Enterprise clients want to know their project is progressing. In the office, that happened through regular meetings and the general confidence that comes from knowing a team is together, working. Remote removed that confidence.
We increased client touchpoints from weekly to twice-weekly for the first month. Short calls. Fifteen minutes. "Here's where we are, here's what's next, here are the risks." Some clients relaxed after two weeks and went back to weekly. Others appreciated the extra contact and kept it.
The Productivity Question
Everyone asks: is remote more or less productive? The honest answer: it depends on the work.
Deep focus work, writing code, designing interfaces, writing documentation, is more productive at home. Fewer interruptions. Longer focus blocks. Our code output per developer is measurably higher.
Collaborative work, design critiques, requirements discussions, architectural decisions, is harder. Not impossible. But it takes more deliberate effort and more time. A decision that took twenty minutes at a whiteboard takes forty-five minutes over video.
The net effect is roughly neutral. We're producing the same output. The distribution of effort has shifted.
What We'd Tell Other Teams
Start with documentation. If your processes aren't written down, they'll fragment within a week. Every ritual, every convention, every "everyone knows this" needs to be explicit.
Protect your team's energy. Remote work blurs the boundary between work and life. People will overwork without realising it. Build hard stops into the day. We close Slack at 6pm. Not as a rule. As a culture.
Trust your team. If you need to monitor people to believe they're working, you have a hiring problem, not a remote work problem.