The 10 commandments of being a good DBA manager
Posted by John Hallas on October 10, 2013
With a subtitle of ‘The 10 commandments of being a good DBA within a DBA team”
I have been considering for a while what might make a good DBA manager and how that has a knock-on effect of developing DBAs and giving them an insight into best practises. These are some of my thoughts. I am not pretending to be a good manager, but I do try my best and these are some of the methods which I think have merit.
They are in ascending order of importance, however my top two wrote themselves, if you interview a DBA and ask him what the job is about and he does not come up with these two then I would be tempted to give up straight away.
1 Ensure that everyone has plenty to do
It is bizarre I know but I have often been in contracts with no work to do for days at a time because the project work has dried up. That is really poor management but it does happen. It is ideal for someone who is quite self-motivated but many do like to idle their time away under such circumstances.
I like each person in my team to have a list of at least 6 things on the go at any one time. Most will be on the back-burner but I do like to chase up that list and get them moving along. Multi-tasking is the way to go in my view, although it does make any sort of work tracking hard to calculate
2 Get the key priorities right
Database priorities –these are in the order that I think they should go but I am sure many will disagree with that order
People want to know what they should be doing. Sometimes people are just left without defined roles and responsibilities – where no one knows what is what or who is responsible for certain things.
So this commandment is really a two-parter, the responsibilities of the team and the responsibilities of the individuals within that team.
3 Provide the tools required for the job.
It is no good having clapped out old kit that is painfully slow as that leads to poor productivity. Investment in good kit pays dividends.
We are using Lync, which is a messenger type tool, that only works internally. That has really speeded up communication between the team members, some of whom are based in Europe and other who are local but hotdesk and sometimes are difficult to find.
Another time that it comes into its own is when doing upgrades and such out of hours and you can easily communicate with the apps people or Unix team.
Another tool that helps a lot is having a read-only NFS share that is auto-mounted on every database server. That allows a lot of shared scripts as well as each person’s own directory of scripts to be available to everyone. Quite often on Lync we will see a message ‘has anyone got a script to do xxxx’ and it is immediately available on every server.
4 Team members like good feedback.
That is not only feedback when things are going well. Sometimes I wonder whether it is harder to criticise or to praise. With the first it is very easy not to bother, to ignore, or just moan to yourself or someone close. With the second it is so easy not to do it.
Equally neither should be overdone. Personally I have always wanted to be told that I was doing OK or could improve in an area. As a contractor getting a renewal is often the only way you can tell that you are doing the right things. In my case I am sure it was often because they could not find anybody cheaper.
5.Encourage the circulation of new knowledge
This can serve several purposes, it stops information hoarding, it helps everyone work in an environment where they are encouraged to both learn and share and that has a knock on effect on my mission statement referred to in (8).
I used to send emails out to members of the DBA team at places where I worked that might include something like “You might know how to do this but I just found that the xxx command has a parameter that helps do yyy”. Quite often I would get responses back along the lines of “ha, I have known that for years” or just as many saying “hey, I didn’t know that either” . Obviously that technique is used sparingly otherwise it becomes silly but it really does encourage the sharing of ideas and equally the asking of questions to the group as a whole.
At one site where there was a very good team of DBAs I used to do that occasionally and one day a girl who was notorious for disliking contractors and who had just returned from maternity leave replied back to my email with the following comment.
“The company rule is that your email signature has to be in red”. In the meantime I had received about 3 comments thanking me for my mail. I mailed her back with the words ” I am colour blind, are you making fun of my disability?” and did not hear from her on the matter again. PS I just thought that green looked jazzier than red
6 Use staff to train one another
This is really an add-on to the previous commandment. One good way is that I encourage each member of the team to have time to research a topic, have sandpit time to experiment and learn how it works. That works really well for self-development but the big benefit is that I ask them to do a presentation to the rest of the team on the subject. In that way everyone gets some idea of what it is all about and as they get chance to ask questions and provide feedback it allows the speaker to see how well he know the matter as well as identifying any opportunities to use that feature.
7 Ensure that everyone knows what their responsibilities are
That can be both collective and individual responsibilities. If you have an inbox or ticketing system then it should be a team effort to keep it up to date, not the poor DBA who has been stuck with it the day that hell breaks loose. Equally that DBA should be empowered to ask his colleagues for help without feeling he has to beg or buy them a dozen coffees each. That is a team ethos.
8 Have a mission statement and stick to it
That is so 1990’s that I hesitated to write it. My mission statement is as follows
“My aim is to ensure that anyone who works for me has a better CV when they finish than when they started and that they are more valuable in the market-place as a result of working for me”
I truly do believe in and follow that ethos and it applies to permanent, contract and third-party supplied staff.
Your mission statement may be different, it may be “I will never have a production system fail because one of my team has been negligent” or “I will have a one-to-one with every one of my staff every week” or “I will read and react as necessary to every single weekly report I get”. All of those are good and I am sure there are many more that people use. However the one I use drives a lot of best practise in itself as I try to adhere to it. It avoids islands of knowledge (9), links in with (5), it encourages innovation and new ideas and promotes the general health of the team which then contributes to (10).
9 Sharing is everything
Which is better in a team – to have six mid-skill level staff or five mid-skill level and one top skilled person. Well either would work well in certain environments but if pressed I would always want the mid-level person who could communicate and share knowledge rather than someone who is much better but keeps it all to himself, or does not communicate well. The ideal is perhaps to have three mid and three high level people and ensure they all work together to try and get the mid-level people to move higher up the food-chain.
It is absolutely true that in a team you want a range of abilities and there should be opportunity to develop by learning from both your peers and your betters. Having contracted for quite a few years I have had experience of a number of workplaces and quite often there is somebody in there who does not share, who is protective, who does not document his knowledge.
Here are a few ways of sharing information.
- Keep a wiki – with a blog section on it. Encourage people to blog their findings.
- Ask team members to present at team meetings on areas where they are the SME
- Use any on-call rotas you have to ensure that everyone knows key pieces of information about each supported system
- Ask the team what they need to know and ensure that you follow up on it
- Use new members to ask the ‘naive’ questions that causes a lack of information sharing to be highlighted.
10 BAU – “Service is King” – Keep the systems running – availability
If you are paid to support production databases then the main driver is to ensure that they are up and running. Simple as that.
- That means you don’t add an index because it might help.
- You don’t do anything to risk service.
- You have a change control or agreement in place before you do anything.
It might not always be a production system that is important, it really depends on your environment. Recently we had a DBA login at weekend to try and improve LOB performance on a volume test environment. It was a really good effort, in his own time and as far as I could tell would have worked. However a code change had been deployed a few hours earlier. When the database was unusable later on as services could not connect it was the DBA team that got all the grief, had to restore the database 3 times and generally were under the cosh. The fact that everything worked again after the deployed code had been regressed was lost to most people involved.
I hope that has been helpful. To be honest I have found it quite enlightening whilst I have been thinking over the last few days about what I might put down. I have realised which areas I do well and which I am poor at. I understand how to manage a team, but managing people is much harder as everyone is different and has different aims and objectives. When building a team all you can hope to do is to channel some of those aims and objectives into delivering the service you are trying to do which neatly gets me back to commandment number 10. Service is King.