Voice of the DBA

Author: way0utwest

  • Negotiating Salary for a New Job

    Slightly off topic, but I’m adding this one to the Modern Resume blog since I think it’s something to be aware of in managing your career, and to some extent, your brand. How you handle this reflects on you, and I wanted to note a little advice.
    I ran across this post from Brent Ozar on salary negotiations that gives some advice. It was in response to a Twitter post, which proves one great thing about where you can get inspiration: Twitter! For the most part I agree with Brent’s advice, but I have a slightly different take on how to handle it.

    Ask, Don’t Answer

    My basic advice is that you ought to get an idea of what the job is paying first, and as soon as possible. Money does matter, and it can break negotiations down if the number of too low.
    There is no good average salary for some jobs. I know that HR people like to think there is, but I have seen it quite often that the ranges for a particular job, and skillset, can vary widely in companies. I think that it’s it’s in part because the value placed on a particular job can vary widely from company to company. However, I would say that the majority of the issue is that most people are poor negotiators.
    I’m getting slightly off track here, but my first advice is that early on in the initial interview, probably over the phone, you get an idea of the salary range the company is looking to pay. If they ask you what you are making, tactfully ask them what the job pays. If they press let them know that you do not necessarily want to disclose your salary right now until you find out more about the job. Defer the discussion.
    Why?
    If you are expecting, or need, to make $75,000/yr and the job is for $55,000/yr, there might not be a point in continuing.  I’ve had that happen to me (not those numbers, but a similar experience) and it spurred me to ask them if that was a hard range or could anything be done to raise it. I have let them know that I can’t work for that number and in some cases they considered raising it, some they didn’t. However if it’s a make or break number, then it’s good to get that out of the way up front and stop wasting each other’s time.
    After that, I think I’d follow Brent’s advice and give you current salary as a multiple of 10. You make in the “60s” or the “80s”, but there’s no need to give an exact figure. Information is power, and a sharp negotiator, like an experienced HR person or manager, will use an exact number to beat you down on your salary.

    Have Reasons

    Whether you hoping to make more money, or take a pay cut, have reasons for your move. Keep in mind that anything you say as a slight against your current situation could be seen as a potential negative to a new employer. Tread carefully, but honestly in your reasons for your new salary (up or down).
    Above all, be honest. There’s no reason for you to lie about your salary, and it can only hurt later on down  the road if someone finds out. Give an honest range in which you currently fall.
    Lastly, the best argument is that they are paying you to do a job, and even if that job is paying 20% more than you currently make, if they think you can do the job, they should pay you.

  • What is SQL Server? – Rocky Mountain Tech Trifecta

    I’m doing a basic presentation at the Rocky Mountain Tech Trifecta later this month on what SQL Server is from a basic viewpoint. I had a request for this at the SQL Saturday #17 in Baton Rouge last year and I’ve been meaning to get it written. Apparenltly there are a decent number of developers, managers, PMs, etc. that attend events, trying to better understand technology and it seems that we don’t often get to a basic enough level for them.

    So what is SQL Server? A set of Excel spreadsheets? Is it a filing cabinet? Is it a library? Is it a storage mechanism or something more complex?

    You’ll have to see the presentation to get my thoughts. However I would be interested in analogies or ideas that others have for explaining SQL Server to a manager, a new developer, or maybe even your Mom or kids.

    I’ll try to record a version and stick it up on the Internet at some point.

  • Interviewed at CSTechCast

    cstechcastlogo The segment should go out in this week’s show, but I spent half a day down in Colorado Springs with the CSTechCast crew, doing an interview for their weekly podcast.

    They hosts of the show, Eric, Eric, and Josh, are friends I’ve known for a few years in the local tech community. I did an interview a few years back for their audio only podcast, but this was my first video interview with them. I talked about free training and the SQL Saturday franchise, so check out the show this week.

    I’d also recommend this as a decent summary of the tech world in general from the perspective of a few different technology areas. They cover Windows, Exchange, Development, along with SQL Server, and have a good rapport with each other. It’s a long show, 40 minutes, but running in the background it should provide you with a nice summary of the past week’s tech world, and perhaps broaden your view of technology.

  • Relationships – T-SQL Tuesday #3

    I missed T-SQL Tuesday #1, but participated in T-SQL Tuesday #2. Now it’s time for #3, and I’m making my entry. I like this style of getting a series of posts from the community on a topic, and thanks to Rob Farley, we have an interesting and open-ended topic for T-SQL Tuesday #3: Relationships.

    Making Friends
    Some year ago I started a new job as a DBA with a large company. I was a production guy, working in the Operations group that was responsible for keeping our live systems running. That’s the kind of work I enjoy.

    In the company there was also an Engineering group, that was a counter-part to my group. They helped architect, design, sometimes build solutions that we would then deploy. As you might expect, there were usually bugs or issues in systems, and since my group was on-call for issues, we had to support those systems at night, often without a lot of help from Engineering after hours. The relationship between the groups was somewhat contentious, and even outright hostile at times.

    Enter Steve. New DBA, and taking the place of a senior DBA that had moved on. Without the baggage of previous relationships, I wasn’t aware of issues. However when I got a call one day asking if the DBA could come help Engineering on an issue, I headed over. More than a few of my co-workers told me that I should stand my ground and not let the Engineering group tell me what to do.

    Walking over to the other side of the building, I couldn’t help but wonder what I was in for. All the talk from my group had put me in a slightly defensive mood, but when I got there, all I found was another IT guy asking for help discovering why something wasn’t working. A little SQL Server debugging and tracing, and I’d fixed his issue, gotten thanks, chatted for a few minutes, and then went back to work.

    Over the next few months, I had a few more encounters with Engineering and Security people, usually being called to solve a problem. I made some friendships by helping people get their jobs done. I left my ego at the door, and just solved problems, even when they were self-inflicted by people that ought to know better.

    Those relationships were handy later in my career at that company. There were times I needed to shortcut a rule to get something done, and would get the help I needed. My responsibility to comply with paperwork or regulations had to be completed, but having a good working relationship allowed me to get the work done first, and the documentation second. It also helped me to stop an Engineering deployment a few times and let them know that they had a system with issues and their group was responsible. Hearing that from someone with whom you have a good relationship is completely different than hearing that from someone you dislike. It allowed me to legitimately push-back and have someone listen to my reasons without being overly defensive from the start.

    In short, the relationships helped me to get work done and problems solved in an efficient matter. Sometimes being a DBA means working on relationships outside of SQL Server in order to have those inside SQL Server work better.