Cross-Functional and Global Team Leadership

A fictional retailer put a platform lead in Seoul in charge of improving checkout reliability before its next holiday season. The work involved product management in London, engineers in Seoul and Warsaw, data specialists in Bangalore, security in Dublin, and finance in New York. None reported to her. Over eight weeks, decisions made in one meeting were challenged in the next. Bangalore attended a recurring call at 02:30. Messages pointed to threads with two hundred replies. Then, at 16:00 Dublin time, three days before the change freeze, security said that the new session store could not go live without review. Finance first saw the infrastructure cost on an invoice. The initiative needed clearer authority, earlier input, and workable participation across regions. This article uses that illustrative case to examine cross-functional team leadership, drawing on public guidance from GitLab, Atlassian, FinOps, GOV.UK, and Google.

Where influence comes from when authority does not

The lead did not need every function to report to her, but she did need a mandate that those functions could act on. Her director and the functional owners had to agree priorities, commit review capacity, and identify who could settle unresolved conflicts. Direct reporting authority alone would not supply good requirements or clear records; equally, communication could not supply missing budget authority or staff time. The lead’s practical work was to establish those arrangements, understand the functions’ requirements, and make decisions and requests usable across regions. Team types and how teams interact covers the structural choices behind such arrangements.

GitLab recommends contacting the people whose support is needed directly, with escalation when that support cannot be obtained. GOV.UK’s multidisciplinary-team guidance similarly allows needed skills to be within the team or available to it. Availability needs an operating arrangement: a named contact, capacity, response expectations, and an escalation route. In the checkout case, the late request left no room for the normal security review before the freeze. The lead needed the functional owner’s help to arrange review and a feasible release plan.

What each function is protecting

A late objection calls for investigation. It may expose an earlier consultation gap, a changed design, a newly discovered risk, or competing work. FinOps Personas offers a useful starting point for understanding the participants: broad groups contribute different expertise and pursue related but distinct outcomes. Its finance, product, engineering, and procurement descriptions concern technology value, requirements, operation, and commercial decisions. They do not assign local approval powers. Cloud cost operations and FinOps develops that cost-management context. For checkout, the lead drafted the following map and asked each representative to confirm responsibilities, information needs, and actual decision authority.

Function	Concern in this initiative	Input needed	Decision or escalation to confirm
Product (London)	Holiday conversion and customer experience	Behavior changes and tradeoffs before scope is committed	Who can change product priorities and agree engineering capacity
Engineering (Seoul, Warsaw)	Reliability and operability	Design, workload, dependencies, and time for implementation	Who accepts the technical design and commits delivery capacity
Data (Bangalore)	Order integrity and downstream consumers	Schemas, event contracts, and migration plans before dependent work is committed	Who validates compatibility and agrees changes with consumers
Security (Dublin)	Session handling and applicable residency requirements	Design and data flows with sufficient review time	Who confirms security compliance; separately, who controls the release freeze
Finance (New York)	Forecast and affordability	Estimate before commitment and actual costs during delivery	Who holds the relevant spending authority and how exceptions are escalated

Use the map to arrange input and approvals, then revise it when the work changes. A larger estimate is evidence about scope or uncertainty, not necessarily engineering’s refusal. Broken reports call for investigation; they are not the data team’s way of voting no. Finance and security may have formal controls, but the specific holders and limits must be confirmed. Stakeholders distinguishes approval authority, relevant knowledge, and exposure to consequences. A participant can belong in more than one category; lack of approval authority does not make their evidence irrelevant.

One decider, and a decision that survives the night

Atlassian’s DACI play separates four roles for a defined decision. The Driver gathers information and moves the decision toward an agreed date. The Approver makes that decision within their authority. Contributors supply expertise and recommendations; Informed participants receive the outcome. In this case, the lead drove coordination, the head of engineering held the technical-design decision, the authorized budget holder decided spending, and Dublin’s reviewer held the security sign-off. The release owner separately applied the freeze policy. The lead confirmed these mandates with the holders. One Approver for a scoped DACI decision did not remove the other approvals needed for release.

A DACI record should identify an existing or validly delegated decision right; naming a person does not grant one. The advice process is a separate rule for seeking advice from people meaningfully affected and people with expertise. It can be combined with DACI, but its consultation duties do not follow automatically from a Contributor label. Decide whose input is needed before the decision and provide a route for it; those people cannot be treated solely as recipients of the final notice. GitLab’s distinction between a proposal seeking input and an announcement of a decision helps make the stage clear.

Record the question, decision, authorized owner, rationale, alternatives, constraints, and conditions for reconsideration. Link the supporting discussion so people in other regions can reconstruct what happened. GitLab’s guidance on non-linear work separates gathering input from making the decision. Set an input window appropriate to the urgency and participants’ working schedules, then make the decision through the agreed authority. New evidence can arrive in chat or elsewhere: route it to review and update the record when a decision is changed or superseded. A log prevents untraceable changes; it should not suppress a legitimate challenge.

Writing for a reader who was asleep

A message that only says see thread makes the recipient reconstruct what the author already knows. GitLab recommends explicit context and a brief description of what a linked issue contributes. State the problem, current status, request, and relevant timing, with links for supporting detail. Low-context communication reduces dependence on a shared meeting or conversation. It can reduce unnecessary clarification, but readers may still need specialist knowledge, authorized access, or a follow-up answer.

Asynchronous communication does not require people to participate at the same time. A question answered the following morning is still asynchronous. GitLab favors this approach where it works and also describes situations where a live conversation can resolve uncertainty or disagreement more efficiently. Choose from the issue’s urgency, complexity, and the people whose input is needed. For Dublin’s concern, the lead arranged a call with the reviewer and head of engineering at a time all three confirmed they could attend. The recurring status update could instead be written, with a clear route for questions and urgent blockers.

People differ in language fluency, communication preferences, and comfort expressing disagreement. Ask about those needs instead of diagnosing colleagues by nationality. A team can learn shared practices: spell out requests, avoid unexplained references, and offer suitable ways to raise concerns. Check whether intended readers understand the next step and can respond. More text is not automatically clearer, and no fixed paragraph count guarantees a day of saved work.

Time zones: a budget of synchronous hours

Synchronous time is limited, so check the working hours of the people who actually need to attend. GitLab’s Communication guidance suggests considering UTC for recurring meetings, while warning that local offsets change during the year. Decide whether to preserve the UTC instant or a particular region’s local clock time. A 13:00 UTC meeting falls at 08:00 in New York on March 2, 2026, and 09:00 on March 16; London changes from 13:00 to 14:00 by March 30. Recheck overlap around those transitions. GitLab’s Meetings guidance also recommends suitable regional facilitators. Changing the host alone does not change anyone’s local meeting time. To distribute inconvenience, change actual slots, provide regional sessions, or reduce required attendance with an effective alternative input route.

GitLab’s Meetings guide recommends advance invitations and agendas, commonly 72 hours with a 24-hour minimum in its guidance; its Communication page gives similar notice guidance for announcements. Treat these as organizational practices to adapt, not proof that every person has had a working day to respond. Account for weekends, holidays, leave, and the work needed to review a proposal. Share an agenda, identify who contributes and by when, and have an owner examine their input before the decision. Notes preserve the outcome for absent colleagues, but reading them afterward is not the same as influencing a decision beforehand. Urgent incidents need a separate response path. Assess outcomes while also providing any agreed coverage or live coordination the work requires.

Google’s study found that colocation and consensus-driven decision making were not significantly associated with its measures of team effectiveness in that setting. The authors explicitly caution against assuming those factors are unimportant elsewhere. The result does not establish that distributed work has no coordination costs or that DACI is superior. Examine delays, handoffs, relationships, and participation in the actual team. Written records and clearly scoped decisions can help; a focused meeting can also be worth its cost.

The working agreement

A working agreement records shared ways of working. Atlassian’s play asks members about location, hours, commitments, and feedback preferences, then has the group discuss channels and escalation. The agreement can refer to existing organizational procedures rather than duplicate them. Make clear what the group can choose and what policies or authority limits it must follow. Where preferences differ, the play suggests trying a workable compromise and reviewing the result. If practice later diverges from the agreement, investigate whether the practice needs correction or the agreement needs revision.

A Team API communicates a team’s boundaries and ways of interacting with other teams. A working agreement describes practices adopted within a standing team or a temporary group. They can complement one another. Forming the twelve-week checkout initiative was a useful occasion to establish shared practices. Atlassian also recommends reviewing them after changes such as onboarding or a reorganization; forming an initiative does not necessarily constitute all of those events.

The initiative, restarted

In the ninth week, the lead reviewed the function map with each representative and confirmed the relevant mandates. Dublin specified a three-week security review for the revised scope. With only three days remaining before the freeze, the lead and release owner removed the unreviewed store from the pre-freeze release and kept the existing system in place. They assigned owners to test its holiday capacity and agree operational coverage; an unacceptable result would require scope reduction or another authorized contingency, not an unreviewed replacement. The store’s earliest release was moved beyond the freeze and made conditional on completed review and release approval. Other open decisions were assigned to the appropriate authorities with input deadlines and explicit resource commitments.

The lead held two working-agreement sessions in suitable regional hours, circulated a merged draft, and highlighted differences for resolution through the agreed decision process. Participants had time in their working schedules to comment before confirmation. The agreement made the log authoritative while allowing chat to raise new evidence for reconsideration. Written updates had locally feasible submission windows and a common review cutoff. For the monthly call, the team varied actual slots and provided a documented input route for people unable to attend; rotating the facilitator was a separate task.

The security call produced a proposal for a narrower first release. The engineering lead chose the technical scope, but did not waive security requirements. In this illustrative design, that first release retained existing approved storage locations and excluded the new regional data flow. Dublin verified that it met the applicable residency and session-handling requirements before signing off. New regional functionality remained blocked until its requirements were met and separately reviewed. The budget holder approved the cost before commitment, and the release owner checked all required approvals and the revised post-freeze date. The log recorded each decision and its conditions.

The lead retained the cross-functional reporting structure while obtaining the mandate and capacity commitments the work needed. She replaced routine status calls where written updates worked and used live discussion where it helped resolve the security question. Bangalore’s 02:30 meeting was an evident burden, but silence did not establish agreement or reveal every cause. She asked participants about fatigue, language, role clarity, and concerns about speaking up, then followed up on what they reported. Psychological safety concerns whether people feel able to take interpersonal risks when raising concerns; an accessible channel is useful but does not by itself establish that condition.

What a reviewer should ask

A cross-functional or distributed initiative can be reviewed with a short list, each item tracing to something above.

• Have the participating functions confirmed their concerns, information needs, actual decision authority, and review capacity? How are new requirements or late objections investigated?
• For each scoped decision, who drives it and who has valid authority to decide? What separate budget, security, or release approvals remain necessary?
• Can intended readers find the decision, rationale, constraints, and supporting evidence, and is there a route for questions and reconsideration?
• Do input deadlines allow the required participants to contribute before the decision, with a separate route for urgent situations?
• Which outcomes need live coordination? What are the actual local attendance times, and can regional sessions or alternative input reduce the burden?
• Is the schedule anchored to UTC or a named local zone deliberately, checked across DST changes, and supported by realistic working-time notice and review windows?
• Do recent messages give their intended readers enough context to understand the request and next step, while allowing clarification and respecting access limits?
• Does the working agreement identify usable channels, responsibilities, and escalation routes within the group’s authority? When practice differs, who decides whether to change the practice or the agreement?

The lead still had no new direct reports. She had, however, secured explicit commitments, separated decisions by authority, and made input and outcomes accessible across regions. The revised release plan respected the review and freeze constraints instead of treating the meeting as permission to bypass them. Those arrangements gave the initiative a workable way to proceed and a way to revisit decisions when the facts changed.

References

• GitLab Handbook, Communication, including its sections on asynchronous communication, low-context communication, scheduling meetings across regions, and company announcements.
• GitLab Handbook, All-Remote: Meetings.
• GitLab Handbook, The complete guide to asynchronous and non-linear working.
• Atlassian Team Playbook, DACI Decision-Making Framework.
• Atlassian Team Playbook, Working Agreements.
• FinOps Foundation, FinOps Personas (CC BY 4.0).
• GOV.UK Service Manual, What each role does in a service team, updated 6 November 2023.
• Google re:Work, Understand team effectiveness, originally published 2015.