Part 4: Human and Organizational Dimension#

Parts 1 through 3 addressed what the automation system should look like and how to operate it. Part 4 addresses the question that the technology cannot answer: what does it take for an organization to actually use it?

A network automation platform can be architecturally correct, reliably scaled, and fully auditable, all the properties that Parts 2 and 3 describe, and still fail to produce organizational capability. The platform exists; the team continues to make changes manually. The tests pass; the engineers do not trust the results enough to let automation act on them without review. The governance model is implemented; the approval gates are consistently bypassed under time pressure because nobody has internalized why they exist. The gap between a working platform and an organization that operates automation well is not a technical gap. It is a human and organizational one.

Part 4 examines that gap through two lenses.

Chapter 13 addresses the cultural shift that network automation requires of individuals and teams. It traces the arc from a network engineering culture built around deep device expertise and manual change discipline to one that treats automation as the primary operating model. The chapter is not a change management guide; it is an examination of the specific resistance patterns that appear reliably when automation is introduced, the skill transitions that engineers navigate, and the organizational structures that either support or undermine the transition. It follows a practicing network engineer named Jordi across a multi-year arc that illustrates how that transition actually unfolds in a real team.

Chapter 14 addresses the organizational model for sustaining automation at scale. It applies product management discipline to automation services: service contracts that make the platform team’s commitments explicit, SLAs that make reliability measurable, and a lifecycle model for automation services that includes definition, delivery, operations, and evolution. The chapter’s core argument is that automation treated as a project, delivered and declared complete, degrades. Automation treated as a product, maintained, governed, and evolved in response to user needs, compounds.

The two chapters are not independent. The cultural work of Chapter 13 creates the conditions in which the organizational model of Chapter 14 can function. A team that has not made the cultural shift will not sustain the discipline that product management of automation services requires. A team that has the discipline but not the organizational model will find its automation accumulating technical debt faster than it can be paid down.

The governance and trust model that Part 3 established, the Policy-as-Code Gates, the Provenance Chain, the Automation Track Record, are the technical foundation on which Part 4’s organizational model rests. The Confidence Ladder in Chapter 13 relies on the instrumentation that Chapter 11 provides. The SLA commitments in Chapter 14 depend on the audit trail and reliability engineering that Chapters 11 and 12 built.

Part 5 builds on the foundation that Parts 3 and 4 together establish: teams that have the platform, the reliability engineering, the governance, and the organizational maturity to operate automation well are the teams that can take the next step toward closed-loop and autonomous operation.

💬 Found something to improve? Send feedback for this chapter