Enterprise IT is changing at a rapid pace, and organizations that want to remain competitive must adopt modern software development practices. DevOps — the cultural and technical movement that unites development and operations teams toward shared goals — is central to that shift. But implementation is rarely smooth.
At a 2017 Dell EMC World conference breakout session, Emily Kaiser and Brian Roche from Dell EMC’s DevOps Dojo outlined seven critical lessons businesses encounter when putting DevOps into practice. Their insights remain highly relevant for any organization navigating a DevOps transformation today.
1. Define What DevOps Actually Means for Your Organization
Before a team can practice DevOps effectively, they need a shared, concrete definition of what it means in their context. Roche stressed the importance of clear communication and getting every stakeholder on the same wavelength so the team can unify around a common mission.
A common trap is measuring vanity metrics — lines of code written, number of commits — rather than outcomes that matter. DevOps practitioners should instead measure the real effect their work has on users and on team capability. Core operating principles include eliminating waste and investing in automation to support the cultural shift.
“At its heart, DevOps is a cultural movement. Businesses employ automation to support that movement.”
Brian Roche, Dell EMC DevOps Dojo
2. Know Why You Are Adopting DevOps
Organizations must be able to articulate a clear, honest answer to the question: why DevOps? Kaiser was direct: “DevOps is anything but comfortable.” The cultural transformation it demands is significant, and without a compelling reason, momentum will stall when friction arises.
Implementing DevOps means making everyone responsible for quality — not just QA engineers or release managers. Teams must develop shared context and genuine empathy for colleagues across development, operations, security, and the business. Critically, DevOps cannot succeed without buy-in at every level of leadership. Teams must learn to tailor the case for DevOps to different audiences: technical leaders, product managers, finance stakeholders, and executives all need a version of the argument that resonates with their priorities.
3. Build a Culture of User Obsession
In a mature DevOps practice, the end user is never an afterthought — they are the central reference point for every decision. Project scope, sprint priorities, and release criteria should all be evaluated through the lens of user value.
Kaiser and Roche recommended test-driven development (TDD) as a practical framework for embedding this mindset into daily engineering work. The TDD cycle — write a failing test, implement the minimum code to pass it, then refactor — keeps the team anchored to defined, verifiable behaviour rather than assumed requirements.
4. Recognize That Your Team Is the Glue
Technology alone does not make DevOps work. The people and relationships within the team are what hold a DevOps implementation together. Team leaders must actively invest in three areas:
- Empathy: Understanding where teammates are coming from — their constraints, pressures, and perspectives — reduces friction and blame during incidents.
- Feedback: Regular, structured feedback loops surface problems early and create opportunities to recognise success.
- Trust: Attending to how team members feel builds the psychological safety needed for honest communication and dependable collaboration.
The Dell EMC Dojo team used retrospectives as a formal mechanism for this. After each project, team members would come together to reflect on what they learned, what obstacles they faced, and what they would do differently — reinforcing empathy and continuous improvement as team habits rather than aspirational values.
5. Expect to Fail — and Build Systems That Make Failure Safe
Roche and Kaiser were candid: failure happens often. The goal is not to eliminate failure but to make recovering from it fast and learning from it systematic. Continuous delivery pipelines are the operational mechanism that makes this possible — by shortening the feedback loop between a change and its consequences, teams can detect and fix problems in minutes or hours rather than days.
A practical approach when starting out:
- Identify the specific problem you are trying to solve.
- Build a minimum viable product (MVP) for your DevOps practice — don’t try to implement everything at once.
- Iterate: make incremental changes, learn from each cycle, and adapt.
6. Scale DevOps Deliberately, Starting with APIs and Mindset
As DevOps practices mature, scaling them across larger teams and more complex systems requires two parallel investments: technical architecture and cultural change.
On the technical side, Roche identified APIs as the foundational building blocks for scaling DevOps. Well-designed APIs enable services to be deployed, monitored, and updated independently — a prerequisite for the autonomous, fast-moving teams that DevOps enables.
On the cultural side, operators need to adopt a development mindset. This means:
- Treating infrastructure as code — version-controlled, peer-reviewed, and tested like application code.
- Automating repetitive operational tasks.
- Investing in health monitoring and observability so the team can detect and diagnose problems quickly.
- Developing empathy for developers, just as developers must develop empathy for operations.
Roche’s underlying point was that development and operations teams ultimately want the same outcome: reliable software running in production. Recognising that shared goal makes collaboration feel natural rather than forced.
7. Learn by Doing
No amount of training, certification, or documentation prepares a team for DevOps as effectively as actually practising it. Kaiser argued that hands-on experience deepens conceptual understanding and sharpens problem-solving skills in ways that passive learning cannot.
Agile and lean methodologies provide a structure for this approach. Short iterations, regular retrospectives, and a bias toward shipping working software over writing comprehensive plans all reinforce the habit of learning from real experience and adjusting course continuously.
Key Takeaways
The seven lessons from Kaiser and Roche share a common thread: DevOps is fundamentally a human and cultural endeavour that technology enables, not replaces. Organisations that treat DevOps as a tooling upgrade tend to stall. Those that address the cultural and collaborative dimensions — shared purpose, empathy, psychological safety, and continuous learning — are better positioned to realise its benefits at scale.
- Define DevOps clearly and consistently across your organisation.
- Build a compelling, audience-specific case for why DevOps matters.
- Keep users at the centre of every engineering decision.
- Invest in team relationships as seriously as you invest in tooling.
- Design systems and processes that make failure safe and recovery fast.
- Use APIs and infrastructure-as-code as the foundation for scale.
- Prioritise hands-on, iterative learning over theoretical preparation.
Source: Original reporting based on a breakout session by Emily Kaiser and Brian Roche, Dell EMC DevOps Dojo, at Dell EMC World 2017, as covered by TechRepublic.