I watched a CTO tell his fully remote team that he had an “open door policy.” He said it in a Slack channel. I sat there for a moment, staring at my screen, trying to work out where the door was.
He meant well. Of course he did. He was trying to say “I’m approachable, come to me with problems.” But what he actually created was a channel where three junior developers pinged him every time they hit a snag, two senior engineers never said a word until things were properly on fire, and he spent his entire day context-switching between half-conversations that could have been, and I’m sorry but it’s true, a Google search.
The open door policy is an office metaphor. And like most office metaphors applied to remote work, it doesn’t survive contact with reality.
You can’t copy-paste office leadership
Here’s something nobody tells you when you become a remote CTO: there’s no playbook. Or rather, there are hundreds of playbooks, and they’re all written by people who managed teams in offices and then bolted on a chapter about Zoom.
Malcolm Gladwell popularised the idea that roughly 10,000 hours of deliberate practice are needed to achieve mastery in a complex field [1]. I think about this a lot in the context of remote leadership, because the emphasis is on deliberate. Not 10,000 hours of doing the same thing. Not 10,000 hours of hoping your office instincts translate. Deliberate practice means paying attention to what’s different, experimenting, getting it wrong, and adjusting.
Remote leadership is a different discipline. It shares DNA with in-person leadership, sure, you still need empathy, clarity, technical credibility, all of that. But the how is fundamentally different. The signals are different. The failure modes are different. And if you’re not deliberately learning the new skill, you’re just accumulating bad habits with a green dot next to your name.
The green dot problem
Speaking of green dots, can we talk about presence indicators? That little bubble in Slack or Teams that goes green when you’re “active” and shifts to yellow or red when you’ve been away for a bit.
I hate them.
MS Teams is the worst offender, but they’re all guilty. What starts as a neutral status indicator becomes, in the wrong culture, a surveillance tool. Managers glance at their team list and make unconscious judgements. “Sarah’s been yellow for 40 minutes.” “Why is Dev offline at 2pm?” And before you know it, your engineers are jiggling their mouse to keep the dot green instead of doing actual thinking.
Here’s my unpopular opinion: the best engineering work doesn’t happen at the keyboard. It happens when you’re walking the dog in the park between focused work sessions. It happens in the shower. It happens when you step away from the problem and let your brain do that background processing thing that brains are remarkably good at, if you let them.
I’m a fan of the Pomodoro method, work in focused 25-minute bursts, then take a five-minute break to walk away from the screen and actually think. During those 25 minutes, Slack is closed. Not muted, not “do not disturb”, closed. And during those five-minute breaks, I’m not at my desk. I’m making a coffee, or standing on the balcony, or yes, walking the dog. My dot is red. My work is better for it.
The asymmetric communication trap
The open door policy creates another problem in async environments, and it’s sneaky because it looks like two opposite things.
Junior engineers over-communicate. They ping you with every question, every uncertainty, every “is this right?” They’re not being annoying, they’re doing exactly what you told them to do. You said the door was open. So they walked through it. Repeatedly. Often with questions that fifteen minutes of focused research would have answered. The “could this have been a Google search?” moment is painfully common, and it’s not their fault. You created the incentive.
Senior engineers under-communicate. They’ve been around long enough to know that bothering the CTO is career-limiting in most organisations, so they absorb problems quietly. They route around issues. They make local decisions that might not align with the bigger picture. And by the time they do speak up, the thing is genuinely broken and the fix is three times harder than it needed to be.
Neither of these is what you wanted. You wanted “come to me when it matters.” But “when it matters” is subjective, and an always-open channel gives no guidance on where the line is.
So what actually works?
I’m not going to pretend I’ve got this fully figured out, that would take more than my current hours on the clock, and I’m still learning. But here’s what I’ve found works better than an open door:
Structured check-ins, not open channels. Regular 1:1s with a clear format. I want to know three things: what’s going well, what’s blocked, and what are you worried about that isn’t blocked yet. The third question is the one that catches the stuff senior engineers sit on.
Written-first communication. If a question takes more than two sentences to ask, it should be a document or a ticket, not a Slack thread. This forces the person asking to organise their thinking, which, more often than you’d expect, leads them to answer their own question before they even send it.
Protected deep work time. Make it explicit and cultural. “We don’t expect responses between 9 and 12” or whatever works for your team. Make it okay to close Slack. Make it expected. If someone’s dot is red during focus hours, that’s not a problem, that’s the system working.
Teach the juniors to fish. Instead of answering every question, build the habit of asking “what have you tried?” and “where have you looked?” Not in a dismissive way, in a genuinely curious way. You’re teaching a skill that’s more valuable than the answer to any single question.
The deliberate practice bit
Coming back to Gladwell’s 10,000 hours, the thing that strikes me about remote leadership is how few of us treat it as a skill that requires deliberate practice. We assume that if we were decent managers in an office, we’ll be decent managers over Slack. And that’s about as logical as assuming that because you can play tennis, you’ll be fine at badminton. Same general shape, completely different game.
Every week, I notice something about remote communication that surprises me. A message I wrote that landed completely differently to how I intended. A silence I misread. A meeting I scheduled that should have been a Loom video. Each of those is a rep, if you pay attention. Most people don’t pay attention, they just blame the tools.
Remote leadership isn’t office leadership with a webcam. It’s a different skill, and it takes deliberate practice to get good at it.
The thing I’m still figuring out
I don’t have a neat answer for the loneliness part. When you’re a remote CTO and you close Slack to do deep work, you’re also closing your only connection to your team for those hours. There’s a tension there between protecting your focus and being present for the people who need you. I haven’t fully cracked it. If you have, I’d genuinely love to hear how.
What I do know is that an “open door policy” isn’t the answer. It’s a comfort blanket for leaders who haven’t yet done the hard work of designing intentional communication structures. And designing those structures, deliberately, thoughtfully, and with the willingness to get it wrong and iterate, that’s what remote leadership actually is.