About six months ago, I wrote a post reviewing a book titled The Phoenix Project. In that post, I compared the events in the book to my experiences in my role as a production DBA. I also shared some ideas that I gained from the book to help improve the situation within and without my own team. Some big changes have occurred as a result – read on if you’d like to know what those changes are.

Before going any further, I’d like to stop to thank Thomas LaRock. It was his recommendation that led me to read The Phoenix Project. Prior to that, he also recommended Clifton’s Strengths Finder, which I also read. If not for his recommendations, I likely never would have read either of these books, and likely would still be struggling to understand why those developers just can’t do things right.

I was skeptical when I began the Clifton’s Strengths Finder book. I was never one to put much belief into these personality profile things – I know who I am, I don’t need a book to tell me. I changed my opinion when I was finished. The profile that the book provided was scarily accurate. So accurate, in fact, that I decided to give serious thought to some of the followup actions that the book recommended. I started to actually implement and pursue some of those actions, and soon noticed changes taking place in my attitude, and in my interactions with other teams in the company. Things like:

You are likely to anticipate potential issues more easily than others. Though your awareness of possible danger might be viewed as negativity by some, you must share your insights if you are going to avoid these pitfalls. To prevent misperception of your intent, point out not only the future obstacle, but also a way to prevent or overcome it.

and

Make sure that you are involved in the front end of new initiatives or enterprises. Your innovative yet procedural approach will be critical to the genesis of a new venture because it will keep its creators from developing deadly tunnel vision.

Acting on the Clifton’s Strengths Finders recommendations, and the ideas that I pulled from The Phoenix Project, I began an aggressive campaign to work better with our developers. I began sending out weekly SQL tips, including a pop quiz and a prize (paid for out of my own pocket). The developers loved these, and I was soon getting a lot of positive feedback. I made daily visits to the section of the building that houses the development teams, making myself visible, and getting some extra Fitbit steps. I went out of my way to drop in on meetings, hallway discussions, wherever I thought I might be useful.

Former “opponents” became allies. Some have become good friends. Developers are soliciting input from the DBA team again, and we’re reaching mutual agreements instead of arguing about the right way/wrong way to do things or whose fault it is.

The biggest change from all of this is that I’m changing roles within the company. Effective on October 13th, 2014, I will, for the first time in my 20+ years working with SQL Server, NOT be a production DBA. That is the day that I begin my new role as Principal Data Architect, the first one we’ve ever had here. I will be leaving the operations team and joining development, keeping one foot in operations, bridging the gap between the two teams. I will still, on occasion, get involved in production issues, but I will get to focus more on proactively preventing those issues, and growing my role as a mentor for the development team.

I’m truly excited about this change, and so very glad that I stuck with it and didn’t walk away from the company to start over somewhere else. It’s all about attitude, and attitudes can change. Life is too short to be miserable, take control and find what makes you happy. Change is good, after every sunset comes a brand new day.