Voice of the DBA

Tag: culture

  • Under the Bus

    I’ve had a good career in database work. I’ve had success, and I’ve had some failures, fortunately the former far outpacing the latter. In my career across many companies, the code I’ve written has tended to work well, or at least well enough. I’ve managed systems and ensured a high uptime, and solved issues quickly. I have left quite a few jobs in technology, some because I was unhappy, some for better opportunities.

    I was asked to leave one job. I disagreed with my boss, thought he was a jerk, and our CTO told me this person was more valuable than I was at that time. The CTO suggested I move on, so I did. That day.

    I’ve been a manager of both development and operations groups at different positions. I learned as a manager that I praised my staff publicly and criticized them privately. That included taking blame for issues, but passing our kudos for success. A leader is responsible for the team, and that includes accepting the failures of individuals below them. That’s what I believe.

    In the last few years, there has been a bit of a trend where managers blame individual contributors. The Equifax ex-CEO blamed a single person for not patching their servers prior to the attack. Solarwinds CEO blamed an intern for an issue with posting a password to GitHub. There are other examples, but in many cases, senior management is blaming someone far below them for a mistake.

    I know technical people sometimes make decisions that are poor, they click the wrong thing, adjust the wrong server, or make some other mistake. However, in many cases, managers know about the work their people are doing. If they don’t, then isn’t that a management failure? While a manager might not know about patches, they know patching is important. It’s a manager’s job to place a priority on patching systems if this is important, and then ensuring someone verifies patches.

    I don’t expect managers to check repos for passwords, but certainly there are tools to help detect his. I certainly get alerts about a few passwords in my test scripts posted to some repos. Again, a manager should ask that controls, checks, verifications, etc. are a part of any processes that need security.

    I know that often the paychecks of senior managers are far above those of technical staff. I know it’s easy to blame someone making $60k a year and not accepting blame as a VP being paid $400k a year. I know that manure rolls downhill, but it’s disturbing that these executives aren’t being held accountable for the mistakes of their staff. It’s up to them to ensure that staff prioritizes what’s important, security, maintenance, whatever.

    As an individual contributor, I find this behavior is a symptom of a poor culture. We’re not a team when upper management throws people under the bus. To me, it’s a sign I need to seek new employment.

    Steve Jones

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

  • The Cost of Employee Turnover

    Sometime during the first 3-4 months of the pandemic, after offices all over the world closed, I thought that a lot of businesses would try to hold on to existing employees and minimize turnover. I also thought many employees would be nervous about changing jobs amid all the uncertainty.

    That wasn’t the case everywhere, and I was surprised at how much employee turnover occurred in many companies during 2020 and 2021. We had the Great Resignation, where talented employees (and some not-so-talented) found new employment with lots of remove flexibility. We typically have low turnover at Redgate, but more surprising to me was the number of people we’ve hired in the last two years.

    Our gains come from losses elsewhere. It seems a lot of companies have had a bit of turnover, more than they liked.  The costs of replacing a staffer has climbed to an average of USD$57k, according to a recent poll of hiring managers. I’m sure this is a combination of the time and money spent on recruiters and interviews as well the lost productivity of having less people around.

    For many of us working in technology, we realize that losing good people is a problem. Often we lose undocumented knowledge about our systems,  those shortcuts, checks, small tasks, not-so-obvious fixes, and more that make life easier. We can feel more stressed about additional work, or even the anticipated unknown challenges we might face. Moral, productivity, and motivation decrease, which creates a snowball effect. Everyone gets less done, which costs the organization more. Either lower revenue, more costs, or perhaps fewer services for those government or non-profit concerns.

    With large tech companies letting lots of talented people go, I wonder if we’ll see more competition in the employment market. For quite a few years there have been fewer workers than there are jobs. Perhaps that changes a bit in the future, though I still think there are not nearly enough talented workers for the positions open. Good for talented workers as they may have more choices, but also good for less talented workers when companies feel pressure to hire anyone.

    Except, what I’ve seen in a lot of companies is that they don’t want to hire anyone. Having a degree or cert isn’t enough. Companies aren’t going to hire you because you are Azure/AWS/etc. certified. They want tech skills and at least a few soft ones. That creates an even higher cost to fill positions, so maybe that USD$57k isn’t a bad number.

    To me, what this really means is that organizations ought to look at poor management, both middle and upper, and replace those people. That’s the problem in many places, one that isn’t easily fixed. Poor culture, micromanagement, lack of support, little-to-no psychological safety, and more contribute to poor retention.

    Culture is important and building it is hard. While not everyone will have a great culture, many organizations can avoid a poor one by treating people fairly and ensuring management understands how to do that. If for no other reason than to avoid the high costs of replacing staff.

    Steve Jones

  • A Mindset Shift

    I’ve been working with people at Microsoft for nearly two decades in different circumstances. It’s been interesting to me to work with developers, Microsoft consultants, and community people across the lifetime of SQLServerCentral, especially the last 5 years. For a long time, I never wanted to work there, but I’ve started to think I might find it to be an interesting company in the last couple years.

    There are two good articles that talk about the ways that Microsoft has changed. The first is from the high level culture perspective and tries to explain how the mindset has changed. If I hadn’t been witness to it, I wouldn’t believe it. These changes really happened, and they were amazing to me. I’ve been going to Redmond for 15 years, often working with a couple groups and since Satya Nadella took over, I’ve seen these changes get implemented. I’ve watched teams grow and change, and learn to re-frame the way they look at their work. I think it’s been a change for the better.

    The second one is a little more technically detailed, and perhaps more interesting to anyone that would like to get their organization to adopt DevOps. There are some specifics with tools, but really read about the mindset changes and the feedback they use to improve software. I think too many managers think automation and features are all you need to implement and forget that quality, experimentation and learning are keys to this working well. Make sure you point those out to managers if you pass this along.

    Not everyone at Microsoft made the transition. Some left, some were probably asked to leave. New people came, but plenty adapted, altered their mindset, and have bought into the way that the company has evolved. They’ve certainly gone from a company I wouldn’t want to work for because of the stacked ranking and competition to an organization I’d now consider employment within. That’s if they want someone remote in Denver.

    I’m proud that Redgate is also moving in this type of direction. We’ve learned a lot from DevOp and we’re learning that culture is important. We hire those that work well with us and help us build better tools for software developers in a team culture. Those that don’t want to work with a team, work in a DevOps flow, and be accountable for their autonomy will probably move on. That’s fine. We’re learning who we are and implementing that into our staff. I’ve tried to do the same in my life, know who I am and be that. I hope you can do the same.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.