Leading DevOps

After thinking through our interviewing process, previous company process and interviews I have gone on in the last few years, I see interviewing as a complete failure at most companies. Obviously the interview process depends on the role but there is really no way you can spend 30 minutes on the phone, an hour team interview and a 30 minute executive interview with someone and decide if they are a good or bad candidate.   Honestly the more senior the role, the more time you should spend with them. I want to give a few tips to interviewees and interviewers. Interviewees - You are interviewing them Dress up no matter the role.  Don't ware jeans unless the company has specifically told you to do that.  If it is a manager or higher role, wear a suit.   Make sure you interview the people you talk to.  Find out if you want to work with them and their role compared to yours.   Understand the day to day responsibilities and long term expectations of t...

Empathy This is the key to success.  You have to try to understand everyone around you.  To do this, you have to listen and have empathy for their POV.  Without this, you can't gain their trust and respect.

Faith It is simple.  You have to have Faith that you can improve your self, team or company every day.

Continuous Improvement The first key to DevOps leadership is never stop learning and improving.  We all know about Kaizen and if you don't, Google it.  I see our journey in IT similar to my tennis journey. A long story, that fits really well for this scenario in my life, was in 9th grade when I decided to play tennis because my friends were playing.  I had only ever played Basketball.  I practiced and played some tennis matches during the season, but a pivotal moment occurred at the end of the season when another guy and I had to play 3 matches.   The winner of 2 of the matches would be in the last spot at the district tournament.  I won the first match.  Awesome!  I let it get to my head some, yet I was winning the second match.  I had a match point and an easy overhead to win it.  I got in position like normal, and swung hard as I could because I wanted to slam the ball over the fence. Instead, I just hit the ball straight ove...

Many of you saw this blog post and said, "Heck yea"  If my leadership understood DevOps, we could start doing trunk based development, with feature flags, micro services, GitHub, Jenkins, with Chef, in Azure and deploy during our IPO.  If "They" just understood,  my world would be better.  I agree but I don't agree with "They". I started to call this blog post "The Forth Way" but I don't think it fits accurately with Gene Kim's Three Ways model.  Instead, my goal is to show we are missing a key element of DevOps and DevOps does not work without it. Main point : "You are a leader or you are not in your organization!" In upcoming post, I will explain the three key leadership traits required to grow a DevOps culture in your company, organization or team.

It finally dawned on me why people struggle with defining DevOps.  If someone is truly trying to define DevOps, they will start to realize it is different in different context.  I have tried many times and each time I slant my response to the situation or what is important to me at the time.  You have seen DevSecOps, DevTestOps, DevOpsSomething and so on.  This is because people are trying to use the fundamental point of DevOps to describe more examples of it.  This made me realize that if you view DevOps as a culture, you will start using it to define more than just "dev" and "ops" because it is a metaphor. DevOps is really a metaphor for two opposing entities that clash when required to work together because they have different goals and motivators.  Dev wants to change and Ops wants stability.  Apply the same concept to other challenges like Dev/Test, ITIL/Agile, Offense/Defense, Politics/Religion, Blacks/Whites, Husband/Wife, InSource/OutSource a...

http://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/ I found this blog to be fascinating and a very good representations of different DevOps model.  First off, a full stacked team that builds, releases and operates its own service is the best hands down.  The problem is very few enterprises are doing this.  So the question is what do you do instead.  My opinion is DevOps as a service is the next best model for enterprises. Here is why: Teams in an enterprise either don't know how or aren't allowed time to do automation.  This means a DevOps as a service team can work with the teams to do all the large up front building and then, teach the teams to own it from there. You have to let the teams own it because pipelines are continuously changing and maturing.  The IaC solutions should be changing and adapting to the needs of dev and ops.  The DevOps team can't stay on one team for too long or you will miss more...