It has been many months since my last significant post; I figured it was time to dust this blog off again and begin posting again. In the time since I’ve last posted I now have a Master’s of Digital Sciences from Kent State University. I’m very thankful that I’ve completed this milestone in my career. The courses that I was enrolled in gave me a deep understanding and insight into how organizations really need to think in a digital environment.
Fast-forward to what I’ve seen accomplished in my current role. Our internal implementation of “DevOps-as-a-Service” has been deemed a success. Why internally roll out DevOps-as-a-Service? It allowed us to deal with things sensibly and in a fashion that allowed us to experiment while still being able to deliver business value. We partnered with one highly visible project that we knew we could accelerate and it was fairly low risk for us. You could say we stacked the deck.
The Team
The biggest asset we had going for us was the team structure of the founding members of the team that ended up being known as the “DevOps team”. The goal of this is not to be a prescriptive “playbook” in how someone else that may be looking at doing something similar but to give you an idea of what worked for us.
The Leader
It all started with the “Leader” that helped form and tell the story as to why we needed to change. They needed to be able to challenge the status quo and be able to articulate to the executives the vision in terms that they can understand and get excited about. Another key feature was being able to provide “air cover”. This let the rest of the team do their thing and report back when they needed support, had a success story, or just needed to bounce ideas off of.
The Tinkerer
The “Tinkerer” had a very strong development background and was constantly looking at new ways and new technologies for developers to quickly get their work out the door. The “Tinkerer” had the knowledge to sniff out people, processes, and technologies that were impeding this delivery; while always coming to the table with a proposal, no matter how off the wall people thought it was.
The Integrator
Google’s whole concept of a Site Reliability Engineer (SRE) is what would happen if a software engineer (developer) were to do operations work. We had an ex-infrastructure engineer that knew enough about all kinds of infrastructure and could articulate to our development team the thoughts of our group. Essentially the “Integrator” was our bizarro SRE and was able to deep dive into each aspect of the infrastructure and bring the silos together for the developers.
The Implementor
The “Implementor” was able to take many of the thoughts and ideas of the group and craft solutions to the problems or ideas that were presented. Need something automated, installed, or the like and the “Implementor” was seemingly able to figure out how to get it working.
Conclusion
Those were our founding members of our “DevOps-as-a-Service” team and it’s not to say that everyone wasn’t able to do other things, but at it’s core, that’s how we were able to be successful in our first endeavor. We’ve struggled with how we scale this team, while trying to keep the core traits and tenants each archetype in place. Time will tell whether we’ll continue to have success or how we will have to evolve as we continue to try to add value.