Managing A DevOps Team

Well first off I figured I would make that the title since that’s probably what people think I do these days, I manage a DevOps team. Well first off all if you have been following the DevOps movement there is no such thing as a DevOps team, so while it might help my resume to put “Manager of DevOps” it simply isn’t so, and I try not to lie about my work history. So why would I make a blog about “Managing A DevOps Team” when obviously I have no experience in doing so? Well I will tell you why…..

Today I was waiting around and doing some harmless googling and came across a great article called Devops Consulting: Why I Don’t I suggest if you haven’t read it yet you take out some time and do it and it gave me some great ideas for my next blog post.

Why We Aren’t The DevOps Team

I manage a team that specializes in building and maintaining a core set of infrastructure and automation tools that allow the company to bring product to market quickly and effectively. We work closely with our customers, who in our case happen to be development teams. We version control our releases of infrastructure as if it where code (well since they are) and leverage popular version control tools such as git and stash. We deploy often, we role code forward using puppet’s puppetfile and r10k. And finally, we write unit tests for our infrastructure code base.

From the sounds of it, we are what the internet is coming to decide is the DevOps team. I even get emails from our recruiters who tell me they have a new DevOps engineer for me to interview. It’s really to the point where I’m starting to hate the word. I actually don’t call my team a DevOps team but from time to time I do catch other teams and even managers calling my team “The DevOps Team”.

I am still not sure where the idea that silos where a good idea. The guys who mentored me taught me from the very beginning to “automate all things”, to “check my code into version control”, that “a lazy system admin is a good system admin”, that “development and database administrators are our customers”, etc… At nearly every company I have worked for I have had great relationships with the development teams I support. I’ve whipped up kool solutions for them, they have worked with me to troubleshoot applications that they wrote, we have architected new solutions together, and much more.

Managing High Performance Teams

Now that I am a manager of a devops team, I want to share some of my experience. Over the years I have had amazing bosses and horrible ones. Recently I was sent by my company to a management training seminar which I actually found quite a bit of value in. One of the questions I was asked was “What was it about your best manager that made you like him or her so much” and “What was it about your worst manager that you disliked so much”. This was actually a very interesting question and one that I ask myself every day when managing my own team of high performance engineers.

Worst Manager

When I took this training class it was certainly easy for me to identify the worse manager I have ever had, and if there is one trait that I could identify as the single most problematic it’s that inability to give up being a technical leader and turn the reigns over to your team. He is the manager who takes down production in the middle of the day, “fixing a performance issue”. He is the kind of boss that “defends a technical decision he made 5 years ago because he can’t let it go”. He is the one who “still has to stand in the spot light because he was the company’s savior” which we all know is the reason he got promoted in the first place, right?

I’m actually not picking on any one in particular, this just happens to be the bad traits of a few different bosses I’ve worked for in the past. These however are the things I think about day in and day out with my team. Obviously I was promoted because of my technical skills and abilities, the company felt it was a good idea to give me a technical team, because hey if “one Brian Carpio is this good, 5 will be better’. The obvious mistake many companies make is not realizing most technical people make horrible bosses.

Best Manager

So the next question is who was the best boss I’ve ever worked for in my career. It would happen to be a guy named Wayne (I doubt he ever remembers me let alone reads my blog but ..). He was team lead turned manager. I remember when he took over the management position and we all teased him we were taking root away from him. It was a big joke in the team but it was  the honest truth. We changed the root password and didn’t give it to him. I was pretty young at the time, I was about 22 years old working as a Solaris admin with guys 2x my age with 10x the experience. I just assumed that was the natural order of things, but boy was I wrong.

So taking root away from him wasn’t what made him a great leader, no. It was his ability to make sure everyone in the team had their voice heard. He made sure that everyone in the team had their area of expertise and pushed us all to be better. For instance being the most junior on the team he worked with me on gaining respect with the team, and finding my niche. Through his leadership not only did I run the entire DR/BCP program for our team but also took over security and designed our DMZ. He was the kind of guy who allowed the team to hash things out, then take us out for beers afterward. He was the kind of guy we all felt comfortable speaking with, and he pushed us to maintain good relationships with our customers.

So I think most leaders try and do nearly everything I posted above correctly, but the one thing I find lacking with most managers is that they don’t help the team build good relationships with customers. I feel like the happyness and sucess of our customers make the workplace an enjoyable one. I’ve been in an operational role for nearly my entire career so that’s all I can speak to. I’ve seen development and operations teams hate each other, which we all know is the thing that DevOps aims to fix. Yet, I’ve also seen development and operations organizations have a healthy relationship, one where there is mutual respect, and collaboration. Honestly up until a few years ago I didn’t realize there was this problem where development and operations didn’t get along (I spent a few years consulting and apparently living under a rock). I didn’t realize every operations team’s motto was “automate everything”. It wasn’t until I had a co-worker tell me about the DevOps movement that I heard the IT world had gone astray. He said “it’s where dev and ops work together, and you automate everything”, and I thought, “you mean to tell me that isn’t how all companies work”?