Tag: career

Many of us would prefer that the technology industry were a strict meritocracy. One where we get opportunities and are compensated according to our skills. We learn to code better, or manage more systems, and we’re seen as more valuable (and rewarded appropriately). Or maybe many of us would prefer that things stay the same, since we might worry that we’d be paid less because our skills aren’t as sharp as our co-workers or our competition for that next job.

In any case, we don’t work in a strict meritocracy, but if we did, we might recognize that it’s not just your programming skills that are being measured. In this piece on hard and soft skills, the author notes that the importance of soft skills is both more and less serious than we might imagine. If that sounds contradictory, it is, but read the article and you’ll see that this is a complex issue.

The main point from the author is one that we’ve realized at Redgate for some time, and it’s why we’re constantly refocusing our efforts on teamwork. Most modern systems are too complex to be built by one person, which means a group of people need to work together. DevOps asks us to build a culture of collaboration and communication, which are critical soft skills. It matters less and less if you’re an amazing developer that can’t work with others for some reason.

I do think that the more you advance in your career, the more important these skills become as your job is not just code. It’s also helping shape the direction of software, teaching others, and sharing what you know. If you don’t have the skills to interact well with others, then I suspect your ceiling may be lower than you like. Or worse, your tenure shorter than you’d prefer.

At Redgate, we do embed a lot of customer research, discussions, and more inside development teams.  At times, I think we do too much, but then I stop and think about the teams I’ve worked with that didn’t do this. They didn’t necessarily code quicker, certainly lacked understanding and empathy, and certainly didn’t make more customers happy. We’re trying to adopt more soft skills inside the company, while learning to build better software. We still value technical programming skills, but not necessarily above teamwork. More alongside teamwork.

To build a team, we need to value those in the team, and work with them, not against them. Those are skills that can certainly help us in our career, as well as skills that help any organization learn to operate more smoothly, with more retention. At least, more retention of those that have strong soft skills.

Steve Jones

Listen to the podcast at Libsyn

I get asked this question regularly each year as I start coaching volleyball: “what do you do?” New parents are always interested in what the coach does outside of running their kids around a court. This year, I actually got asked this question a couple weekends ago at the final tournament by a parent that I’d talked to many times, but this was the first time we had an extended conversation. It’s always a little funny to explain what I do, since it’s a mix of quite a few jobs, most of which are somewhat out or the ordinary.

There was an interesting post from Pamela Mooney recently that reminded me that many of us perform jobs that are a little harder to describe to others. Or maybe we are a bit too literal in how we communicate and struggle to concisely express our job responsibilities. In any case, I like the analogies that Pamela makes to the medical industry where there are many specialties with vastly different skills. It’s similar for data professionals, though there are really many less potential specialties. Pamela has a general definition that covers lots of things:

DBAs are the guardians and facilitators of the company’s data.

Guardians covers most of the administrative responsibilities. Protect it with backups and security, ensure it’s still there, and more. Facilitator might be more development focused, but availability and performance would certainly fall under this description as well. The more I think about it, the more I think this is a good general description.

One that’s not likely to mean much to laymen.

I’m sure most of you have had to answer the question at some point in the past. Thinking about it now, without the pressure to respond in real time, how would you easily describe what you do? What do you say about your job? Perhaps you talk about the parts that you really like, or that things you are proud to do. Maybe you mention the things that annoy you the most.

Let us know today what you respond with, and try to do better than the generic I often give: “I’m a computer guy.”

Steve Jones

Listen to the podcast at Libsyn