What separates a competent DevOps engineer from a truly effective one? According to Marcel Dempers, a software engineering specialist, the answer lies less in mastering a specific tool chain and more in cultivating a set of durable professional habits. In a widely shared presentation, Dempers outlined advice for anyone building or deepening a DevOps career. The core message: keep an open mind, understand foundations, challenge your biases, and resist the pull toward unnecessary complexity.
Below are four habits that effective DevOps engineers consistently demonstrate.
1. They Strive to Understand Both Sides of the Fence
DevOps sits at the intersection of software development and IT operations. Effective practitioners do not settle for expertise in only one domain — they actively work to understand the other side.
“If you have trouble writing code, focus on it and learn how to code,” Dempers says. “If you have trouble learning about hardware, focus on that. Learn about infrastructure and learn about networking, load-balancing, proxies.”
This cross-discipline fluency has a practical payoff: it enables engineers to build their own tooling — command-line interfaces, automation scripts, monitoring integrations — that bridges the gap between development workflows and operational processes. Rather than depending on others to translate requirements across the dev/ops divide, a well-rounded engineer can navigate it independently.
2. They Invest in Understanding Underlying Foundations
The DevOps ecosystem moves fast. New tools, platforms, and services appear constantly, and there is rarely enough time to thoroughly learn every one of them. Dempers argues that the most durable investment is not learning how to use a technology, but understanding why it works the way it does.
He offers a concrete example: “Instead of just learning how to run a Docker container, you dive into the Linux kernel features that make containerization possible — namespaces, cgroups, and so on. Once you understand those, how Docker works becomes obvious. You can then move on to technologies like Kubernetes, which rely on the same kernel primitives, and understand them far more quickly.”
This foundational knowledge also improves communication across the organization. When you understand how the pieces fit together at a fundamental level, you can explain trade-offs clearly, identify gaps in a proposed architecture, and make better decisions — rather than simply following vendor documentation.
3. They Actively Work to Manage Bias
Every experienced engineer develops opinions about technologies — preferred languages, favorite orchestration platforms, go-to monitoring stacks. That is natural and, in moderation, useful. The problem arises when preference hardens into tunnel vision.
“Bias toward certain technologies is fine, but if you develop tunnel vision around a particular stack, it won’t help you or your team,” Dempers explains. “Knowing and recognizing the strengths and weaknesses of the technologies you work with is a genuine superpower. It helps you make better decisions and strengthens your DevOps career.”
In practice, this means being willing to recommend a tool you personally dislike when it is genuinely the right fit for the problem at hand, and being honest about the limitations of tools you favor. It also means staying curious about technologies outside your comfort zone rather than dismissing them.
4. They Prioritize Simplicity Over Over-Engineering
One of the most persistent failure modes in modern engineering is complexity for its own sake. Cloud providers offer hundreds of services, infrastructure-as-code tools enable elaborate configurations, and there is constant pressure — from vendors, from peers, from the desire to look sophisticated — to reach for complex solutions.
“We live in a world where developers and operations teams are constantly over-engineering,” Dempers says. “Cloud providers make it easy to overspend and over-build.” The antidote, he suggests, is deliberate restraint: stepping back before designing a solution and asking a deceptively simple question — Is this actually the problem I need to solve?
Talking to the right stakeholders early often reveals that the assumed problem is not the real one, or that a far simpler solution already exists. The discipline of challenging problem definitions before investing in solutions is a habit that saves engineering time, reduces operational overhead, and keeps systems maintainable.
Putting It Together
None of these habits require a specific certification or years of experience in a particular platform. They are mindset shifts that compound over time:
- Learn both sides — close the knowledge gap between development and operations so you can work fluidly across the boundary.
- Understand foundations — invest in first-principles knowledge so that learning new tools becomes faster and comparisons become clearer.
- Manage bias — know your preferences but do not let them drive decisions; evaluate each situation on its own merits.
- Keep it simple — resist over-engineering; validate the problem before committing to a complex solution.
The common thread is intellectual honesty — about what you know, what you do not know, and what the situation actually requires. That disposition, more than any particular tool or framework, is what defines an effective DevOps engineer.
Original advice attributed to Marcel Dempers, software engineering specialist, from a public presentation on DevOps career development.