When Job Titles Stopped Meaning Anything
I’ve been a “DevSecOps Engineer” for years now. So has the person who deploys containers without understanding networking. And the person who writes Terraform but has never responded to a 3 AM incident. And the security auditor who’s never written a line of production code.
We all have the same job title, but we don’t all carry the same responsibility.
This bothers me. Not because I want to gatekeep, but because in a field where mistakes can cost millions—where a misconfigured S3 bucket can expose millions of customer records, where a missed security patch can compromise an entire infrastructure—we have no shared understanding of what it means to be accountable.
What Medieval Guilds Understood
Medieval guilds weren’t perfect, but they understood something we’ve forgotten: a title means nothing without standards, and standards mean nothing without commitment.
When you became a master craftsman in the stonemasons’ guild, everyone knew what that meant. You had demonstrated specific competencies. You had made specific commitments. You carried a symbol that represented not just your skills, but your oath to the craft and to those who depended on your work.
The guild didn’t just certify your ability—it certified your responsibility.
Today, we have certifications that prove you can pass tests. We have job titles that prove someone hired you. But what do we have that proves you’ll take responsibility when things go wrong at 2 AM? When the security vulnerability you could have prevented makes the news? When the infrastructure you built can’t handle Black Friday traffic?
Five Pillars of DevSecOps Responsibility
Through my work with ISO 27001:2022, NIS-2 compliance, and building ISMS frameworks for organizations, I’ve watched the gap between title and responsibility widen. But I’ve also seen what happens when teams embrace genuine accountability.
Here’s what I believe should define us—not as people with a job title, but as professionals who carry responsibility:
1. System Responsibility (Systemverantwortung)
You own what you build. Not just during business hours. Not just until it passes code review. You own it in production, at scale, under load, when things break.
This means:
- Understanding the blast radius of your changes
- Knowing how to debug what you deploy
- Being available when systems you built need intervention
- Documenting not just for yourself, but for the 3 AM responder
2. Security by Default
Security isn’t a feature you add later. It’s not the security team’s job to fix what you built insecurely. It’s your job to build it secure from the ground up.
This means:
- Principle of least privilege in every design decision
- Encryption by default, not by afterthought
- Input validation before it becomes an injection vulnerability
- Assuming breach in your architecture choices
3. Risk Management
You can’t secure what you don’t understand. Every system has risks. Your job isn’t to eliminate all risk—it’s to understand, document, and consciously manage it.
This means:
- Threat modeling before implementation
- Communicating risks clearly to stakeholders
- Making informed tradeoffs, not wishful assumptions
- Knowing what could go wrong and having a plan
4. Operational Capability (Betriebsfähigkeit)
Code that works on your laptop isn’t production-ready. Systems must be operable—not just deployable. They must be debuggable, monitorable, recoverable.
This means:
- Meaningful logging and metrics from day one
- Runbooks for common failure modes
- Graceful degradation under unexpected conditions
- Testing failure scenarios, not just happy paths
5. Ethics
Technology is not neutral. The systems we build have consequences. We have a responsibility to consider those consequences and speak up when we see harm.
This means:
- Protecting user privacy, not just complying with regulations
- Questioning implementations that could be weaponized
- Speaking truth about security theater vs. actual security
- Admitting mistakes quickly and transparently
From Principles to Practice
These principles sound nice. But principles without practice are just philosophy.
Here’s what I’ve started doing:
I document my commitments. When I take ownership of a system, I write down what I’m committing to. Uptime targets. Response times. Security standards. Not for my manager—for myself and for whoever inherits this system after me.
I maintain a failure log. Every incident, every outage, every security finding. Not to beat myself up, but to learn. To see patterns. To measure whether I’m actually getting better at this craft.
I ask “who will be called at 2 AM?” before every architectural decision. Because if I’m not willing to be that person, I shouldn’t be making that decision.
I say no. When timelines don’t allow for security. When requirements ignore operational reality. When “just ship it” means shipping risk I can’t justify. Saying no is part of professional responsibility.
A Symbol of Commitment
The old guilds had symbols—marks that identified members and their commitment to standards. Today, we have LinkedIn badges and certification logos. But those prove you paid money and passed tests.
What if we had something that represented genuine commitment?
I’m not suggesting we need medieval ceremonies or secret handshakes. But I do wonder: what would it mean to identify ourselves not by our job title, but by our commitment to responsibility?
What would it mean to look at someone’s work and recognize the signature of a professional who:
- Owns their systems
- Builds security in from the start
- Manages risk consciously
- Operates reliably
- Acts ethically
You’d know it when you saw it. In the code. In the documentation. In the architecture diagrams. In how they respond when things break.
The Culture We Build Together
Culture isn’t created by manifestos or org charts. Culture is created by what we tolerate and what we celebrate.
Every time we accept “good enough” security because the deadline is tight, we build a culture that tolerates risk.
Every time we celebrate quick deployment over operational excellence, we build a culture that values shipping over sustainability.
Every time we let title trump accountability, we build a culture where responsibility is optional.
But every time we hold ourselves to higher standards—even when no one is watching—we build something better.
Your Turn
You don’t need anyone’s permission to be a professional. You don’t need a certification or a guild symbol or a formal code.
You need a commitment. To your craft. To the people who depend on your work. To yourself.
What standards do you hold yourself to?
What would you commit to, even if no one else did?
What kind of culture do you want to build?
Working on ISMS implementation, ISO 27001:2022 compliance, or building a security-conscious DevSecOps culture? Let’s talk about creating systems that work—and teams that take responsibility.