I’m not an engineer by trade, I don’t have a degree in computer science and I taught myself what a technology stack is. I learned about programming not through primary school, but through my obsessive hobby of model rocketry at the age of 12 and again my freshman year of college where I majored in Finance and Accounting.
That said, my background is important because I love solving business problems with technology. I’ve worked with thousands of companies to improve operations through technology, built my own business, developed backend software for my own business and I’ve consulted on dozens of software projects. I’ve had to evolve, pivot and learn new things to stay relevant as the pendulum of technology swings back and forth between the need for specialists once new architectures, methodologies, disciplines, etc. arise and the need for generalists once they mature. The one thing I’ve noticed that stays consistent is that tech is always in a state of entropy (organized chaos) so I hope the insight I learned from DevOps Days help you bring more predictability and value to your organization.
DevOps isn’t a Luxury, it’s a Requirement
Gene Kim who is one of the rockstars of DevOps and technology, gave a fabulous speech on his research and shocked the audience when he noted that out of 16 million software developers, only .5% (not 5%) are practicing DevOps! That’s a shocking statistic when you compare operating costs and margins of high performing IT departments, and even more shocking because the other 99.5% could unlock TRILLIONS of dollars in CAPEX by adopting DevOps and it’s practices. To reiterate the introduction, I’m not an engineer by trade but I do know finance so it’s pretty clear to me that the world needs DevOps not to improve, but to survive.
Selling DevOps – It’s Personal and It’s Business
One of my favorite speeches was Driving Technical Change and how to motivate people with technology. Long story short, we covered several ways to align your arguments to the self-interests of others so they clearly understand how technology will benefit them regardless of their background. For example, the presenter used an example from the past where he tried to convince the CFO to allocate resources to make certain technology upgrades which he knew had to be light on details and heavy on substance. The CFO is motivated to improve stockholder value so making the argument to adopt a modern architecture had to align with his motivations such as making it easier to recruit top talent, improve efficiency and drive down costs. He was obviously successful in persuading the CFO because he put the self-interest of the audience above his own and to make his argument irresistible which are tactics everyone should adopt regardless of occupation.
Automation – Build for Speed Not for Comfort
Everyone in DevOps has heard about continuous integration but according to Suzie Prince, not every DevOps professional properly implements this practice. We learned that it’s not enough to have a CI tool if you don’t have a uniformed process to check-in your code at least daily. The logic behind this is straight forward – merging is tedious but it mitigates conflicts that result in broken builds. It’s easy to say that you practice continuous integration if all you have is a CI tool but unless you properly follow CI best practices you’ll be wasting time and you won’t reap the full benefits of DevOps!
Communication- Perfect the Fundamentals
Why is it so hard to talk to people? I’m referring to collaboration and communication with development teams… I met a VP of a decently sized manufacturing who wasn’t getting the results he expected after reorganizing his functional teams of development, database, quality assurance and operations so that each area of expertise was no longer physically segregated around the office. When they adopted DevOps, they created cross-functional teams with members from each group, but also retained managers that oversaw functional. Unfortunately, this didn’t work because each cross-functional team remained implicitly silo’d even though they were no longer physically separated. The fatal flaw was a lack of strategy both for short term implementation of DevOps and long term sustainability of new practices because collaboration and communication was never enforced!
If I had to pick my favorite speech it would have to be “How to elevate your contributions as an Ops Engineer”. It was easy to fall in love with the comedic tone of the presenter but the subject matter on thinking about the big picture of organizational success perfectly aligns with my approach to business and consequently captured my undivided attention. For example, the speaker told a story about the time he discovered his sales reps were spending 12 hours onboarding customers because of manual and laborious which he knew could be automated with very little engineering effort. The moral of the story is that he didn’t just think about his role, he wanted to make a tangible and positive impact on the company and by reducing the onboarding effort from 12 hours to 15 minutes he advanced his career and improved the org!
I thoroughly enjoyed every interaction I had and feel blessed to live in the city of Seattle where our DevOps community is truly world class. While I learned a lot, the conference reinforced my belief that tailoring the end to end value chain to your people, process and technology is paramount to successfully implementing and sustaining DevOps. Feel free to reach out to me via firstname.lastname@example.org if you’d like to know how my team helps in driving the DevOps transformational journey!