If you’re in DevOps, The DevOps Handbook is a must-read. Honestly, if you work anywhere near software development—whether you’re a programmer, agile delivery manager, product manager, or just someone who once deployed a script and called it “automation”—this book has something for you.
The handbook lays out some brilliant ideas, and while I don’t have it in front of me (because I’m currently typing this on a train bound for Edinburgh), a few key concepts jump to mind:
- T-shaped engineers – People who have deep expertise in one area but broad knowledge across others.
- Reducing dependencies – Enabling teams to make changes without waiting on external approvals or other blockers.
- The “two-pizza” team rule – Teams should be small enough to be fed with two pizzas (though that depends on the size of the pizza, really).
- The NationWide case study – A great real-world example of DevOps transformation.
- The dangers of context switching – Multitasking isn’t a superpower; it’s a productivity killer.
Reading the book is one thing, but implementing its lessons is another. Because let’s be honest—every organization is different, and every person within it brings their own experiences, challenges, and resistance to change.
If you walk into the office one day, dramatically hold up The DevOps Handbook like Moses descending Mount Horeb, and declare that you now have the “DevOps Ten Commandments” (there are more than ten, by the way), the likely response will be: WTF?
Unless you’re the CTO with the power to force change through the organization (lucky you), you’re probably wondering: How can I actually implement DevOps principles if I’m not the one in charge?
Leading Without Authority
This reminds me of something Simon Sinek often talks about. He’s done a lot of great work on leadership and optimism, and one of the ideas he shares is how to lead when you’re not in a leadership position. His advice? Just start acting like a leader.
Not a manager—a leader. Don’t tell people what to do. Instead, demonstrate value through your actions. Help others. Solve problems. Share knowledge. When you do that, people naturally start seeing you as the go-to person, and before you know it, you’re leading change without ever having been “officially” put in charge.
One interesting psychological concept behind this is mirroring—people tend to mirror the behaviors of those around them. So if you start working in a DevOps way—collaborating, automating, breaking down silos—there’s a high probability that others will start doing the same.
But here’s the kicker: This isn’t going to happen overnight.
Persistence Pays Off
A few years ago, I set up an internal DevOps community at work. I shared the chat group across various teams, hoping to foster collaboration. The very first response?
“What’s the point of this DevOps community? Sounds like a waste of time…”
Not exactly the enthusiastic launch I was hoping for. But instead of arguing, I thanked them for their input and moved on. I kept posting, kept sharing, kept engaging.
Six months later, the community had grown to over 500 people actively helping each other solve problems. Ironically, the same person who initially dismissed the idea became one of the most active contributors—turns out they just needed to see the value first-hand.
Practical Takeaways
- If you’re a CTO – Great! Read the book and drive change across the organization. (Kidding. Sort of.)
- If you’re not the CTO – Pick a couple of key DevOps concepts that you can implement in your own workflow. Show the impact, and others will start paying attention.
- Keep improving – Don’t just implement and forget. Observe what works, tweak what doesn’t, and continuously improve.
The goal isn’t to follow The DevOps Handbook word for word but to expand your knowledge of how things can be done—then tailor those ideas to your organization.
And with that, I still have about 40 minutes left on this train to Edinburgh. Time for a tea.
