Tag: career

  • Un-Stable Teams

    I’ve always valued having a team of people I know and can work with. While I haven’t had a lot of long-term jobs before Redgate, I have had a few positions that lasted more than a year and appreciated working with the same group for a long time. We might gain or lose a person, but overall, the structure of the team was the same day after day. This was a comfortable atmosphere, and I liked knowing who I was working with each day.

    At Redgate, we have had some stable teams of people, but in our engineering area, we move teams around. There is an annual re-teaming each December/January where engineers can choose to leave their team and ask to transfer to another one. They get to put in their top three choices (or remain on their team), and we do a good job of trying to match up everyone’s preferences. The number and charter of teams do change a bit each year, so engineers get visibility into the structure we’re planning before they mark a preference. It seems from our internal reports that we match up 99% of engineers with their first or second choices (first choice is in the high 80s).

    Recently our head of engineering talked about the dangers of a long-term stable team vs. making changes. Chris Smith noted that 25-33% of engineers look to move, which is my impression. I get to know who works on different products (or parts of them), and while I often know year-to-year who can help with which issues, I’m also surprised by the changes at times.

    I’m also disappointed sometimes because some very talented engineers will leave a team to move to another. That can worry me as I know how much knowledge is leaving. At the same time, as Chris pointed out, sometimes very talented people will leave an organization because they feel stuck in one job. There also is value in cognitive diversity, which is something I look for. We need to get along, but I like working with people that think differently than I do.

    I haven’t seen this need to move as much in operations teams as in development teams. Maybe the nature of the person who supports systems is different than those who build them, but I do find long-term system administrators sometimes struggle with change and improvements. I’m not fond of change for change’s sake, and I want to justify new technologies/protocols/etc. However, I also think as technology changes, we ought to objectively evaluate if it’s better. Not all change is, but some certainly improve the environment.

    Do you prefer a stable team or do you like to change periodically? A lot of companies move people around, sometimes on a schedule, to ensure they can grow and bring new ideas and perspectives to other teams. Does your employer do this? Do you like the idea or would you prefer not to re-team periodically?

    Steve Jones

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

  • Do You Have a Jeff?

    In the Phoenix Project (worth a read), there is a character called Brent, who is to go-to person for everything in IT. I don’t know if this character was modeled after Brent Ozar, but I always picture him when I re-read the book, and I suspect he was that person in previous positions. I’ve been that person as well, and it’s both exciting, fulfilling, and very stressful. At Redgate, that person has been Robert C, who is my go-to person for many questions.

    In the DBA world, I think of Jeff Moden. He’s been a prolific and incredible author over the years on many things SQL-related and is a huge proponent of others learning to write better code and better utilize the database platform more efficiently. I suspect in his company, he is the go-to person for most database-related questions and problems. I also suspect he solves most of them very well and has the influence (or power) to effect change.

    However, are you Jeff in your organization? Do you have a Jeff? In many of the customers I work with, there is no Jeff. Sometimes there are very smart people, but they cannot effect change. Or they don’t know how to go about making change happen. In other companies, there isn’t anyone who is an expert on the database or related technologies. Too often, I think people aren’t often aware of what expert really is and they just do the best they can without knowing if it’s a great job or a poor one. That’s my opinion, but it’s based on decades of experience (and success) working with lots of others on database code.

    The good news is that most of you can learn to be Jeff. You can work to improve your skills, both technical and interpersonal (soft), to raise the quality bar at your organization. Maybe you can get more work done and get a huge sense of satisfaction from your job (and a raise). Maybe you just want to get things done more efficiently and get away from work more often.

    There are many ways to do improve the quality at work, but essentially the idea behind platform engineering is to produce tools that make developers and operations groups more efficient. The goal is to get more work done, easier, reducing the cognitive load on everyone involved with software. Not because they can’t do the work, but because we want them focused on their specialty. Whether that’s writing C# code for an application, writing zero downtime database changes, or making beautiful reports. The hassles of actually capturing and moving code should be something provided by a platform. A person can do some of this by sharing their knowledge, not just in conversations, but providing templates, models, standards, and other code elements that might help their co-workers become more productive.

    DevOps is about producing code quicker, reliably delivering that to the customer, and raising the quality bar (don’t forget this) and platform engineering is the next evolution here, where the tools, process, and flow are set to make the implementation of DevOps easier for most developers and DBAs. Even if your organization doesn’t want to produce a platform, the idea of building and deploying tools (samples, models, snippets, etc.) to make someone else’s job (or yours) easier and smoother is something we all can do. We can all aspire to be Jeff and get there with a little investment in our skill across time.

    Steve Jones

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

  • Mind Over Milkshake (Thoughts Matter)

    Last year I went to THAT Conference in Wisconsin. It was a fun event, very community and family-friendly, and I enjoyed it. So much so that I recently went back to the Texas event in January. It’s more developer-focused, but it does have some data related sessions. I recommend this conference if you’re looking for some fun training and want to combine that with a family vacation. Your kids will love it.

    In any case, I watched a keynote talk that referenced an NPR article, called Mind over Milkshake. It’s an interesting look at how the food labels affected people’s bodies. It’s not definitive and I wouldn’t make any drastic changes based on this, but it is an interesting read on the idea your mind and thoughts can influence your body. I’ve heard about the effect of placebos in the past, we well as attitude on healing, so this makes some sense.

    I don’t know to what extent this would change how I manage my health and medical care, but I do think a similar idea is important in my work with databases. I see lots of people who have a negative attitude towards learning, change, or even adopting new/better ways of doing things. So many people, whether workers or management, get stuck in a rut and want to stay there. Or they don’t feel empowered to change. It’s why I find the cultural part of DevOps way more challenging in organizations than the technology part.

    In some of my management positions, I’ve often challenged workers not to bring problems, but to find solutions. I want them to view the issues we face, the things that go wrong, as opportunities to improve, not set-in-stone problems that we gripe about. I know many chronic issues recur regularly. I also know that in any organization, there can be resistance to change, and a “we’ve always done it that way” attitude. However, adopting that for yourself is how things continue to linger on (or get worse).

    Your mindset can make a huge difference in how you approach situations, including how much stress you feel from the environment. I don’t advocate change for change’s sake, but I do look to critically evaluate if something works well or can be improved. I’ve also learned to ask for change and that being turned down doesn’t mean that nothing changes. Or nothing ever well, or even this thing won’t change. It often means that this particular thing can’t change, or that it can’t change now. I have also learned to separate this request from another request for a different change. The key is often to analyze the solution, prepare a good reason why something should change, and present this un-emotionally.

    I know when I approach things as an opportunity life is better. Even if I don’t make a difference, or I don’t like the outcome, I feel better about it. Try it, and you might feel the same way.

    Steve Jones

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

  • Webinar Tomorrow: Navigating the Database Landscape in 2024

    You can still register and join me tomorrow. I’ll actually be in Austin at the Redgate office doing the webinar, which should be interesting.

    Send your questions, comments, and have some fun as we look at the results from our survey of 3500+ database professionals.