Skip to main content

The Key Ingredient Everyone is Missing with DevOps -Leadership Part 2

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 over the fence.  I could not believe it.  After that, I could never mentally recover and he came back and won the second match.  I was frustrated and could not let it go. I got destroyed in the last match.

Instead of playing at the district tournament, I sat around with the team.  I had time to reflect and watched the guy I played get destroyed in his match.  Wow, would I have lost too?  Then, I saw the guy that won the tournament.  He was way, way better than us.  I went from, “I am going to win and play at district” to, “I really suck at this sport”.  This got me motivated to play a lot more tennis.  I practiced every chance I got in the summer.  The next year I actually got second in district and got to play at the regional tournament.  I am thinking I am really good again.  Wrong.  I got destroyed at regionals in the second round by a guy who got destroyed his next round.  Again, I was amazed at how much better some people where.  Overtime I got better, so did the people I watched play.

Back to practicing and during the summer. I worked at a country club so I could attend a tennis camp for free.  The first week I was there, the head coach made me play a match against a girl.  I was thinking, “Don't you know I went to regionals last year and you want me to play a girl?”  Surprisingly, she beat me 6-0, 6-0.  I did not even win a game.  I found out she was the state champ the year before and was practicing for college.  You can image how this felt.  It felt like I had taken two steps forward but 4 steps back.

I kept having these moments through out my tennis life.  I went to the state tennis tournament the next year and lost in the semifinals. I lost again in the state tournament my senior year.  After that, I played college tennis and barely made the team.  Again, I was motivated to practice more to stay on the team.  I basically spent 10 years of my life playing and learning tennis.  Somewhere in there I graduated high school and college and obtained a Masters Degree.

What I discovered over and over, was that most of the people that were really good, and beating me, had been playing tennis since they were 8 years old. (Unicorns) I started when I was 15. (Donkey)

I see this a lot in IT today. People always look around and see other companies, and people, are better off than they are. (Unicorns)  They just say, “We can't do that at my company” or, “We will never be able to do that DevOps stuff.” (Donkeys) The fact is; every day you can get a little closer to doing DevOps or improving IT. Everyday you must make opportunities to improve.   You can't wait on others to improve. You must take your career into your own hands. You have to be determined to improve yourself, your team, or your company everyday.  Check out this video on taking control of your own career: https://www.youtube.com/watch?v=lgxEmiMJVq4

I feel so strongly about this, if you are in your 20s or 30s and have not learned anything new in the last 2 months from your team or company, you should leave.  You should do this, even if it means taking a pay cut.  I did this after my first job.  I realized I was basically dying a little everyday because I was not learning anything new. I was that guy who knew everything and no one to learn from.  Changing jobs turned out to be one of the best decisions I ever made.  I ended up on a team of of incredibly smart people who taught me OOAD, Automation, CI, Infra, Architecture, Agile, TDD and how to work as a team.  We did DevOps 15 years ago and it was natural.  I have no idea where I would be today if I had not made the decision to go and learn more.

As I improved as a tennis player, I noticed that others started looking at me as a good tennis player.  I knew I was not great, but I had become better at the physical and mental aspects of the game.   This is when I started to give back and help others, just like I had been helped.  I taught college tennis camps, gave lessons, and worked at country clubs.  I was amazed how much it helped me get better by teaching others.  I am amazed everyday how many people in IT have not had the opportunity to learn some things that I have been blessed to experience over the years.  I find that most people want to learn, but have never been on a team, or with a company, where they can learn.  If you want to do "DevOps", then take the time to teach others around you.  You can do presentations at local user groups.   You could record training sessions and post them on the YouTube.  Anything that helps raise the knowledge level of people around you will ultimately result in IT delivery improvement.  

Another related factor to continual improvement is tool maturity.  I get so tired of hearing the Chef vs Puppet vs Ansible or Jenkins vs Team City, or .Net Vs Java or whatever.  I feel many people today never truly mature a tool, especially in enterprises.  Tools are just like people and need opportunities to improve.  I don't know if this is a generational thing or not, but every time something gets hard or different, we give up and get another tool.  You can't truly get value out of tools until you mature them across many teams or users.  You need to have as few tools as possible and continuously improve them.  See what others are doing with the tools, and mature the ones you have.

With all this said, realize that sports, IT, and life are all about continuously improving.  Don't just give up and move to something else. Keep learning and maturing as a person, and help others do the same.  Like in tennis, I saw many times that I could improve my craft.  Stay up to date with IT trends and software development changes.  It is not easy, but improving year after year in Tennis was not easy either.  No one said being a leader is easy.




Comments

Popular posts from this blog

2020 State of DevSecOps by Accurics

 This is an excellent report for all IT Pros and Engineers.   Highlights: Storage is most impacted solution Open security groups or network configuration Secrets are not so secret Unused resources are not secure. Take a look at these.  Look again.  These are not highly skilled problems.  They just need guidelines and proactive management.  The article uses policy as code as a solution for many of the problems.  I will drill into each of these more in the future.  I wanted to get the awareness out first and then, come back to solutions.  

Manage IT by Johanna Rothman

I just completed this book. I think it is a really good book which covers a whole lot of software development. This book could possibly be the best book for first time project managers. I believe many of the PMs understand PMM but do not understand software development. This book gives a view of each project role. The only one that it does not cover is Business Analyst or requirements documentation. It does cover QC, development and of course PMs. It gives a PM a view into development processes like TDD, CI and estimation. Many PMs that are new to SD can read this book and get a great start to manager an SD project. If you are a PM or know some, read this book. http://www.jrothman.com/

Matrix Organizations are bad for Software Dev

Development teams need to be teams first and company people second. What happens when your team wants to start using user stories and index cards, but your analyst team manager thinks Use Cases are the best way to document requirements? How about when your QA process is not mature and you keep releasing with defects but the QA manager does not do anything about it? How about your project manager never buys into the team and only cares about being on time and on budget because their review is based on it. Maybe the tech lead wants requirements that never change and never lets the client change their mind. The technical manager taught your tech lead and agrees with everything the tech lead says. Agile or what I like to call "Successful Teams" are teams. They do what it takes to do what the customer wants, deliver features. I am not saying only agile teams are successful but successful teams are agile. If your organization is matrix, get your leadership buy in to override...