Every role feels like the hardest one when you are in it. Developers think they have the toughest job because nobody lets them ship features. Ops people think they have the hardest job because everyone keeps breaking stability. Security people feel the same way. But the nuanced view is that each group applies a pressure that makes the whole system work. Without the security pressure, you would not invest in security. Without feature pressure, you would not make money. It is a balancing act, and no single perspective should dominate.
The history of devops tracks closely with this realization. In 2009, nobody was actually stopping developers from talking to operations – we just structured ourselves into silos that limited collaboration. When agile developers started getting more productive and working together happily, I was jealous from the ops side. That energy led to the first DevOpsDays in Ghent. The practices that became devops were already happening; what the label did was give people a way to find each other and share stories.
Security fits into this same pattern but with one key difference: it is harder to build the business case. With operations, you have direct feedback – the site is fast or it is down. With security, if nothing goes wrong, you do not know whether that is because of your security investments or because nobody tried to attack you. That intangibility makes it a harder sell, even as breaches make the need more obvious.
On developer relations, the role fills the cracks that companies do not handle well. It is about listening, connecting people to the right internal teams, and being helpful without commercial strings attached. In emerging fields like devsecops, devrel is especially valuable because the chaos creates opportunities to connect people who are all trying to figure out the same unsolved problems.
Watch on YouTube – available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.