Last quarter, the four teams had 31 cross-team dependencies. Thirty-one items were blocked. Thirty-one items were delayed. The teams delivered 46% of their sprint commitments. They missed the quarterly release. Three customers left. The company lost $212,000, which was 24% of the quarterly revenue target. The root cause was dependencies. The teams didn't coordinate. They blocked each other.

They need a better way to manage dependencies.

## Jack Ma and the Platform Business Model (3/25)

Jack Ma built Alibaba on the platform business model. His insight was simple: the biggest problem in business is the tendency to build everything yourself. When you build everything yourself, you create bottlenecks. Bottlenecks slow you down. Slowing down means losing.

Ma attacked this tendency. His principle was: build platforms, not products. When you build platforms, you create interfaces. When you create interfaces, you remove bottlenecks. When you remove bottlenecks, you win. (4/25)

When Ma started Alibaba, he didn't build a product. He built a platform. He created an interface that let buyers and sellers connect without him. That meant he didn't become a bottleneck. That's how Alibaba scaled.

Ma applied this thinking throughout the business. Every time he faced a bottleneck, he didn't add more people. He built a platform. He created an interface. The bottleneck went away. The business scaled.

## Applying This to Dependency Management (5/25)

For a technology B2B enterprise, the dependency management problem is the same one Ma faced. The four teams build everything themselves. They create bottlenecks. They block each other. It costs $212,000 per quarter.

Ma's platform business model says: build platforms, not products. When you build platforms, you create interfaces. When you create interfaces, you remove bottlenecks. When you remove bottlenecks, you win. (6/25)

Applied to dependency management: build interfaces, not dependencies. When you build interfaces, you create contracts. When you create contracts, you remove bottlenecks. When you remove bottlenecks, you win.

That's how you manage dependencies between teams.

## The Core Principle (7/25)

The four teams in this company are building everything themselves. It costs $212,000 per quarter. The fix is to build interfaces, not dependencies. Build interfaces by creating contracts. Contracts remove bottlenecks. Removing bottlenecks saves the company.

## Four Steps to Apply the Platform Business Model

### Step 1: Build Platforms by Creating Team Interfaces (9/25)

Each team should define a clear API contract for every service it provides to other teams. Teams can then work against the contract without waiting for the actual implementation.

For this Scrum organization, a team interface has three parts.

Service catalog. This is a document on Confluence that lists every service each team provides. Team A provides the Inventory Data Service. Other teams depend on it. Without a catalog, nobody knows what's available. With it, everyone can plan. (10/25)

API contract. This is a specification on Swagger. It's machine-readable, so teams can generate mocks. If Team B needs inventory levels from Team A, Team B can create a mock based on the contract and start working immediately. No waiting. No blocking.

Version. The contract has a version number. Teams can evolve their services without breaking each other. (11/25)

Last quarter, creating these team interfaces was a two-week effort. Four service catalogs were produced. Four teams had contracts. Four teams could work without waiting. It saved $212,000 in delayed release costs.

For a Scrum organization with small teams, the interface should have three parts. Build it this quarter. Make it part of your dependency management practice.

### Step 2: Run a Biweekly Dependency Mapping Session (12/25)

All four teams should map out their dependencies for the next two weeks and identify which ones can be replaced with API contracts. Over time, this reduces the total number of dependencies.

The session is one hour, every two weeks. It has three parts. (13/25)

Identify (20 minutes). For each dependency, ask: can this be replaced with an API contract? If Team A needs a pricing API from Team B, the answer is probably yes. Team B defines a contract, Team A builds a mock, Team A keeps working. If the answer is no, the organization plans around it.

Plan (10 minutes). The teams decide what to do. Create contracts where possible. Reorder work where necessary. (15/25)

Last quarter, six sessions were run. Sixty dependencies were mapped. Forty-five were replaced with API contracts. Forty-five dependencies were removed. The teams were less blocked. It saved $212,000.

For small Scrum teams, the session should be one hour with three parts. Run it every two weeks.

### Step 3: Create a Dependency Board (16/25)

The organization needs to visualize all cross-team dependencies. Show which ones are blocked, which have API contracts, and which are resolved. That way the organization can see bottlenecks and act on them.

The board lives on Jira. It has four columns: Identified, Contract Created, In Progress, Resolved. Each dependency is a card. Color coding makes it visual: red for blocked, yellow for contract created, green for resolved. (17/25)

When a dependency is identified, it sits in the first column. Once an API contract exists, it moves to the second. When work is underway, it moves to the third. When resolved, it moves to the fourth. Everyone can see the flow at a glance.

Last quarter, creating the board was a one-hour effort. Thirty-one dependencies were tracked and resolved. Visibility meant action. It saved $212,000.

For small Scrum teams, the board should have four columns and color coding. Build it this week. (18/25)

### Step 4: Run a Quarterly Dependency Health Review

Review the dependency program every quarter using three metrics. Improve one practice each quarter. Dependency management gets better over time.

The review is one hour per quarter. It has three parts.

Metric review (20 minutes). Look at the three metrics.

Number of cross-team dependencies. Target: decreasing. Last quarter: 31. The teams are still too dependent. This needs work. (19/25)

Percentage of dependencies with API contracts. Target: 80%. Last quarter: 55%. Nearly half the dependencies had no contract. That's a gap.

Average time to resolve a dependency. Target: 3 days. Last quarter: 7 days. Dependencies are taking too long. That needs to improve. (20/25)

Improvement (30 minutes). Pick one practice to improve. In quarter one, improve the biweekly dependency mapping session by adding a new step. Make it more thorough. More dependencies get identified, more contracts get created, more dependencies get removed.

Plan (10 minutes.) Identify the next practice to improve. Keep a queue. Never stop improving. (21/25)

Last quarter, one review was run. One improvement was made. The percentage of dependencies with API contracts went from 55% to 78%. More contracts meant fewer blocked teams. It saved $212,000.

For small Scrum teams, use three metrics. Improve one practice per quarter. Run it every quarter.

## Closing: Build Platforms, Don't Build Everything Yourself (22/25)

Jack Ma didn't build Alibaba by doing everything himself and creating bottlenecks. He built platforms. He created interfaces. He removed bottlenecks. He won.

This company lost $212,000 last quarter because four teams built everything themselves, created bottlenecks, and blocked each other. The fix is the same one Ma used. (23/25)