Engineering Leadership
March 25, 2024
7 min read

Remote Team Leadership: Lessons from Indonesian Startups

Managing 4 engineering squads across Indonesia taught me that great remote work isn't about overcoming cultural differences—it's about leveraging regional communication styles as strategic advantages.

Remote Team Leadership: Lessons from Indonesian Startups

When I managed 4 engineering squads across Jakarta, Surabaya, Yogyakarta, and Palembang, I discovered something fascinating: Indonesia's regional communication styles created more complex remote leadership challenges than most international teams face.

My Jakarta engineers were direct and efficient—"tanpa basa basi," straight to technical solutions. My Yogyakarta engineers were thoughtful and diplomatic—"muter-muter dan halus," carefully considering relationships and context before decisions.

Managing these different Indonesian cultural approaches remotely taught me that great distributed teams aren't built by forcing uniformity—they're built by orchestrating diversity as a strategic advantage.

Understanding Team Dynamics Through Psychology

Beyond Cultural Stereotypes

Rather than assuming extreme regional differences, I used systematic psychology tools to understand each individual's communication and working style:

DISC Assessments: Helped identify who preferred direct communication (D-style) vs. collaborative consensus-building (S-style), regardless of regional background

MBTI Framework: Understanding thinking vs. feeling decision-makers helped structure code review processes that worked for different cognitive styles

Graphology Analysis: Provided insights into individual stress patterns and communication preferences during high-pressure deadlines

Book-Based Surveys: Each book we read included practical assessment tools - from "Crucial Conversations" communication style inventories to "Deep Work" focus preference evaluations

Key Insight: The psychology tools revealed that communication preferences crossed regional lines - some Jakarta engineers preferred consensus-building while some Yogyakarta engineers were very direct. Individual assessment was more valuable than cultural assumptions.

Book-Based Problem Solving: Psychology Meets Engineering

Responsive Learning Culture

Rather than predetermined curricula, our bi-weekly book selection responded directly to real team challenges gathered from my 1:1s and emerging issues:

Book Survey Application: Each book included practical assessment tools that we immediately applied to current problems. If engineers were struggling with focus during sprint planning, we'd read "Deep Work" and use its productivity assessments. If code review discussions were becoming tense, we'd dive into "Crucial Conversations" with its communication style inventories.

Example Problem-Book Cycle: When our acquisition and registration system for user credentials became a source of team conflict (different engineers had strong opinions about security vs. usability trade-offs), we selected "Crucial Conversations" and used its conflict resolution frameworks to structure our technical discussions.

Three Years of Compound Learning at Warung Pintar

Year 1: Basic frameworks and individual understanding

Year 2-3: Same books revisited with deeper application

Key Books on Rotation:

  • "Effective Engineer" (yearly): As people joined/left, core productivity concepts needed reinforcement
  • "Atomic Habits" (yearly): Continuous improvement frameworks for both personal and technical practices
  • "Crucial Conversations" (yearly): Essential for navigating technical disagreements
  • "Drive" (yearly): Understanding motivation, especially important for remote team dynamics
  • The Compound Effect: By year 3, when we discussed "Atomic Habits" again, engineers could reference previous applications, share what they'd actually tried from earlier readings, and dive into much more nuanced discussions about habit formation in engineering practices.

    Shared Technical Language: By year 2, when discussing "Effective Engineer" concepts, team members could reference specific examples from previous implementations. Conversations became more sophisticated: "Remember when we discussed leverage from last year's reading? I think this automation project is exactly that kind of high-leverage activity."

    Cross-Reference Learning: Engineers started connecting concepts across books without prompting: "This deployment process reminds me of the habit stacking we discussed from 'Atomic Habits,' but we need to apply the crucial conversation framework to get stakeholder buy-in."

    Strategic Board Gaming for Real Team Challenges

    Games That Mirror Engineering Problems

    Secret Hitler: This social deduction game became our most valuable team exercise. Engineers had to share information, build trust, and coordinate under pressure—exactly like incident response scenarios.

    Real Application: After a session where miscommunication led to "fascist victory," we redesigned our incident response protocols. The game taught us that withholding information (even with good intentions) could harm the entire system.

    Terraforming Mars: The engine-building mechanics perfectly mirrored our technical architecture challenges. Players had to balance immediate needs with long-term system optimization while coordinating shared resources.

    Direct Translation: One memorable session where poor early-game coordination led to resource conflicts became the framework for our microservices dependency management. We realized our services were competing for shared resources instead of building complementary systems.

    Practical Communication Solutions

    The Real Challenge

    During our acquisition and registration system development, engineers had different comfort levels with challenging technical decisions in real-time discussions.

    Solution Framework

    Async Technical Communication:

  • PR Threads: Detailed technical discussions where engineers could provide thoughtful analysis without time pressure
  • RFC (Request for Comments): Structured documents for architecture decisions, allowing comprehensive input from all team members
  • Documentation-First: Critical decisions documented before implementation, creating space for considerate feedback
  • Sync Opportunities:

  • Pair Programming: Optional sessions for engineers who preferred real-time collaboration
  • Weekly Chapter Discussions: Frontend, Backend, and QA teams had dedicated time for domain-specific technical conversations
  • Case Study: Acquisition System Architecture

    The Challenge: Different engineers had strong opinions about security vs. usability trade-offs in our user credential system.

    Traditional Approach: Force consensus in meetings or let senior engineer decide unilaterally.

    Our Solution: Used an RFC for the security architecture decisions. Jakarta engineers provided immediate feedback on implementation complexity via PR comments, while Yogyakarta engineers contributed comprehensive security analysis through structured RFC responses.

    Result: The final solution incorporated both rapid iteration feedback and thorough security considerations. Everyone contributed their communication strengths to technical decisions, leading to better architecture and higher team satisfaction.

    Building Trust Through Systematic Understanding

    The "Know Your Team" Approach

    Indonesian culture taught me that trust isn't built through proximity—it's built through understanding how each person works best and creating systems that leverage their strengths.

    Weekly 1:1 Structure:

    1. Current Challenges (10 minutes): What's blocking you technically or personally?

    2. Communication Preferences (5 minutes): How do you prefer to receive feedback or share concerns?

    3. Growth Discussion (10 minutes): What are you learning? What do you want to learn?

    4. Team Dynamics (5 minutes): How are cross-team interactions working for you?

    Monthly Psychology Check-ins:

  • Review DISC/MBTI insights and how they're applying in current work
  • Discuss communication patterns that are working or causing friction
  • Adjust team processes based on what we're learning about individual styles
  • Measurable Cultural Success

    Team Health: Achieved highest engagement scores across all Sirclo Group engineering teams, measured through quarterly culture surveys.

    Technical Collaboration: 30% increase in code review participation, with contributions coming more evenly across all regional teams.

    Knowledge Sharing: 40% of all tech teams participated in bi-weekly book sharing sessions, creating cross-team learning culture that extended beyond my direct reports.

    Cultural Bridge Success: Zero escalated conflicts between communication styles over 18 months, despite managing technically complex, high-pressure projects.

    Innovation Through Diversity: Technical solutions started incorporating different regional approaches—Jakarta speed with Javanese thoroughness, Surabaya pragmatism with Palembang quality focus.

    The Community-First Engineering Mindset

    Collective Problem-Solving

    Instead of assigning complex problems to individual "heroes," we approached technical challenges as community learning opportunities:

    Architecture Reviews: Not "senior engineer decides" but "team designs together through structured discussion"

    Incident Response: Cross-regional debugging sessions with real-time knowledge sharing

    Performance Optimization: Team-wide learning initiatives where everyone contributed insights

    Knowledge Sharing as Cultural Value

    We institutionalized collaborative learning:

  • Bi-weekly Book Discussions: 30-minute sessions connecting human skills with technical work
  • Cross-regional Tech Talks: Engineers presenting solutions with cultural context
  • Psychology-Informed Retrospectives: Using frameworks from our reading to improve team processes
  • Why Indonesian Regional Diversity Matters for Tech Leadership

    The future of Indonesian tech isn't about creating uniform "global" engineering cultures. It's about leveraging our incredible regional diversity as a competitive advantage.

    Key Insights:

    1. Communication Orchestration: Different Indonesian cultures contribute different strengths to technical teams

    2. Shared Learning: Books and games create common frameworks while respecting cultural differences

    3. Psychology-Informed Leadership: Understanding individual differences matters more than regional stereotypes

    4. Authenticity Over Uniformity: Teams perform better when communication approaches are leveraged, not eliminated

    Managing across Jakarta's directness, Java's thoughtfulness, Surabaya's pragmatism, and Palembang's precision taught me that Indonesia's regional diversity is a strategic asset for building exceptional distributed engineering teams.

    The best remote engineering cultures aren't built by copying what works in Silicon Valley. They're built by understanding what works for your specific team—across cultures, personalities, and contexts—and creating systems that help everyone contribute their best work.

    ---

    Leading distributed engineering teams in Indonesia? I'd love to hear about your experiences with regional diversity and remote culture building. Connect with me on [LinkedIn](https://linkedin.com/in/syanmil) or [send me an email](mailto:syanmil@gmail.com).

    Tags
    remote-workleadershipcultureindonesiadistributed-teamspsychology
    IS

    Izhharuddin Syanmil

    Engineering Leader & Game Designer combining psychology, technical leadership, and creative design to build better products and teams. Former Engineering Manager at eFishery and Warung Pintar.

    Related Articles