Voice of the DBA

Category: Editorial

  • What Do You Want to Know Before Negotiating Salary?

    Many of us are employed, and while we might have a salary review each year, we often don’t get to negotiate much about the amount. We might periodically ask for a raise of some sort, but what should we ask for? Most of us have accepted employment at some point, responding to the offer of a job. Do we know what a fair salary is for our position, in our location, with our experience?

    Human Resources and Personnel departments use surveys and information to set ranges of pay for different positions. They come to a salary negotiation with some idea of the market, which is a generalization of what an employee is worth. This could be quite different than what you specifically feel you should be paid. However, do you have any rationale for your demands?

    Every year Brent Ozar runs a salary survey. He gets lots of responses and does a better job of this than most other places I’ve seen. Including me. I’ve done this a few times, but I’d rather just let Brent run this and view his data. This year he asks you to look at the list of questions and give feedback.

    I think Brent has a good list of questions, but perhaps there is something you wish you’d have known before you last negotiated salary. Is there something that might help you decide if an offer (or raise) is fair? Perhaps you want to add a checklist of responsibilities (BI, DBA, dev, etc.).

    Maybe you think it would be interesting to know if there is on call work, or even the number of hours your employer expects you to work? Given the pandemic I might ask if the company is allowing remote work or expecting people to come back to an office. Some people have suggested these in the comments, but read Brent’s answers. He’s looking for a indicators or features that affect salary, not necessarily how you feel about the environment. I added one about non-monetary compensation like training, but feel free to comment on other suggestions as well.

    What’s really important here is that you take the survey when it comes out. Even if you don’t like the questions, getting this data compiled for our industry helps us all, so keep an eye out for the survey and fill it out to the best of your ability. Then get the results when they are published and use them to try and evaluate if you’re being compensated fairly.

    Steve Jones

  • Do You Have a Talent Gap?

    I have seen articles over the years that talk about a talent gap in companies, similar to this one. For a long time early in my career, it seemed anyone that went through a boot camp could get a job, and we had lots of unqualified people earning lots of money. I know I’ve run into my share of paper-CNE’s, paper-MCSE’s, and more in my career that took advantage of that talent gap. Over time it seemed that many companies stopped relying on certifications in hiring, but this didn’t seem to help us find more qualified workers. We either were short of staff or still had plenty of people that couldn’t do the work that well.

    During the last year, I have seen lots of articles about companies that are struggling to find workers at all levels, even though the pandemic has broadened the search space. Companies learned to work remotely and many started to hire people in different cities. I know a lot of people that changed jobs in the last year. Many landing a remote position at a company they would rarely if ever, drive to visit. I still hope the pandemic repercussions will include hiring more people in different locations, though that may not be the case for all organizations. Many managers seem to assume they will bring everyone back into an office at some point.

    However, the talent gap is real, and it’s existed for years. There has been a concern for many years from managers about their staff having the proper skills for the future. I hear constantly from customers that they don’t have enough trained people that understand some of the modern tools available. This is especially true for those technologies that are DevOps related. This includes version control, which I think is a basic skill. There are plenty of people that don’t understand the basics of writing code and committing it in Git.

    I do think some talent gap of this is the result of technology changing so fast, with new options and products to learn. Many of us feel we can’t ever keep up. I know I do, though I think that’s both true and not something to worry about. If you don’t use tools at work, you might think there’s no point in learning about them. If you are excited about technology, you can still be intimidated by all the choices out there. Do you look at Jenkins or Azure DevOps? We email scripts around, so is there a point to git? I even feel that way with Redgate products. They update every week or two and I’m always behind in trying to learn about them and decide if I need to worry about a specific feature.

    I think the talent gap is real, but I also think that learning to be comfortable with being a little uncomfortable is important. It’s unlikely you will be an expert with a tool anytime soon, so learn to be productive and effective. Maybe, more importantly, learn to learn. Spend time going through a tutorial or tackling a walk-through and get some comfort with technology. If you do need to learn more, then you can ask for resources.

    The talent gap is real for many of us, and certainly for many organizations. That’s not likely to change, so learning to adapt to the situation is probably best for all of us.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Incident Review

    Something will always go wrong with our software systems. Issues might happen regularly or rarely, but something is going to go wrong at some point and a client will complain. Often the way we handle these situations determines whether our customers continue to do business with us or look for an alternative.

    In my career, I’ve been a part of many incidents, lots of which were service outages for customers. I’ve attended some incidents as a technical person working to diagnose the issue. In other incidents, I’ve been a developer that has to fix code. During many, my role was as a manager trying to ensure information moves smoothly between resources, ensuring people double-checked that our “fix” wouldn’t cause another problem. After a problem, I’ve also had to take part in a post-incident review. Unfortunately, this has happened far less often than it should.

    When I read this description of a post-incident review, it is unlike many of the after-action meetings I’ve attended. In my experience, there is one meeting and someone is being blamed. Senior management is often there, putting pressure on everyone in attendance to “never let this happen again.” I haven’t known anyone that wanted to go through another outage or a post-incident meeting after an incident, but with complex systems, and humans managing them, something is bound to go wrong. We should expect to have incidents in the future.

    What we want is this same type of incident to not get repeated, which comes about if we learn from our mistakes and design better protocols that help us catch mistakes.  Often to ensure a human doesn’t make a simple error. We should accept that mistakes will happen and try to find ways to detect the problem quickly, limit the scope of impact, and provide a way to share this knowledge with other workers. Depending on humans to be more perfect in the future isn’t likely to be successful.

    These days I read post-incident reviews that my company will publish after an outage, I find them fact-based, focusing on what things went wrong without blaming a person. They include analysis not only of the actual issue but the conditions that led to the hardware/software failure or decision that was made. There are learnings about how we might have prevented something with a time machine, while still assuming that humans would make mistakes or a component might fail. There are also suggestions for improvements in hardware, software, training, or monitoring that might assist in quicker recovery in the future.

    Coming out of an incident with a positive mindset is the best way to try and prevent a repeat of the same incident in the future. This requires that we not only avoid blaming someone for an error but that we also take steps to limit the potential for future errors. If the issue is someone clicking the wrong selection in a drop-down or pressing “OK” when they meant to press “Cancel”, there are limited ways to prevent those issues. However, we can adopt the mindset an outage is a team failure and build a habit of double checking each other. That’s much better than blaming one person, giving the job to another human, who might easily make the same mistake.

    Many humans struggle to avoid placing blame on others and just accepting that some mistakes will happen. A DevOps mindset, with blameless reviews instead focuses on how we can do better as a group, rather than how we failed as an individual. This little change helps us build a better team, one that often performs better in the future.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Making Software Decisions

    I work for a company that builds software. At Redgate, we are constantly debating what to build and how, and more importantly, how to structure something that is easy for our customers to use. There’s a lot that goes into the process of building software, way more than I thought was important a decade ago. Today, even when I don’t like the decision or the final result in a product, I know our process often produces good results.

    Recently Netflix started a new series on how they make decisions for their software. It’s interesting in that they note that of all the ways they can make decisions, most of these involve few people. This leads towards their premise of using lots of A/B experimentation for helping to make decisions, and I look forward to future parts of the series that might explain the weight that they give to the results of A/B testing versus the opinions of developers and management.

    How do you decide what decision makes the most sense for your business? I often see technology professionals being very passionate about how or why something should be implemented. I also think that sometimes we lend more weight to the passion of the arguer, rather than the merits of the particular thing being examined. It’s easy to give in and go with the group, or not care, about many software decisions.

    For me, I’ve learned to try and give feedback, justify this with some rationale, and then trust the process. No matter how “right” I think I am, we are a team, and if the decision is made to go a different way, I support that. I’ve also learned that building software involves a lot of tradeoffs, especially with regard to the prioritization of work. There’s always more work to do than can be completed by our staff, no matter what the size of the team.

    I find the process of building commercial software to be fascinating and I’ve learned a lot in the last few years about how to make the process successful. I’ve also learned what Netflix talks about. A small group has a very limited viewpoint and it’s worth gathering more data whenever possible to ensure you make a decision that has a positive impact on your software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.