Structure sets where work sits; interfaces and ways of working determine how work actually moves. Most performance and collaboration pain shows up not inside a team, but between teams and units. This chapter focuses on designing those “in-between” spaces: mapping critical interfaces, setting up cross-functional teams, defining collaboration norms and escalation paths, using agile and hybrid models sensibly, and reducing friction at handoffs with clear expectations and service catalogs.
12.1 Mapping Critical Interfaces Across Units and Functions
Interfaces are the points where work, decisions, or information must pass from one unit to another to create value. If macro-structure defines the boxes, interfaces are the arrows between them. Poorly designed arrows create delays, rework, and blame-shifting.
Start by identifying critical interfaces, not every interaction. Use your strategy, value streams, and diagnostic work to pinpoint where interfaces matter most:
- Customer journeys that cross multiple units (sales → delivery → service → billing).
- Product or service development flows (product → tech → operations → risk/legal).
- Cross-regional or cross-BU topics (global product → regional sales, central functions → local units).
- Risk and control points (business units ↔ risk/compliance, operations ↔ quality).
A practical way to map interfaces:
- Select priority flows. Choose 3–6 flows that are strategically important or painful today (e.g., “lead-to-order,” “idea-to-launch,” “incident-to-resolution”).
- List involved units and roles. For each flow, identify which units, teams, and key roles participate.
- Draw the current-state interface map. Use a simple diagram showing units as nodes and interfaces as arrows. For each interface, note:
- What passes through (information, decisions, approvals, materials).
- How often it happens.
- Typical problems (delays, rework, conflict, ambiguity).
- Overlay accountability. For each interface, ask:
- Who owns the end-to-end outcome?
- Who is responsible for the handoff quality?
- Where does escalation go if something breaks?
The aim is to spot patterns such as:
- Interfaces with no clear owner on either side (“we just send it and hope”).
- “Ping-pong” interactions where work bounces back and forth.
- Excessive dependencies on a single function (e.g., everything must pass through legal or IT, regardless of risk level).
- Unstructured collaboration relying on personal relationships rather than defined mechanisms.
You do not need elaborate tools. A handful of simple interface maps can reveal where the structure you designed in earlier chapters needs corresponding connective tissue to work in practice. Those maps then become design inputs for cross-functional teams, norms, and service-level agreements.
12.2 Designing Cross-Functional Teams and Squads
Cross-functional teams are one of the most powerful ways to manage complex interfaces. Instead of passing work between silos, you put the critical capabilities in one team with a shared goal. But poorly designed cross-functional teams can become talking shops or parallel hierarchies that confuse accountability.
There are a few common types:
- Standing cross-functional teams. Persistent teams owning an end-to-end outcome (e.g., a customer journey team or a product team).
- Squads/tribes (agile-style). Small, stable teams focused on a product, feature, or problem space, often grouped into tribes around a broader domain.
- Temporary “tiger teams.” Time-bound teams formed to solve a specific problem or deliver a project.
- Centers of excellence (CoEs). Cross-functional expert groups setting standards and supporting execution across units.
Regardless of type, effective cross-functional teams share design elements:
- Clear mandate and scope.
- What outcome(s) is the team accountable for (e.g., NPS for a journey, launch of a product, reduction in incident rates)?
- What is in and out of scope (segments, geographies, product set, time horizon)?
- Defined leadership and reporting.
Decide:- Who leads the team (role, not name).
- Whether team members are fully dedicated or partially allocated.
- How line managers and team leads share responsibility for performance and development.
A common pattern is: line manager owns career and functional craft; cross-functional team lead owns day-to-day work and priorities.
- Right mix of capabilities.
Include all critical skills needed to deliver the outcome end-to-end. For example, a digital product squad may require product, design, engineering, data, and operations. If a critical capability is missing, you have just created another dependency. - Backlog or work program.
Even outside formal agile, treat the team’s work as a prioritized backlog:- A transparent list of initiatives, problems, and tasks.
- Clear prioritization rules (who decides what comes first and why).
- Regular re-prioritization cadence.
- Time and capacity discipline.
Part-time membership is sometimes unavoidable, but uncontrolled “fractional people” kill cross-functional teams. If a role is critical to the team’s success, you should either:- Dedicate that person for a significant portion of their time; or
- Provide a clear, limited time allocation with agreed trade-offs (what they will stop doing elsewhere).
A simple checklist when designing a cross-functional team:
- Can the team achieve its mandate without depending on constant approvals from outside?
- Is there a single person accountable for the team’s outcome?
- Does each member understand who their “real boss” is day-to-day and over the long term?
- Are conflicts between functional priorities and team priorities resolved by a clear rule, not case-by-case negotiation?
If you cannot answer “yes” to most of these, the team is likely to become a forum, not a high-performing unit.
12.3 Collaboration Norms, Meeting Architecture, and Escalation Paths
Even with well-designed interfaces and teams, collaboration can still fail if norms and meeting patterns are left to chance. Most organizations do not have too few meetings; they have too many of the wrong kind, with vague purposes and no decisions.
You can think about collaboration design in three parts: norms, meeting architecture, and escalation paths.
Collaboration norms
Norms are the everyday rules of engagement you expect people to follow. They do not need to be elaborate, but they should be explicit and aligned with your design objectives. Typical areas:
- Channels: What is best handled in email, chat, documents, or live meetings? For example, decisions above a threshold documented in a short note; routine updates posted in a channel rather than in recurring meetings.
- Response time expectations: For critical interfaces, define expected response times (e.g., “risk sign-off on standard deals within two business days,” “IT support acknowledges high-severity incidents within 15 minutes”).
- Preparation standards: Pre-reads for decision meetings must include options and recommendations, not just data; no decisions taken without the right roles present.
- Behavioral norms: Listening, challenge, and escalation. For instance, “disagree in the room, commit outside” or “raise issues early, not after decisions are taken.”
Agree these norms at the top-team level and model them visibly. Codify them in a simple “ways of working” guide shared with managers and teams.
Meeting architecture
Meeting architecture is the deliberate design of recurring forums and their purpose. Instead of each leader setting up their own meetings ad hoc, you design:
- A small set of core cross-functional meetings aligned to value streams (e.g., S&OP, portfolio review, risk review, customer-experience review).
- Clear cadences: daily/weekly operational huddles, monthly performance reviews, quarterly strategic reviews.
- Ownership: who chairs each meeting, who must attend, and who can skip.
- Decision vs. information: each recurring meeting tagged as primarily for decisions, problem-solving, or information-sharing, with agendas reflecting that.
A useful rule: if a meeting has more than 10–12 regular participants and rarely produces clear decisions or actions, you should redesign or eliminate it.
Escalation paths
Escalation is how you resolve issues that cannot be solved at the immediate interface. When escalation paths are unclear, people either escalate everything “just in case” or avoid escalation altogether, leading to stalemates.
Design simple escalation ladders for key cross-unit domains:
- First level: direct discussion between the roles involved (e.g., BU lead and functional lead).
- Second level: resolution in an agreed cross-functional forum (e.g., product council, regional committee).
- Third level: sponsor or executive committee decision.
For the most frequent disputes (e.g., pricing exceptions, risk vs. growth, global vs. local product decisions), write down:
- First attempt to resolve: which roles, within what time frame.
- Where it goes next if unresolved.
- Who has the final say and on what criteria (often your design principles).
If you design norms, meeting architecture, and escalations together, you reduce a large amount of ambient friction without changing the org chart at all.
12.4 Agile and Hybrid Models: When and How to Use Them
Agile and squad-based models have become a default answer to many collaboration problems. Used well, they can dramatically improve speed, customer focus, and team engagement. Used indiscriminately, they create confusion and parallel structures.
The first design question is where agile is appropriate:
- Work with high uncertainty and changing requirements (digital products, customer-facing journeys, innovations).
- Domains where small, empowered teams can deliver end-to-end value increments (features, campaigns, service improvements).
- Situations where rapid experimentation and feedback loops matter more than strict predictability.
By contrast, many core operations, compliance-heavy processes, and transactional back offices do not benefit from full agile transformation. They may benefit from lean or continuous improvement, but not necessarily from tribes and squads.
If you choose to use agile, be clear about what you are changing:
- Team structure: small, stable squads with cross-functional membership.
- Role definitions: product owner (accountable for value), scrum master or team facilitator (for process), chapter leads (for functional craft) where relevant.
- Planning cadence: sprints, sprint reviews, and backlogs replacing large, infrequent planning cycles in those domains.
- Governance: moving many decisions into the squad (within guardrails) rather than through central committees.
Often, the most practical design is a hybrid model:
- The line hierarchy (BUs, functions, regions) remains the home for people management, budgeting, and long-term capability building.
- Squads and tribes cut across that hierarchy to deliver specific outcomes, with clear rules on who “owns” what and how conflicts are resolved.
- Some functions (e.g., security, risk) maintain independent sign-off responsibilities even as they embed team members in squads.
To make hybrid models work, you must answer a set of integration questions:
- How are people allocated between line and squad work (e.g., fully dedicated to a squad; percentage allocations)?
- Who evaluates performance: line manager, product owner, or both? How are their inputs combined?
- How do squads connect into your broader portfolio and budgeting processes?
- How do you avoid creating a privileged “agile world” and a neglected “non-agile world”?
A minimal design discipline for agile/hybrid models:
- Define a small number of domains where you will genuinely work in an agile way; do not try to “go agile everywhere” in one step.
- For each domain, design the squad/tribe structure, product ownership roles, and chapter/functional leadership explicitly.
- Integrate squads into governance: portfolio boards, risk reviews, architecture boards; avoid duplicating forums.
- Align HR processes (performance, career paths, rewards) so agile roles and line roles are treated consistently and fairly.
Used this way, agile becomes one of several collaboration patterns in your operating model, not a competing religion.
12.5 Reducing Friction: Handoffs, SLAs, and Service Catalogs
Many frustrations about “silos” are, at root, frustrations about handoffs: who does what, when, and to what standard. Handoffs can be significantly improved with simple mechanisms: clearer steps, service-level agreements (SLAs), and service catalogs, especially where shared services or enabling functions are involved.
Designing cleaner handoffs
From your interface maps, identify a handful of critical handoffs that repeatedly cause issues (e.g., sales → delivery, product → operations, BU → shared services). For each one:
- Map the current steps: who initiates the handoff, what information is provided, who accepts it, how progress is tracked.
- Define the minimum viable information that must accompany each handoff to avoid rework.
- Agree on what constitutes a “complete” handoff (e.g., fully signed contract, approved specs, required data fields).
Small changes—templates, checklists, standard request forms—often remove a lot of ambiguity and blame.
Service-level agreements (SLAs)
SLAs make expectations explicit between “providers” and “customers” inside the organization. They are not contracts in a legal sense, but they should be specific enough to change behavior.
For each key internal service (IT, HR operations, finance operations, analytics, legal, risk):
- Define services: what the unit provides (e.g., “standard reporting,” “incident resolution,” “contract review”).
- For each service, define:
- Typical response and resolution times.
- Quality measures (e.g., accuracy, completeness).
- Inputs required from the requesting unit.
- Prioritization rules (what counts as high vs low priority).
SLAs work best when they are jointly owned:
- The provider commits to the SLA where the requester meets agreed input standards.
- Both sides review performance periodically and adjust capacity or expectations.
Avoid over-engineering. Start with a small number of high-impact services and a few metrics each, then iterate.
Service catalogs
A service catalog is simply a structured description of what a shared or enabling function offers, to whom, and how to engage with it. Without a catalog:
- Business units do not know what they can reasonably ask for.
- Support functions get random, bespoke requests and struggle to prioritize.
- People complain about “unresponsive” services when, in reality, expectations were never aligned.
A basic service catalog for a function includes:
- List of services, grouped logically (e.g., “hire-to-retire” for HR, “record-to-report” for finance).
- Service descriptions in business language.
- Eligibility and scope (who can use it, for which geographies or units).
- Standard channels for requests (portals, forms, contacts).
- Links to SLAs and any relevant policies or templates.
You do not need an enterprise IT platform to start. Even a well-maintained document or intranet page is a step change versus implicit expectations.
Putting it all together
To systematically reduce friction:
- Prioritize 5–10 critical interfaces based on strategic importance and pain.
- For each, design cleaner handoffs (steps, inputs, acceptance criteria).
- Where the interface is between a provider and many customers (e.g., shared services), define a simple service catalog and SLAs.
- Embed these expectations into ways of working: onboarding materials, manager training, and performance reviews.
Over time, these mechanisms turn vague complaints about “poor collaboration” into specific, fixable issues about flows and commitments. They also make your organizational design more robust: as you adjust macro- and micro-structure in future, you already have a language and toolkit for managing the spaces between the boxes, not just the boxes themselves.
