Slipping out of the DBA trenches

  • Comments posted to this topic are about the item Slipping out of the DBA trenches

  • A DBA manager doesn't need immense technical knowledge to be effective - that's what the DBA's are for. The manger's role is to make sure the way is clear for the DBA's to do their jobs, fight the budget and staffing battles, and stand up for the troops. the DBA manager needs just enough knowledge to keep up with the trends, and to know when the employees aren't being effective. When questions arise, the important knowledge is where to go for the answer.

  • Rodney, great article.

    Ross, great answer, ... so I will just say "What he said".

    <><
    Livin' down on the cube farm. Left, left, then a right.

  • Eventually everyone has to decide whether to stay the technical craftman or move into management. Definitely agree as a manager that you have to stay technically engaged, but you have to give up being the alpha geek if you really want to succeed at managing. Hard choice to give up living totally in tech, not the right fit for everyone.

  • The best manager I had knew technology at a high level. The worst manager I had came from the trenches. The trench guy always wanted to micromanage the projects down to the code. He felt only he could do it right. He failed miserably as a manager because he had little time for budgets and handling personnel issues.

    Fight the good fight in the boardroom for budgets, training, benefits, and projects but stay out of my hair regarding the project details. I will answer to you if something goes wrong. A good mentor always hands over the keys at some point. A good manager gives general direction but leaves the details to the staff.

  • I'll agree with most of what's been posted already. Do what you're doing when you're doing it. If your job is to manage, then learn to manage well. If your job is to administer databases, then administer databases well.

    Don't worry about keeping up with every new detail that comes along. There are too many for any single human being to deal with all of them. Learn the important ones, and pick up the rest as you find you need them. That applies to management skills just as much as it does to technical ones.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Speaking as both a former DBA manager and former DBA - major financial institution with 2500+ SQL Server boxes from dinky little databases of 10Mb to multi-instance cross-site clusters databases in the hundreds of terabytes (not to mention Oracle/Sybase/IMS/DB2) - your role is not to be a DBA, but to construct the framework to enable your people to do their jobs, and to get what they need to deliver. Not to be a DBA. If you try to be a better DBA than your staff, you will fail as a manager. Instead, you will want to micromanage them to death, and they will not respect or trust you, and will resent your very existence.

    The most important lesson I ever learnt as a DBA manager was when to let go - even if you know the answer and your DBAs don't, you have to step out of the way. Of course, that never stops you from offering some gentle hints to keep them moving in approximately the right direction - but let your DBAs own the solution. Even if it means they make mistakes.

  • I tried the manager route for a while and ultimately decided it was not for me. I would go home at the end of the day feeling that I accomplished nothing despite that never being the case. I would spend my time trying to keep the heat off my people, allow them to focus on their jobs and not deal with the politics of situations. The group was successful, I did not feel that I was.

    I was still getting my fingers dirty whenever possible however my knowledge was getting stale, stagnant even. I was told that I had to get myself completely out of the technical to move up the management chain. I sat down and gave it a great deal of thought and came to realize that management had made me miserable. All the fun had gone out of my job and I was just not enjoying myself. Upshot was that I asked to move back to a technical role, never been so glad to do so. Sure, long days, much stress, people yelling, but so much better than management for me.



    Shamless self promotion - read my blog http://sirsql.net

  • I think skjoldtc makes a good point regarding the trench guy. A trench guy that becomes management without leaving the trench behind is doomed to fail. Yes, you have to know the technology and best practices, but you have to trust your people with maintaining the level of skill the trenches require. If you can't make that break and focus on the higher level tasks set before you, it's going to be a tough road.

    As was pointed out, good DBA's don't necessarily make good DBA managers and (arguably) vice-versa.

  • Excellent post. I'm a self-taught geek as well. I got a summer job at a software company when I was 19 and never looked back. (Besides, I could never explain why I was going to school for chemical engineering and existential philosophy in the first place.) Certifications and 16 years of experience later, I still grapple with where I truly fit.

    You discuss the problem in terms of DBAs and DBA Management, and it's certainly valid for those domains. But I'm working through it from the Product Management side. I had the opportunity to spend a lot of time working directly with clients so I heard exactly what people needed, saw how they used the applications daily, and could see the gaps and solutions. It's exactly the knowledge you need to make the right product strategy decisions. So then I was given the role to make product strategy decisions and I spent less and less time with the clients directly. I encouraged feedback from Implementers and PMs, but it still felt removed and the answers didn't come quite as easily. I read a lot and research and listen, but I still don't feel like I know as much as I did. Finding a Business Analyst or PM who can hear what the client isn't saying and then articulate it has been the key. But intuitive, perceptive technicians aren't very common, and it takes time to ferret them out. So perhaps you already have the answer - find someone newer in the field who is fresh with the technology but able to grasp the strategic aspects, and become a team. You both learn from each other.

    This discussion has brought me to an interesting question. Of the people you consider great at their technology jobs, how many of them have a background in pure technology?

    ~Jessica

  • I agree with most of what has been said. Managers manage, know some technical, have the backs of their employees and trust the employees to do the jobs. If Managers try to be the DBA doing the work, then they must be absolutely cautious not to step on DBA toes.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Had an interesting conversation with a friend of mine a while back. He is a systems engineer type who is now a Deputy Program Manager. When he moved up to a management postion he expressed a simaliar view. Where he would have just stepped in, he found himself making "suggestions" and asking "questions" instead. He has proven to be a very wise person in my life so far as I contemplate various possibilities in my career.

  • Great Post!! I started from the trenches too - got opportunities to be a manager, tried one job at that and went back to my 'trenches' - it is not for me, as Andy said i can't let go of technology totally, i hate micro managing people, and above all - i loathe the corporate dishonesty/selfishness and politics that a manager has to deal with. In the asian culture i was raised corporations had their politics but had some principles to abide by in addition to that - people were not fired unless they were completely unsuited to their jobs, and profits were shared equally among employees. With those values missing in corporate america i dont believe the ladder is worth climbing. I also believe it is somewhat of a misconception that the only route a DBA gets to take is be a manager or stay where you are - there are technically senior positions, a great example is Brent Ozar's title 'SQL Server Expert'. I'd like to be one and leave the politics to those who can do it well.

  • The key to being successful in management is to make the job your own...just the right mix of technology, people and politics to keep you happy. Of course, this is easier said than done. There are a lot of egos above you and below, and the company and culture can control you instead of you taking control. In my career, any job of importance that I have held, management or not, has involved a lot of dirty work involving politics, persuasion, and negotiation. I always thought that it was better to do the dirty work from a position of power with a better title, and being in management made a difference to my increased job satisfaction.

    LinkedIn - http://www.linkedin.com/in/carlosbossy
    Blog - http://www.carlosbossy.com
    Follow me - @carlosbossy

  • Just a note that I used to manage a team of 10 DBAs. I was the next to lowest paid person in the group. This was at a large 10,000+ employee company. Being a manager doesn't mean you make more.

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply