Global teams and social media

The chain is the answer

A global software development (GSD) team is one whose members are distributed across sites, usually across countries and time zones. Everyone asked about global teams writes "time zones and language are hard". That sentence earns nothing. What earns marks is the causal chain, which you should be able to reproduce as a diagram and as a paragraph:

Distance reduces collaboration. Not because distant people are less willing, but because the incidental collaboration that co-location supplies for free — overhearing a problem, drawing on a whiteboard, asking a two-second question — stops happening. Distance simultaneously raises the need for coordination. Work that co-located people would resolve implicitly now needs an explicit mechanism: a written interface, a scheduled hand-off, a decision log. So the demand for coordination goes up exactly as the means of supplying it goes down. Distance also introduces barriers and complexity — time-zone offsets, cultural differences in how disagreement is expressed, second-language overhead, differing holidays and working norms. Those barriers attenuate communication: the signal-to-noise ratio drops, so more messages carry less information. Run the chain forward and the outcome is a project that becomes unstable — decisions are made twice, or not at all, and nobody can say which.

The chain is also the source of the fixes, which is why it is worth memorising in that order. If distance reduces collaboration, engineer collaboration explicitly rather than hoping for it. If it raises the coordination requirement, invest in coordination artefacts you would not have needed in one room. If barriers attenuate the signal, make the signal redundant — write decisions down, and confirm them in a second medium.

What is hard about a decision, before you add distance

Decision-making on any software team is complicated by four things: the complexity of the problem itself; the uncertainty and risk attached to the decision; the law of unintended consequences, in which a decision made for one objective damages another; and the fact that people hold genuinely different views of the same problem. Distance creates none of these. It amplifies all four, because each is normally resolved by exactly the cheap, high-bandwidth conversation that distance removes.

Social media: the case for, and the case against

Social media is not merely a substitute for face-to-face contact, the way email, texting and videoconferencing are. Its distinctive value is connection: it lets engineers find people who share their goals or hold complementary skills, including friends-of-friends they had no way to reach otherwise, and that value grows with team size and is magnified when the team is geographically dispersed — precisely the situation a global project is in.

The cost is equally concrete. Much of what a software team works on is proprietary to the employer, and disclosure can be seriously harmful — architecture, defect data, release dates, security weaknesses. Public social media is a channel with no recall. The honest position, and the one an exam question phrased "would you use it, and why or why not?" is looking for, is that the benefit must be weighed against the threat of uncontrolled disclosure, and that the weighing produces a policy rather than a yes or a no. Specialised private networks built on the same paradigm are the usual resolution: the connection value inside a controlled boundary.

Worked example — BorrowBox across three sites

BorrowBox grows: the app team stays in Vancouver, the reservation and payments services move to a team in Kraków, and the locker firmware and hardware integration sit with a vendor's engineers in Bengaluru. Vancouver and Kraków share about one hour of working day; Vancouver and Bengaluru share almost none.

Run the chain. Collaboration falls: the two-second question about whether an expired hold releases the locker immediately or at the next sweep now costs a day. Coordination need rises: the reservation-to-locker interface, which used to live in two people's heads, must become a written contract with versioning, because a mismatch strands a member at a locker on a public street. Barriers appear: a Bengaluru engineer's "we can look at that" is a polite deferral that Vancouver reads as a commitment, and the schedule silently diverges. Communication attenuates: the daily written hand-off grows to eleven bullet points, of which two matter, and people stop reading it.

The response has to follow the chain rather than the symptoms. Collaboration is engineered: the firmware interface is owned by one named engineer per site who pair up in the single overlapping hour, and that hour is protected. Coordination is made explicit: the interface is versioned, every change is a five-line decision record, and done is defined identically at all three sites. Barriers are attacked directly: decisions are written and then confirmed, and commitments are elicited as dates rather than intentions. On social media the answer is a policy: a private team workspace for everything project-specific; public professional networks used only for recruiting and for generic technical questions with no product context; and one written rule — nothing about the locker security model, the QR token scheme, or the release date leaves the private boundary. That rule exists because BorrowBox's attack surface includes a physical device on a public street, so a disclosure there is not an embarrassment but an exploit.