Integrate Ops into the daily work of Development

If you can't reorganize ops into market-oriented teams overnight, you still need to break the wall. Three concrete patterns to embed ops where the work is happening — pick the one that fits your scale.

Testing, operations, and security are everyone's job, every day. Not a separate phase, not a separate team's responsibility. The DevOps Handbook gives three patterns for getting Ops out of its silo and into dev teams, ordered from heaviest investment to lightest.

// three integration patterns

PAT_01

ONLINE

diversity_3

Embed Ops engineers

strongest · highest investment

Ops engineers join the service team full-time. Same standup, same backlog, same on-call rotation. Best when you have enough Ops headcount and service teams to make it work.

PAT_02

IDLE

link

Assign Ops liaisons

medium · scalable

One Ops engineer is the designated point person for each service team — partial alloc, attends weekly. Less than full embed but still ends the random-ticket pattern. Works at mid-scale.

PAT_03

STANDBY

rate_review

Invite Ops to retros

lightest · start here

Ops attends dev sprint retrospectives, planning sessions, and demos. No headcount move — pure information flow. Cheapest first step; usually surfaces enough pain to justify the heavier patterns later.

// silos vs long-lived, multiskilled teams

// functional silos

— Specialized teams per phase: Dev → QA → Ops → Sec.
— Handoffs at every boundary; tickets queue.
— Each silo optimizes its slice; nobody optimizes the stream.
— Knowledge dies at handoff. Defects multiply.

// long-lived, multiskilled

— One team owns the service for years.
— All skills inside the team or one liaison away.
— No handoffs for the common case.
— Team accumulates context; defects drop over time.

// case study · target api enablement (2015)

Target's APIs were locked inside legacy systems behind a centralized integration team — every new internal consumer waited months. Their fix:

— Stand up a self-service API platform team. Their job: make it easy for product teams to expose and consume APIs without filing a ticket.
— Treat the API platform itself as a product. Internal teams = customers. Measure adoption.
— Move expertise from a bottleneck team into a platform that scales.

Result: lead time for a new API integration dropped from months to days, and the platform team grew without becoming the new bottleneck. The pattern — turn a functional team into a product team for an internal platform — is the modern playbook (cf. Team Topologies' "platform team" archetype).

download Case study · Target API Enablement (2015) · PDF ~510 KB

help Knowledge Check

Question 1/2

A small org has 1 ops person and 4 dev teams. They cannot embed Ops into each team. What's the right pattern from this module?

// pick one to verify

help Knowledge Check

Question 2/2

An org reorganizes Ops as a 'platform team' (à la Target's API platform), but the platform team owns a 90-day backlog and gates every change with a review board. Did this work?

// pick one to verify

arrow_back mod-03 / teams mod-04 / continuous delivery arrow_forward