In 2016, when I founded Mind Group Technologies in Sorocaba, São Paulo, everyone was in the same room. Five engineers, one whiteboard, zero Slack channels. We could solve problems by turning around in our chairs.
Today, we have team members scattered across Brazil — from Sorocaba to Recife, Porto Alegre to Manaus. We serve clients in São Paulo, Rio de Janeiro, and increasingly, the United States and Europe. The office still exists, but it's optional.
This transformation wasn't planned. COVID forced it, like it did for everyone. But what happened next was the interesting part: we discovered that remote work didn't just maintain our productivity — it improved it. And then we spent four years figuring out why it worked and how to make it work better.
Here's what we learned.
The Brazil-Specific Challenges Nobody Talks About
Most "remote work advice" articles are written from a San Francisco perspective. They assume reliable gigabit internet, a quiet home office, and a culture where asynchronous communication is the default.
Brazil is different.
Internet reliability varies wildly. A developer in São Paulo might have 500Mbps fiber. A developer in a smaller city in Bahia might have 50Mbps that drops during rainstorms. We learned to design our workflows around intermittent connectivity — not as an edge case, but as a baseline assumption.
Time zones within Brazil matter. Brazil spans four time zones. When it's 9 AM in Sorocaba (BRT), it's 8 AM in Manaus (AMT). That one-hour difference sounds trivial until you're scheduling daily standups for a team spread across the country.
Home office infrastructure isn't equal. Some team members have dedicated home offices. Others work from a bedroom shared with family members. We learned early that providing equipment stipends — monitors, chairs, headsets — isn't a perk; it's a productivity requirement.
Cultural communication styles differ by region. Developers from São Paulo tend to be direct and fast-paced. Developers from the Northeast tend to be more relationship-oriented in communication. Neither style is better, but misreading communication patterns causes friction in remote teams.
Our Remote Work Stack
After years of experimentation, here's what actually works for us at Mind Group Technologies:
Communication:
- Slack for real-time chat, organized by project channels
- Google Meet for video calls (we tried Zoom, Teams, and Discord — Meet won for reliability in Brazil)
- Loom for async video updates — a developer can record a 3-minute walkthrough of their PR instead of scheduling a meeting
Project Management:
- Linear for issue tracking (migrated from Jira — the speed difference is night and day)
- Notion for documentation, wikis, and decision logs
- GitHub Projects for sprint boards tied directly to repositories
Development:
- GitHub for code, PRs, and code reviews
- VS Code + Live Share for pair programming sessions
- Docker for consistent dev environments across machines
The rule we follow: Every tool must work well on unstable connections. If a tool requires constant high-bandwidth connectivity, we don't use it.
The Three Meetings That Actually Matter
We killed most of our meetings. Here's what survived:
1. Daily Standup (15 min, async-first)
We use a Slack bot that asks three questions at 9 AM BRT:
- What did you finish yesterday?
- What are you working on today?
- Any blockers?
Team members respond in text. If someone has a blocker, we spin up a quick call to resolve it. No standing meetings for status updates — those are a waste of synchronous time.
2. Weekly Technical Review (45 min, video)
Every Friday, one team member presents something technical: an architecture decision, a debugging story, a new tool evaluation. This serves two purposes: knowledge sharing and team bonding. Remote teams need rituals that aren't just about tickets and deadlines.
3. Sprint Planning (1 hour, video, biweekly)
We plan two-week sprints. The product owner presents priorities, the team estimates, and we commit to a scope. This is the one meeting that absolutely must be synchronous because real-time negotiation about scope is difficult to do asynchronously.
Everything else is async. Code reviews happen in GitHub. Design discussions happen in Notion documents with comments. Architecture decisions are documented in ADRs (Architecture Decision Records) that anyone can review and comment on within 48 hours.
Code Review as a Team-Building Tool
In a remote team, code reviews are your primary touchpoint for technical mentorship. We treat them seriously:
Every PR gets reviewed within 4 hours. Not approved — reviewed. A first pass with comments. This keeps the development cycle moving and shows respect for the author's time.
Reviews are educational, not gatekeeping. We write comments that explain the why behind suggestions:
// Instead of: "Don't do this"
// We write: "Consider using a Map here instead of an
// object because we need O(1) lookups and the keys
// aren't always strings. See MDN docs: [link]"
Junior developers review senior code. This sounds counterintuitive, but juniors asking questions about senior code is one of the best learning mechanisms. The senior has to explain their reasoning, and the junior learns architectural thinking.
We use PR templates that require:
- Description of what changed and why
- How to test locally
- Screenshots/recordings for UI changes
- Link to the related Linear issue
Handling the "Isolation Problem"
The biggest risk with remote teams isn't productivity — it's isolation. Developers who feel disconnected stop caring about the team's goals and start optimizing for their own comfort.
Here's how we fight it:
Virtual coffee chats. Every week, a bot randomly pairs two team members for a 15-minute casual video call. No agenda, no work topics. Just two humans talking. It sounds forced, and it is — but it works. Relationships that would form naturally in an office need artificial scaffolding in a remote environment.
In-person meetups twice a year. We bring the entire team to Sorocaba for a week. Three days of workshops and planning, two days of just hanging out. The cost is significant (flights from Manaus or Recife aren't cheap), but the team cohesion boost lasts months.
Transparent salaries and growth paths. Nothing breeds resentment in remote teams faster than information asymmetry. Everyone at Mind Group knows the salary bands for their level and what they need to do to reach the next level. This transparency eliminates the "am I being treated fairly?" anxiety that festers in remote environments.
Public recognition. When someone does exceptional work, we recognize it publicly in Slack. Not vague praise — specific recognition: "Maria's refactoring of the payment module reduced API response times by 40% and made the codebase significantly more maintainable." Specific recognition shows that leadership is paying attention, even from a distance.
Hiring Remote: What We Look For
Not every developer thrives in a remote environment. After hiring 50+ remote team members, here are the traits that predict success:
Written communication skills. In a remote team, your ability to write clear messages, documentation, and PR descriptions is as important as your coding ability. We ask candidates to write a technical document as part of the interview process.
Self-direction. Remote developers need to identify what needs to be done next without constant guidance. We test this by giving candidates a deliberately ambiguous problem and seeing how they ask clarifying questions.
Proactive communication. The best remote developers over-communicate, not under-communicate. If something is taking longer than expected, they say so early. If they're stuck, they ask for help within hours, not days.
Comfort with async. Some developers need immediate responses to every question. That doesn't work when your teammate is in a different time zone or deep in focused work. We look for people who can queue their questions and continue working on something else while waiting.
The Productivity Data
We've been tracking productivity metrics for four years across remote and in-office periods. Here's what the data shows:
PRs merged per developer per week: Remote developers merge 15-20% more PRs than in-office developers. The likely explanation: fewer interruptions and no commute means more focused coding time.
Bug rate: No statistically significant difference between remote and in-office periods. Code quality is maintained by our review process, not by physical proximity.
Time to resolve blockers: 10-15% slower for remote teams. Async communication adds latency when someone is blocked. We've mitigated this with the "4-hour review" rule and designated "available for questions" time slots.
Employee retention: Significantly better since going remote. Our annual turnover dropped from ~25% (industry average in Brazil) to ~12%. Developers value the flexibility.
What Doesn't Work
Being honest about failures:
Fully async doesn't work for complex problem-solving. When you need to make a high-stakes architectural decision, real-time video with screen sharing is irreplaceable. Don't try to do everything async.
"Optional" cameras-on policies mean cameras are always off. If you want face-to-face connection, make specific meetings camera-on by default. Don't leave it optional — social pressure will always trend toward cameras off.
Remote-first isn't remote-only. Some tasks benefit from physical co-location: onboarding new team members, resolving interpersonal conflicts, brainstorming product direction. Our twice-yearly meetups exist because pure remote isn't optimal for everything.
Monitoring tools destroy trust. We tried time-tracking and screen monitoring tools early on. They created an adversarial dynamic and the best developers threatened to quit. We removed them within a month. Trust your team or don't hire them.
The Bottom Line
Managing remote dev teams in Brazil requires understanding the country's specific infrastructure, cultural, and economic context. What works in Silicon Valley doesn't automatically work in São Paulo, let alone in Manaus or Recife.
The fundamentals: invest in async communication, design workflows for variable internet quality, create artificial social structures to replace office serendipity, and trust your developers to manage their own time.
At Mind Group Technologies, remote work isn't a policy — it's our operating system. After eight years, we're convinced that Brazilian tech companies that master remote work will outcompete those that don't, simply because the talent pool expands from one city to an entire country of 215 million people.
José Gonçalves is the Founder of Mind Group Technologies, a software company based in Sorocaba, SP, Brazil. Mind Group builds technology solutions across healthcare, fintech, and SaaS with a distributed team across Brazil.
Top comments (0)