Succeeding With Remote Development

Cagan argues that remote development teams, whether from outsourcing, acquisitions, or internal centralization, magnify normal communication and execution problems and often frustrate organizations. He offers three remedies: invest heavily in a high-fidelity product spec, prototype, and communicate through it; appoint a local owner who is accountable for all coordination with the remote team; and build personal relationships through regular face time and exchange programs. He notes that with talented teams and good management, time-zone differences can even produce very fast cycle times. Finally, he predicts that relocating whole product teams to remote locations will become a significant trend, though he expects it to take years to mature.

01Key takeaways

• Invest more in the product spec when the engineering team is remote, since distance and language gaps raise the cost of ambiguity.
• Use a high-fidelity prototype as the main vehicle for communicating both the spec and every change.
• Name one local person who is clearly accountable for the remote team's priorities to catch conflicting instructions early.
• Visit the remote engineering team at least quarterly and meet key architects and managers in person.
• Consider developer exchange programs so people from each location spend time working in the other.
• Plan around time-zone differences to create overnight progress and fast review-and-feedback cycles.

02Key sections

The problem of distance

Remote teams make communication and execution harder, and the perceived cost savings are often questioned. The article frames the challenge as broader than offshore outsourcing.

A high-fidelity spec as the main channel

The further and more culturally different the team, the more important a clear spec is. A high-fidelity prototype should serve as the primary means of communicating requirements and changes, since written documents are hard to get read and understood across languages.

A single local point of accountability

Conflicting instructions go unnoticed for months with remote teams, so one local person, such as a project manager or local engineering director, should own coordination without funneling all communication through them.

Building relationships through face time

Tools like video and VoIP help, but personal relationships matter most. Quarterly visits and developer exchange programs strengthen everyday communication.

Making the arrangement work

Time-zone differences can be turned into an advantage, with progress ready each morning for review and feedback. Remote prototyping is possible but demands more communication effort and flexible hours.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.