Hard Mode
Cheat codes for leading remote teams
Playing a video game on hard difficulty is an ambitious choice the player makes. It can make enemies stronger and faster, the player weaker, resources more scarce, or shorten the time to beat the level. Players play on hard mode for a greater challenge or to unlock rewards.
Leading a remote team is like playing on hard mode. The game looks the same on the surface, but somehow, things that were easy with a colocated, office-based team make the manager sweat much harder to get results that required little effort before.
My first experience with fully remote work was the 2020 COVID lockdown. It wasn’t a big shift — most of my team worked hybrid with a heavy remote component, we knew each other for years, and the domain was familiar.
Until I changed jobs.
My name is Roman, I am the CTO at a startup. I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs.
This issue is about leading remote teams on hard mode — and three cheat codes to make it easier.
In the middle of COVID, I got hired as a software engineer to a recently formed team in a series A startup that just got funding. The team didn’t have much experience working together. New business domain. No processes. Normally, none of that would have been a huge problem. Engineering teams rarely have comprehensive up-to-date documentation. Onboarding can range from quite ok to non-existent. It had never been a real issue for me before.
What changed is that this time I needed to do it all remotely. I could get things done, but building a full understanding of how everything fit together was painfully slow.
The business domain was unfamiliar. The architecture had surprises — no documentation, no clear picture of how everything fit together, partially duplicated systems. I needed to piece together the full mental model by myself.
I asked questions on Slack, but since I didn’t know the team, I didn’t know what to ask or who to ask. When I did ask on a public channel, I got answers I didn’t fully understand — and I was still stuck. In an office, I would have gone to lunch with people, walked to someone’s desk, and the conversation would have wandered until I discovered what I didn’t know I was missing. Remote, that didn’t happen. Every interaction was narrow and specific. A question, an answer, and back to silence.
I could contribute from the first week. But the holistic understanding — how everything connected, why certain decisions were made, what the real priorities were — that took about eight months. Everything just felt much slower and much more complex than it needed to be.
The work wasn’t only slow, it also led to suboptimal decisions. I lacked the bigger picture and made architectural design mistakes on a critical system.
The friction went both ways. I couldn’t fully comprehend the system and the organization. But also, the team couldn’t understand me — my technical approaches, my ideas, my way of thinking about problems. Both sides had context that the other lacked, and we couldn’t close the gap fast enough to collaborate properly. I was senior enough to build the right systems. But seniority doesn’t help when you don’t share enough context to think together.
At the time, I couldn’t put my finger on what was wrong. Now I would formulate it like this: when you work remotely, a small team of ten starts having the problems of a team three times the size. We crank the difficulty to hard mode.
Playing on lag
Anyone who has played an online game on a bad connection knows the frustration. You can see everything happening. You can try to act. But your inputs don’t land when they should, information arrives late, and you’re always a step behind everyone else. You’re in the game, but not quite in it.
That is what remote work does to communication — it slows everything down: team formation, onboarding, and building shared mental models.
Humans evolved to work in groups in a certain way. Non-verbal cues, informal interactions, building rapport and team cohesion through micro-interactions — all of them are how an effective team with high trust and shared goals works. In an office, you read someone’s face and know the message didn’t land. You overhear a conversation and pick up context you didn’t know you needed.
In a remote setting, these things don’t happen naturally. Communication is deliberate — organized meetings, messages, and narrow. A lot of it happens through text, where emojis serve as a poor replacement for body language and tone of voice.
As communication is more scarce, there is a risk of missing information or misinterpretation. A decision made during a scheduled meeting seems to be understood by everyone the same way, but it turns out half of the team got it one way, and the other half got it another.
A short message in Slack from a senior stakeholder got interpreted as meaning that he was angry. That left a bitter taste and diminished trust. In reality, the stakeholder was just stressed and busy with another project. Non-verbal cues were completely missing.
That is what the complexity multiplier really is. Not coordination overhead. Not meeting fatigue. It is the cost of building mutual understanding and shared mental models on a connection that was never designed for it.
Remote teams cannot rely on this process happening naturally. To win on hard mode, we need to cheat. Here are three cheat codes that work.
Cheat 1: Unlock the map
Most games start with the map hidden. You explore in the dark, not knowing what is around the corner. The cheat that reveals the entire map changes the game — suddenly, you know where to go and what to avoid.
Remote teams without shared context are exploring in the dark. The cheat is not to document everything — the details can live in the code. The cheat is to make the high-level picture visible: what the business does, how the system is built, and how the pieces fit together. Without that, every new person has to reverse-engineer the big picture from the details, which is slow and error-prone.
The first order of business is to create high-level context: what is the domain area? What service do we provide? How is the system built at a high level?
A new person joining the team can look at this map and find their way around in the code or understand a ticket. It is the goal anyway. This documentation does not get outdated often. It takes days to write — not months, and it is a real cheat code for onboarding.
We also adopted RFCs for technical decisions. Instead of explaining an approach in a meeting and hoping everyone understood, the author wrote it down. Relying on principles of in-person communication — wide channels, repetition through occasional interactions — does not work remotely. We can be lucky sometimes and get it right, but a hard artifact, such as an RFC or documentation, removes uncertainty. It feels slow, but running faster in the wrong direction is even slower.
Cheat 2: Build your party
In any RPG, you need to know your party — who is the healer, who is the tank, who deals damage. A well-composed party where everyone knows their role is far stronger than a group of random players with no coordination.
Building clarity on who is who — on the team and outside it — removes friction. Getting to know key stakeholders matters just as much as knowing your own team.
Knowing people’s strengths matters. John knows security and payment processing inside out, but if you want an opinion on UI performance, ask Maria.
Learning about the team is crucial when forming a new team or onboarding a new team member, but this is the part that teams nail down eventually. The trickier part is establishing a connection and rapport with stakeholders external to the team. These are often people the team does not talk with daily. But they are the ones who decide on team priorities and budgets. Meeting stakeholders and connecting with them beyond the roadmap items and implementation tickets is crucial for team effectiveness.
The ultimate cheat code for remote teams is to meet periodically — not only for work but also to spend time together. Think of it as taking your party to the tavern. Offsites, team days, and informal gatherings work wonders. A two-day offsite builds more trust than months of Slack messages. It is where the high-bandwidth conversations happen — the ones where people finally build the mutual understanding that a laggy connection can’t deliver.
Cheat 3: Open the comms channel
In multiplayer games, a team without voice chat is at a massive disadvantage. Players run in different directions, duplicate effort, and miss critical calls. But voice chat, where everyone talks at once, is just as bad — pure noise, nobody can think, and the important calls get buried.
That was our Slack. Remote communication without set rules was chaotic. Every question, every bug report, every complaint landed in the same channel. Nobody used threads. Everything felt like it needed immediate attention. Slack sucked the life out of the team. People were constantly reacting instead of doing focused work.
The cheat was to bring structure to the chaos. First, channel hierarchy. Not everything belongs in the same place. Team channels for daily work, project channels for cross-team coordination, broader channels for announcements. When people know where to look, they stop missing things. When they don’t, important messages drown in noise.
Second, public channels over DMs. Direct messages are where information goes to die. When a question is asked and answered in a DM, nobody else benefits. The same question gets asked again next week by someone else. Moving conversations to public channels feels uncomfortable at first, but over time, it builds a searchable, shared knowledge base that compounds.
Third, not everything is equally urgent — but on Slack, everything looks the same. We separated critical bugs from non-critical ones. Critical bugs have an expected response time. Non-critical bugs are looked at when people have time. A simple distinction, but without it, every bug report feels like a fire alarm, and the team stays in permanent reactive mode.
We also built Slack automation workflows for stakeholder requests. Instead of DMing someone on the team or dropping a message in a team channel, stakeholders submit a structured request through a workflow. It goes to the right place, with the right context, without creating noise. It took some effort to set up, but it eliminated a whole category of interruptions.
Still hard mode
When I got all three cheats in place — unlocked the map so people could navigate independently, built the party so they knew and trusted each other, and opened the comms channel so they could coordinate — the friction didn’t disappear. Remote is still hard mode. The lag is always there. Shared mental models still take longer to build than they would in an office.
But it became a game we could win.
If this was useful, subscribe to High-Impact Engineering to receive one practical lesson on engineering leadership every week.
Know someone leading a remote team? Share this with them — they might recognize the struggle.