I keep seeing the same pattern. A company posts a job listing for a “DevOps engineer,” hires someone smart, hands them a Jira board, and waits for magic. Six months later the deploy pipeline is marginally better but the teams still don’t trust each other. The hire burns out. Everyone blames the tools.
DevOps isn’t a role. It isn’t Jenkins. It isn’t even a set of practices you can copy from a blog post. It’s a cultural shift where the people who build software and the people who run it share the same goals, the same pain, and the same wins.
I learned this the hard way at Dropbyke.
What Happened at Dropbyke
When I joined as CTO, we had a classic split. Three backend engineers shipping features as fast as possible. One ops person – call him Max – who kept the lights on. The engineers would push code on Friday afternoon, Max would get paged at 2 a.m. Saturday, and Monday morning would start with a blame session disguised as a standup.
Max was good at his job. The engineers were good at theirs. The system between them was broken.
The fix wasn’t a tool. It was a conversation. I put the entire team in a room and said: starting next week, the person who ships the code carries the pager for it. Not forever – just for the first 48 hours after deploy. If your code wakes someone up, that someone is you.
The reaction was roughly what you would expect. The engineers hated it. Max loved it. But within two weeks, something shifted. Deploys got smaller. Engineers started writing health checks without being asked. Someone added a runbook for the payment service, unprompted. The Friday afternoon deploys stopped entirely.
Nobody told them to do any of that. The incentive structure changed, and the behavior followed.
Quick take
Stop hiring “DevOps engineers” and start fixing the incentives that make your dev and ops teams fight each other. Culture first, tools second.
Start With Shared Pain, Not Shared Tools
That experience taught me something I keep coming back to: if you want DevOps culture, start by making everyone feel the consequences of their decisions.
Developers who never see production alerts write code that’s hard to operate. Ops people who never sit in planning meetings treat every deploy as a threat. The gap isn’t technical. It’s empathy.
The cheapest thing you can do is cross-pollinate. Have a developer shadow on-call for a week. Have the ops person sit in sprint planning. Run a postmortem together after the next incident and focus on the system, not the person. I’ve never seen a team do this and not come out with a better understanding of each other.
Pick a Pilot Team and Let Them Own It
Don’t try to transform the whole company at once. Pick one team. Give them ownership of their deploy pipeline and their on-call. Let them figure out what works. Measure what happens.
At Dropbyke, that pilot was the team running the bike availability service. Small blast radius, clear metrics, leadership willing to experiment. They went from deploying once a week to deploying daily within a month. Not because I told them to, but because shorter cycles meant smaller changes meant fewer pages.
The rest of the engineering org watched this happen. Nobody had to sell them on DevOps after that. They just asked when they could start.
The Technical Stuff Matters, But It Isn’t First
Once the culture is moving, you need the technical foundations to support it. Infrastructure as code so environments are reproducible. A CI pipeline so every commit gets tested. Monitoring that answers “is this thing working” without requiring tribal knowledge.
In 2016, that means Ansible or Chef for config management, Jenkins or CircleCI for builds, and something like the ELK stack or Graphite for observability. The specific tools matter less than the principle: everything should be automated, version-controlled, and visible to the whole team.
But here is the thing – I’ve seen teams with perfect pipelines and terrible culture. The pipeline doesn’t fix trust. It just makes deploys faster. If the team still throws code over the wall and blames each other when it breaks, a faster pipeline just accelerates the dysfunction.
Traps I’ve Walked Into
The hero trap. At Dropbyke, Max was the hero. He could fix anything at 3 a.m. That felt like a strength until he took a week off and nobody knew how to restart the payment gateway. Heroes are a single point of failure wearing a cape. Spread the knowledge.
Tool obsession. We spent two weeks evaluating orchestration platforms when the real problem was that nobody knew what was running in production. A shared spreadsheet would have been more useful than Kubernetes at that point. Solve the problem you actually have.
Burnout disguised as ownership. If you give developers pager duty without reducing their feature load, you aren’t building DevOps culture. You’re just distributing the suffering more evenly. Shared responsibility means shared capacity planning too.
It’s a Slow Game
DevOps culture doesn’t happen in a quarter. At Dropbyke, it took about six months before the dev-vs-ops tension actually went away. The team went from monthly releases with weekend war rooms to daily deploys that nobody thought twice about. But it was gradual, messy, and full of setbacks.
The wins compound though. Smaller deploys mean fewer incidents. Fewer incidents mean less firefighting. Less firefighting means more time for the work that actually matters. Once that flywheel starts turning, it’s hard to stop.
If you’re starting from zero, that’s fine. Most teams are. Start with the incentives, not the tools. Make people feel what production actually looks like. Pick a small team and let them prove the model. The culture will follow the work.