Designing a hub-and-spoke operating model

A company with several business units has a practical staffing choice: centralize its data and AI team, put specialists inside each unit, or combine the two.

In a hub-and-spoke model, the central team is the hub and teams in the business units are the spokes. They share engineering resources while keeping delivery close to the people doing the work. Its success depends on a clear division of responsibility and a useful working relationship between the central team and the units.

What belongs in the center

The central team can own shared infrastructure, deployment tooling, evaluation methods, and the review process. It can also provide specialist skills that would be costly to duplicate in every unit.

Treat those capabilities as services other teams need to use. Make it clear how to request access, get engineering help, schedule a review, and raise a problem. Shared standards are easier to follow when the supported tools are available and the response times are known.

The center also needs a way to resolve priorities when several units need the same specialist. Put those decisions with someone who can weigh the competing business cases.

What stays with the business

Business teams should help select and fund the use cases, define the process changes, and own the result. Their analysts and subject-matter experts bring knowledge that a central team cannot acquire from requirements alone.

A planning project, for example, needs someone who understands actual changeovers, material substitutions, and customer priorities. Give that person time to participate in design and testing, and authority to bring unresolved questions to the process owner.

Embedding an expert helps the team find expensive exceptions early. It also reveals where the current process already works well.

Keep delivery connected to support

For each use case, assemble the roles needed to take it through release: a business owner, relevant data and application engineers, subject-matter expertise, and responsibility for adoption and support. Some people may cover several roles.

Keep continuity across the build and handover. If a separate team will operate the system, involve it in the design and testing so it can challenge support assumptions before launch.

The central team should provide existing pipelines, test tooling, and release templates where they fit. Local teams should identify requirements that the shared components do not yet support.

Watch for the two recurring problems

A central team can become a queue that the business routes around. Independent local teams can duplicate infrastructure and define the same records differently.

Review both: how long units wait for help and how much repeated engineering they are doing. Use that evidence to adjust capacity, authority, or the shared tooling. The organizational chart is a starting arrangement; the work will show where it needs to change.