DevOps: A Set of Practices, Not a Job Role
In the world of modern software development, "DevOps" is often a misunderstood and misapplied term. Many organizations treat it as a job role—posting "DevOps Engineer" positions or expecting their engineers to excel equally in software development, infrastructure, operations, and security. Indeed, here on the Silicon Island, that approach seems to be pretty much the norm.
While cross-functional expertise is valuable, framing DevOps as a job role rather than a set of collaborative practices can lead to stress, burnout, and suboptimal outcomes not only for individuals and teams but also for the business.
What Is DevOps?
At its core, DevOps is a set of practices aimed at improving collaboration between development and operations teams. It focuses on:
Automation: Streamlining repetitive tasks such as deployments and testing.
Collaboration: Breaking down silos between teams to foster shared ownership.
Continuous Delivery: Ensuring that software is always in a deployable state.
Monitoring and Feedback: Using real-time metrics to improve system reliability and performance.
Nowhere in the essence of DevOps does it mandate that every individual must embody all these practices!
Yet, when companies treat "DevOps" as a role, it implies that a person must possess deep expertise in multiple domains: coding, infrastructure as code, CI/CD pipelines, Kubernetes, cloud platforms, monitoring systems, and more.
The Pitfalls of Treating DevOps as a Job Role
Unrealistic Expectations
Expecting every "DevOps Engineer" to be an expert in everything creates unrealistic hiring requirements. Job descriptions that demand expertise in a dozen tools or domains often set people up for failure. Moreover, these overly broad requirements can discourage highly skilled candidates from applying, as they may feel they don’t check every box, even if they excel in the core skills needed for the role. This leads to a narrower, less diverse pool of applicants and the risk of missing out on strong contributors.Stress and Burnout
For individuals, the pressure to master an ever-expanding array of technologies leads to stress and burnout. This is especially damaging in environments where roles aren't clearly defined, and employees are expected to "figure it out" on their own. The problem becomes even more acute in organizations with more junior engineers who lack experience with the technologies and approaches being used, as well as in organizations that don't provide solid, formal professional training to help employees build the necessary skills.Shallow Expertise
When everyone is tasked with being a "jack of all trades," the team risks becoming "masters of none." In complex software systems, shallow expertise can lead to costly mistakes in areas such as security, scalability, or performance optimization. It also increases the likelihood of more frequent and severe system outages, as gaps in specialized knowledge make it harder to identify and address issues effectively.Diminished Career Satisfaction
Engineers often have specific interests and career aspirations—whether it’s becoming a backend systems expert, an SRE, or a frontend developer. Forcing people into roles where they cannot focus on their areas of passion diminishes job satisfaction and long-term career growth. This misalignment can also lead to increased rates of attrition, as talented engineers may leave for roles that better align with their skills and aspirations.
The Need for Specialization in Cross-Functional Teams
The complexity of today’s software systems necessitates specialization. Backend developers, frontend developers, database administrators, site reliability engineers, and security and infrastructure specialists all bring unique and valuable perspectives. While individuals should have a working knowledge of related areas, they should not be expected to have deep expertise in all of them.
For example:
Backend developers focus on building efficient and maintainable APIs, while having a basic understanding of CI/CD pipelines.
Infrastructure engineers set up scalable cloud environments and optimize system reliability, while collaborating with developers on deployment strategies.
QA engineers design and automate tests, working closely with developers to integrate quality into the pipeline.
Security specialists identify vulnerabilities, implement safeguards, and ensure compliance with security standards, while collaborating with teams to build secure-by-design systems.
A well-functioning cross-functional team brings these specialists together and relies on solid DevOps practices to enable smooth collaboration.
What DevOps Looks Like as a Set of Practices
When DevOps is treated as a set of practices rather than a role, the focus shifts from "Who is the DevOps expert?" to "How can we work together effectively?" Here are some examples:
Shared Ownership of Pipelines
Developers and infrastructure engineers collaborate to design CI/CD pipelines. Developers write build scripts and test cases, while infrastructure engineers ensure that the pipelines integrate seamlessly with deployment environments.Infrastructure as Code (IaC)
Infrastructure engineers manage IaC templates (e.g., Terraform, CloudFormation), but they work closely with developers to ensure the infrastructure meets application needs. Developers might learn the basics of IaC, but they don't need to become experts.Monitoring and Feedback
Developers add application-level logging, while operations teams set up system-level monitoring and set up the logging infrastructure (e.g., Prometheus, Grafana). Both teams collaborate on defining Service Level Objectives (SLOs) that align with business goals.Incident Management
Operations teams lead incident response and root cause analysis, but they include developers in post-mortem discussions to identify ways to improve resilience.Automated Testing
Developers write unit and integration tests, while QA engineers implement performance, end-to-end tests, and handle any required manual acceptance testing. Both groups ensure that tests run automatically in the pipeline.
Building a Sustainable DevOps Culture
To make DevOps practices work for the individuals, team, and business, organizations should:
Encourage Collaboration
Break down silos between teams and promote shared responsibility for outcomes. Use tools like Slack or Teams to foster real-time communication.Invest in Training
Provide training on DevOps practices and tools, but don’t expect everyone to master everything. Create learning pathways that align with individual career goals.Define Clear Roles
Clearly define what is expected of each role on the team. For example, an SRE might focus on monitoring and scalability, while a developer concentrates on application logic.Foster a Growth Mindset
Encourage individuals to broaden their knowledge but allow them to specialize in areas where they excel and enjoy working.Adopt Tools That Support Collaboration
Use tools that simplify cross-functional collaboration, such as GitHub Actions, Jenkins, Kubernetes, or Terraform.
Conclusion
DevOps is not a job title—it’s a way of working. By treating DevOps as a set of practices that bring teams together, organizations can create sustainable processes that balance the need for specialization with the benefits of collaboration. This approach not only reduces stress on individual engineers but also leads to better outcomes for software teams and the businesses they support.
In the end, DevOps is about culture, communication, and continuous improvement—not about asking each person to carry the weight of the entire system.
Does your organization employ individuals in the role of “DevOps Engineer”? Have there been any reengineering or reorganization initiatives undertaken to better align with DevOps practices? I would appreciate hearing your perspectives, and if you are interested in discussing further, please feel free to reach out. I'd be more than happy to offer any assistance or insights as needed.
