Why Teams — Not Individual Engineers — Are the Foundation of DevOps

A persistent myth in the DevOps world is the idea of the “full-stack engineer” — a single person who can handle every layer of the technology stack. In practice, this unicorn is rarely found and even more rarely retained. A more durable and scalable approach is the full-stack team: a balanced group of people who collectively cover the competencies that a single engineer could never realistically master alone.

This concept was explored in a report titled Full Stack Teams, Not Engineers, produced by IT Revolution and informed by discussions at the 5th Annual DevOps Enterprise Forum in Portland, Oregon. The report was led by Jason Cox, then managing director of platform engineering at Disney, along with co-authors from across the industry.

The core argument: DevOps is not an org chart change or a job title. It is a culture, a set of lean principles, and a collection of practices — and those practices are best expressed through cross-functional teams that can own the full delivery lifecycle.

What a Full-Stack DevOps Team Looks Like in Practice

A full-stack team is deliberately composed of people with complementary skills. Rather than searching for one engineer who can do everything, organizations assemble a team that collectively can. A concrete example from the report describes a team responsible for a customer health dashboard used across all customer-facing products. That team included:

• Two back-end engineers
• One front-end engineer
• One data scientist
• One data analyst
• One designer
• One product manager

Each role is considered essential. However, the report also emphasizes that specialist roles are not siloed — members are expected to participate in communities of practice where they share knowledge, develop deeper expertise, and stay connected to their functional discipline even while contributing to a product team.

Another model described in the report is embedded functional experts: specialists from areas like security, data, or UX who are embedded within product teams rather than pooled in a separate department. In this structure, team members carry two reporting relationships — one to their immediate team lead, and one to a functional area manager who maintains career development and discipline-specific standards. This approach ensures that cross-functional teams don’t lose depth or accountability in specialist domains.

4 Ways to Energize Your DevOps Teams

Building a full-stack team is only the beginning. Sustaining that team’s energy, creativity, and collaboration requires intentional investment in environment and culture. The report highlights the concept of the dojo — a dedicated learning and collaboration space — as one of the most effective tools. “Dojo” is a Japanese term meaning “place of the way,” and in a DevOps context it functions as an immersive learning center designed to foster the mindset shifts DevOps requires.

Here are four concrete practices drawn from the report for energizing DevOps teams:

1. Create a Dedicated Space for Learning and Experimentation

The dojo should be placed in a high-traffic area to increase visibility and generate organic interest across the organization. Visibility signals that learning is valued and invites leadership and other teams to engage. The environment itself should be open, inviting, and designed to inspire curiosity — not a sterile conference room, but a space where experimentation feels natural and even encouraged.

2. Design Workspaces That Promote Collaboration

Physical layout has a measurable impact on team behavior. The report recommends arranging workstations to encourage proximity and eye contact — for example, family-style tables without physical barriers between team members. Dual monitors at individual stations can support focused work, while open table arrangements signal that conversation and collaboration are the default mode. Whiteboards and markers should be readily available to support real-time visualization of ideas.

3. Build Open Areas That Break Down Silos

Teams learn best when they can observe and interact with other teams, not just their immediate colleagues. Open-plan zones within the dojo encourage members to step outside their usual context, discover practices from adjacent teams, and build cross-team networks. The report specifically notes that this kind of shared exposure helps team members understand how they can support — and be supported by — others across the organization.

4. Establish a Dedicated Communication and Demo Hub

A well-equipped demonstration and communication area — with a projector or large display, comfortable informal seating, adjustable lighting, and video conferencing capability — serves as a common room for all teams in the learning environment. Regular demos held in this space give teams a low-stakes venue to share progress, solicit feedback, and involve non-technical stakeholders such as business partners and leadership. This closes the feedback loop and keeps the broader organization connected to what DevOps teams are building.

The Long Game: Mastery Takes Time

Cox and his co-authors close with a reminder that DevOps transformation is not a quick fix. Developing the full capability of a cross-functional team — the trust, the shared vocabulary, the collaborative habits — takes sustained effort. As the report puts it: “It takes many decades of hard work and dedication to become a master of all things, and DevOps skills are no different.”

The implication is clear: organizations that invest early and consistently in team structure, learning environments, and cross-functional collaboration will accumulate a compounding advantage over those still searching for the mythical full-stack engineer.

Key Takeaways

• Prioritize full-stack teams over full-stack engineers. Diverse, complementary skill sets distributed across a team are more sustainable and more effective than concentrating everything in one person.
• Use communities of practice to maintain specialist depth even within cross-functional team structures.
• Invest in physical and cultural environments — like the dojo model — that make learning, collaboration, and experimentation the norm.
• Give non-technical stakeholders access to team demos to maintain alignment and organizational buy-in.
• Accept that DevOps maturity is a long-term journey, not a one-time reorganization.

Knowing Kubernetes is no longer a differentiator on its own. The broader ecosystem continues to fragment and evolve, and engineers who stay competitive are those who deliberately expand their skill sets rather than wait for the industry to settle. The following five competencies represent high-value areas worth investing in — regardless of where you are in your career.

1. Scripting and Programming Languages

Scripting remains a foundational skill for I&O engineers. Automating repetitive tasks, orchestrating deployments, parsing logs, and integrating disparate systems all depend on the ability to write reliable scripts quickly.

If you are not yet comfortable with at least one scripting language, that gap should be your first priority. Python is a strong general-purpose choice with broad adoption in automation, API scripting, and data processing. Bash remains essential for Linux-centric environments and is unavoidable in CI/CD pipelines.

If you already write Python or Bash confidently, consider adding Go to your toolkit. Go is increasingly used for infrastructure tooling (Terraform, Kubernetes, and many cloud-native projects are written in Go), compiles to a single binary, and performs well in networked and concurrent workloads. Learning a compiled, statically typed language alongside a scripting language broadens the range of problems you can tackle effectively.

Where to start

• Master Bash fundamentals, including conditionals, loops, functions, and process substitution.
• For Python, focus on modules commonly used in operations: subprocess, os, paramiko, boto3 (AWS SDK), and the requests library.
• For Go, work through the official Tour of Go and then build a small CLI tool relevant to your environment.

2. Infrastructure Automation Platforms

As hybrid and multi-cloud architectures become the default, the ability to manage infrastructure declaratively at scale is critical. Infrastructure automation platforms let teams define desired state, enforce consistency, and reduce manual configuration drift across hundreds or thousands of nodes and services.

The most widely discussed tools in this space include:

• Ansible — agentless, YAML-based, and widely adopted for configuration management, application deployment, and orchestration. Its low barrier to entry makes it a practical first automation platform to learn.
• Puppet — agent-based, with a strong presence in large enterprise environments. Its declarative language (Puppet DSL) and reporting capabilities make it well-suited for compliance-heavy organizations.
• Terraform — a provider-agnostic infrastructure-as-code tool with a rapidly growing user base. Terraform’s HCL syntax and state management model are widely used for provisioning cloud resources across AWS, Azure, GCP, and many other providers.
• Chef and Salt — both remain relevant in specific enterprise contexts, particularly where their respective strengths (Chef’s Ruby-based recipes, Salt’s speed at scale) align with organizational needs.

You do not need to master all of these. Start with the tool most relevant to your current environment, then invest time in Terraform if your work involves cloud resource provisioning — its adoption across the industry has been significant.

3. Cloud Architecture and Design

Cloud infrastructure has matured well beyond rented virtual machines. Modern cloud architecture encompasses serverless compute, managed Kubernetes services, object and block storage tiers, content delivery networks, identity and access management, cost optimization strategies, and the complex interplay between these components in multi-cloud and hybrid environments.

Understanding cloud architecture is not purely a documentation exercise. It requires:

• Business awareness — understanding what workloads actually need, not just what is technically possible.
• Developer empathy — knowing how application teams consume infrastructure and what friction points slow them down.
• Cost literacy — cloud costs can scale unpredictably. Engineers who understand pricing models and can design cost-efficient architectures add measurable value.
• Provider depth — the major providers (AWS, Azure, GCP) each have distinct service models and trade-offs. Breadth across providers is useful; depth in at least one is essential.

Formal certifications from AWS, Google Cloud, or Microsoft Azure can provide a structured path through this knowledge and signal credibility to employers, though hands-on project experience remains equally important.

4. Security and Resilience Engineering

As infrastructure grows more complex, the attack surface expands and the consequences of failures become more severe. Security and resilience are no longer the exclusive responsibility of dedicated security teams — I&O engineers are increasingly expected to build both into the systems they design and operate.

Key areas to develop include:

• Secrets management — tools such as HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault are standard approaches to handling credentials, certificates, and API keys securely at scale.
• Network security and service meshes — mutual TLS, zero-trust networking, and service mesh tools (Istio, Linkerd) provide granular traffic control and encryption within distributed systems.
• Monitoring and observability — meaningful security and resilience require visibility. Invest in logging pipelines, metrics, distributed tracing, and alerting that covers both performance and security signals.
• Chaos engineering — deliberately injecting failures to test system behavior under adverse conditions. Tools such as Chaos Monkey and Gremlin help teams discover weaknesses before production incidents do.
• Cloud security posture management — automated tools that continuously audit cloud configurations against security benchmarks (CIS, NIST) and flag misconfigurations.

The specific tools you prioritize will depend on your environment, but the underlying principle is the same: design for failure and verify that your defenses actually work.

5. Advancing DevOps Collaboration in Practice

DevOps as a concept is well over a decade old. Most organizations have at least adopted the vocabulary, and many have restructured teams around its principles. But organizational change rarely finishes — it stalls, regresses, or plateaus.

The practical question for I&O engineers is not whether to embrace DevOps, but how to push it forward from where your organization actually is. That means asking concrete questions:

• What friction do development teams encounter when interacting with infrastructure? What could be self-service?
• Where do handoffs between Dev and Ops still create delays or errors?
• Are on-call responsibilities and incident response processes genuinely shared, or does Ops still bear a disproportionate load?
• Is infrastructure-as-code reviewed with the same rigor as application code?

Breaking down silos is a prerequisite, not a destination. Once silos are reduced, the harder work of maintaining shared ownership, shared tooling, and shared responsibility begins. Platform engineering — building internal developer platforms that give application teams self-service infrastructure capabilities — is one direction many mature organizations are moving.

This competency is less about a specific tool and more about organizational influence. Engineers who can identify friction, propose solutions, and communicate effectively across team boundaries become multipliers — their impact extends beyond the systems they personally manage.

Building a Learning Plan

Five competency areas is a broad target. A practical approach is to audit your current skill level honestly in each area, identify the one or two gaps most relevant to your current role and near-term career goals, and invest focused time there before moving on.

The I&O engineering field continues to evolve rapidly. The engineers who remain effective are not those who learned a fixed set of tools, but those who developed a habit of deliberate, continuous learning alongside the technical depth to apply new knowledge in production contexts.