T-SQL Tuesday #32 - A Day In The Life

T-SQL Tuesday has been a little off my radar for the last few months (as has all blogging activity!), so I was delighted when Twitter reminded me that it was that time of the month. Even better, the topic chosen by Erin Stellato (Blog | Twitter) was a great one that I felt I could really engage with.

So here we go. For the record, my job title is Database Administrator.

The task as laid out in the invitation suggested to talk through your day on the 11th or 12th July which just so happened to be the day I resigned from my current role. Writing down a handover list was an interesting task in itself as it gave me the opportunity to put down in words what the key parts of my job were and what skills gap would be left. I have to say, I was surprised (and pleased) that the number of tasks on the list that required significant handover to another collegue were minimal as I have been very diligent in ensuring that I was not a Single Point of Failure in my organisation. As such, I have written plenty of documentation and made extensive use of Source Control and Task Tracking systems to ensure that even if people do not know what I've done, there is a paper trail to explain it.

What was apparent was the varying skills I employ in my day to day, many of which are not even related directly to SQL Server. Much of my day is spent in project meetings, planning or analysing roadmaps and although the applications typically have a database backend, its not the focus of my attention. I am fortunate to be able to dedicate some time each day to reading blogs and technical articles to help stay up to date although I also spend my fair share of time in firefighting mode. The traditional DBA element probably takes up less than 1 day a month partly due to the small size of the estate but also because I've been effective (backslap for myself here!) in automating many of the tasks.

Is my job really a Database Administrator role? I don't think so and in truth it wasn't from the outset but this hasn't been a bad thing. I enjoy the variety of being involved in the different aspects of SQL Server and feel it makes me a much more effective professional and I imagine that this is the case for many other fellow SQL Server pros. However, I've encouraged my company to not advertise the role under this job description as I believe it may attract candidates with unrealistic expectations.

As for me, I'm not sure what my next role has in store but I hope it affords me the time to participate in future T-SQL Tuesdays!!

Why I Love Conflict!!

Ok, so thats a bit strong. I don't like conflict for conflicts sake. But i do love the benefits that healthy conflict can bring to successful teams.



Disagreement

Disagreeing isn't easy. But it is important. And remember, just because you're the only one disagreeing, it doesn't mean you are wrong. The fact is that there are always at least 2 sides to a story and from a problem solving perspective, there are always options- you just may not like them! People who are not afraid to challenge can be misconstrued as being difficult or contrary or awkward. But, often they are just playing Devils Advocate and are just presenting all the options or the potential flip side to the coin and I think this is a valuable trait.

It's important that people demonstrate the courage to have an opinion even if its one thats not popular or shared. It's all part of the feedback process which promotes discussion, ideas and solutions and often leads to successful teams. This can be a culture shock for some but in the long run, the team benefits and you generally get a better result.

If everyone buys in the cause and people trust that they are heading in the same direction, a bit of conflict can be very healthy. People like to use the phrase, singing from the same song sheet and in general, I agree with the sentiment - lets all work together for a common goal. But this should NOT be lead to blind acquiescence. There is a danger that having an opinion that is different to the majority or the key influencers marks you out as someone who is not a team player, a tag which nobody wants. As a result, this can lead to people just going along with the consensus so as not to "rock the boat", avoiding conflict which is not in the long term interests of the team.

People can be tagged as obstructive or blockers rather than "can do". Beware. While I acknowledge that these people do exist, you need to check their motives. If they are doing so for personal gain then yes they are negative and are trying to "slow the bus down" for the wrong reasons. It may just be that they are trying to offer balance. Trying to apply the handbrake to stop the bus crashing off the cliff. But remember, if you mark yourself out as someone who is willing to challenge, you must be prepared to take criticism yourself as you'll be wrong often! And above all, never make it personal.

Balance

Sticking with the song sheet analogy - a good song doesn't mean everyone is singing the same notes or perhaps even using their voices at all! You will have people playing different instruments and then within a set of singers you may have some who sing high and some low. Its harmonising. There has to be a balanced set of voices. Too much of the same and it doesn't work.

You need some brakemen and some accelerators so that you have a controlled efficient vehicle which can move forward at pace without losing control. Try a football analogy. Too many brakers and you have Arsenal - a good team without being great, just falling short perhaps as a result of not inveseting. Too many accelerators and you have Leeds, living the dream and crashing and burning.

And do not let people think that doing the boring/admin/BAU work is not worthy. All the eye-catching football, the cool development stuff, the good ideas - they all need to be built on solid foundations. Again, think football and the water carrier. You need a Deschamps to do the dirty work to allow Zidane to flourish. And at a personal level, even the worlds best footballers are able to do the basics. You don't think that Ronaldinho can only do fancy flicks and tricks? No, he's built his skills on a foundation of solid basics. The same applies to IT.

Adaptability

So back to the world of development. I like to think I am adaptable. I recognise the need for both roles - driver and brakeman and depending on the position I am in, I will adopt either role. In a highly autocractic environment with lots of red tape, it may be necessary to be a bit more cavalier to try and break some of the resistance to change. In a company where there is minimal control and change is virtually omnipresent, it is necessary to try and apply the brake and introduce process for the sake of stability. After all, while I love change- i also love stability and scalability.

From a personal perspective, an area where I am trying to improve is getting my point across effectively- getting buy in - as it can be difficult for people to understand somone with extreme opinions, be it braker or driver. It is often only after a period of time (and some clashes!) that people begin to understand your motives and give you the respect which lets your message in.

I dare say there are a mixture of people and styles in your work. Spot the gap, spot the problems and fill that niche. You can bring balance and a smoother ride for all.