This was the most personal talk I’ve ever given. After five years of running a startup, I wanted to share what I actually learned – not the DevOps theory I’d been preaching, but the messy reality of running a business where every department faces the same collaboration challenges we talk about in engineering.
It started with a performance problem. Our platform was slow, and the root cause wasn’t in our code – it was in a supplier’s infrastructure. That experience taught me something fundamental about the “serverless” promise: there’s no such thing as serverless, only service-full. You don’t eliminate operations; you distribute it across suppliers. And now you need DevOps practices that cross organizational boundaries – shared monitoring, joint incident response, collaborative capacity planning with people who don’t work for you.
The surprises came from departments I’d never expected. Marketing became my strongest ally because they understood storytelling and positioning – skills engineers typically lack. HR taught me the hardest lesson: hire for potential and cultural fit, not just technical skills. When I hired purely on competence, I got technically brilliant people who couldn’t collaborate. Sales showed me that prioritization problems aren’t unique to engineering – sales teams face exactly the same tension between serving existing customers and chasing new ones. Legal and GDPR became unexpected enablers rather than blockers once I treated compliance as a feature rather than an obstacle.
The company eventually closed. I call the phase before closure “hopium” – that persistent optimism that the next deal or the next feature would turn everything around. After that, I joined Snyk to work on devsecops, which brought me back to the pattern I kept seeing: security teams face the exact same silo problem that operations teams faced a decade earlier.
The thread connecting all of it was trust. I found a framework from organizational psychology that breaks trust into four components: competence (can you do the job?), reliability (do you deliver consistently?), sincerity (are you honest about intentions?), and care (do you have the other person’s interests at heart?). Most DevOps practices – CI/CD, monitoring, postmortems – only address competence and reliability. When teams still don’t trust each other despite having great tooling, it’s usually sincerity or care that’s broken. Practices can mask trust deficits, but they can’t replace trust itself.
Watch on YouTube — available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.