Settings Goals Professionally

I was reminded of this topic after yesterday’s #SQLChat. Have you set professional goals for yourself? If so, have you set them professionally? What do I mean?

There’s a difference between a wish and a goal. A wish is something we want to happen but we don’t make any effort towards seeing it come to pass. Perhaps we can’t. I can’t be back in high school to warn myself about playing with several of the injuries that continue to nag me today. But quite a few wishes are within our grasps. We just don’t move forward towards them. The thing about a goal is that we have to decide to move towards accomplishing it. We won’t accomplish all of our goals. However, we will make attempts to accomplish each of them.

With that defined, let’s talking about setting them professionally.

First, you have to clearly outline your goal. If you’re familiar with the SMART acronym for goal setting, this is the Specific part of it. What are you trying to accomplish? How do you know when you’re successful? An example of a bad goal: I want to be happy in my job. What’s wrong with this goal? How do you know what happy looks like? Your specifics could include details about pay, about how much you work (hours is a measurable quantity), or it could be something like, “Each morning I will wake up and determine if I look forward to going to work each morning. 3/4 of the mornings for the year, I want that answer to be yes. That’s how I know I’ll be happy.” We’ve taken something abstract and made it measurable.

Second is the M in SMART, that the goal is Measurable. I’ve already given an example on specific, but we must be able to measure if we’ve accomplished our goal. We also would like to be measure possible progress. Being able to measure means we have a good idea where we stand on accomplishing a goal and what it looks like when we have met that goal. If you don’t measure, you’ll be less likely to push forward towards accomplishing your goal.

Third is the goal should be Attainable. We want it to be a goal, not a wish. I’m not going to be able to reverse time back to high school. At least, not right now. And even if I could, that might not be the best plan as my past determines who I am now. Goals should cause us to strive and stretch, but they shouldn’t be completely out of reach. Goals like that serve to discourage us, not help us move forward.

Relevance is the fourth part of setting goals professionally. Why does the goal matter to you? If the goal doesn’t matter, you won’t make it a priority. Perhaps someone has suggested something be your goal. This often happens to us professionally. Maybe there is motivation to move a goal to relevant status when it normally would not be (such as continued employment at a place where you’re “happy”). However, if you can’t see a goal as relevant to you, it’s very unlikely you’re going to put much effort towards accomplishing it.

The final part is ensuring your goals are Time Bound. What’s the timeline for you to accomplish that goal? We can define goals with no expected completion date. That’s generally not a good idea. If you do this, how do you know your current rate of progress? How do you give yourself that kick in the tail to work harder if there’s no end date? But the end date isn’t the only part of the goal. If you’ve got steps to get towards that end date, when should you be accomplishing those steps.

Got all this? Great! Now, write it all down. Put your goals somewhere you can regularly review. And then do the review. Recalibrate based on how you’re doing. Don’t let goals be like most folks’ New Year’s Resolutions. Make them something you set and achieve.


Tinker as You Learn

In recent weeks I’ve seen my brother from another mother, Andy Leonard (twitter | blog), write or post about his learning activities. In one case he remarked that he liked it when he went to complete a learning lab exercise and it didn’t work as expected the first time around. When the lab doesn’t work, you have an opportunity to troubleshoot why. You learn more than if you just are able to follow the steps perfectly. Basically, what you’re doing is tinkering. And you gain more knowledge as a result.

In a second case he was asked by a friend if he could write a quick SSIS package. Andy did. But he also spent time figuring out different ways he could do the same task using BIML. More tinkering. More learning. He had the time. He invested it.

If you think about it, this is often how children learn. They don’t start following a series of steps: 1, 2, and 3. They pull things apart. They try things you aren’t supposed to try. Sometimes it works. Sometimes it fails spectacularly. And sometimes something new is the result. For instance, I wonder how the first kid got the idea to secure a baseball card in the spokes of his or her bicycle to make that clicking sound as the wheel turned. It doesn’t matter how the kid came up with it I suppose, but it was definitely a popular thing to do. Nowadays we have little pieces of plastic that do the same thing. But the first occurrence was found by tinkering.

I know that I enjoy tinkering, even if it is with something I supposedly know well. That’s how I was able to get so deep into SQL Server security. It’s also how I learned how to read network traces to understand how DNS, Active Directory, SQL Server, web servers, and other applications communicate at the network layer. That’s how I learned to spot and understand when something isn’t right in those communications.

Don’t just be content with the checklist or 1,2,3 types of learning. Play. Tinker. Try new things. If you’re using VMs, understand how you can roll back to a snapshot and how you can apply/commit changes forward. If you know these things, you can always get back to where you were if you do have that spectacular failure. And you can also set your new starting point if you figure out something interesting or effective. But most of us, don’t be afraid to tinker.

WIT: A Quick Thought

I recently had the opportunity to be a Dungeon Master (DM) at a gaming convention. It was my first time. I loved it. So what does that have to do with Women in Technology (WIT)?

The young lady standing up also DMed her first convention. She’s my daughter and she’s 12. When we were signing up for DM slots, I asked the organizer if he felt there was any issue with her signing up to DM just like any other DM. He didn’t. She had been DMing D&D Adventurers League locally and had done well enough that he didn’t have any issue with it. 

He evaluated her on the merits of her body of work. He could have said no because she was 12. He could have said no because she was a girl. He could have said no for a whole host of reasons that had nothing to do with her ability to unravel the story, adjudicate the rules, and provide for a pleasant and entertaining player experience. He chose to judge her on her capabilities as a DM. 

When I work with colleagues, I care about their skills: technical and soft skills. I want to work with top folks so we can deliver excellent results as quickly as possible. I’m not interested in wasting time on the job because we have a less capable person that was hired and included only because that person meets some cliquish requirements that have nothing to do with the job. See, I have a personal life that’s important to me. I have folks outside of work I want to spend time with, like my daughter pictured above. 

I also want to deliver the best results I can to be competitive in the workplace and so my organization is as competitive as possible. Wasting cycles because somebody reminds me of my high school or college friends or because that person has more in common with me for non-work related characteristics than another is just plain foolishness. To do so negatively impacts my ability to stay gainfully employed and make a way for the people who are most important to me, like my family. 
As a group, the females in IT are in every work-related way as competent as men. They don’t need a helping hand. They aren’t less capable. They don’t cause problems unless folks go looking to cause issues with them. Yes, there are individual exceptions. But the keyword is “exception,” as in outside the norm and that’s true of any group of any reasonable size. 

Women should be evaluated based on their ability to do the work. And they should be compensated properly for that ability. And they should be treated properly as valuable coworkers who help us make stuff happen. They don’t want anything more than these things. It’s not hard to do these things. We only hurt ourselves and deny ourselves opportunities when we don’t do these things.

That’s what some gamers learned after giving that young, female DM a chance. At first, these gamers were skeptical. But they had signed up for those slots and wanted to play, so they did. And they soon realized she had developed the skills to be a good DM. They had fun. Difficult players were managed. The modules were moderated to be just the right challenge level and kept at the right pace. And they left with more stories about their characters and new found friends at the gaming table. They gave her a chance to compete fairly and she won them over. That’s how it is supposed to be for women in our career field, too. 

DevOps Does Not Make Admins Obsolete

As a follow up to my tweet, I stand by my belief that DevOps does not make administrators obsolete. I include Database Administrators in my statement. The core point of embracing DevOps is to determine what is repeatable and see if you can automate it. Why?

  • You’re trying to move faster.
  • You’re trying to reduce mistakes due to human error.
  • You’re trying to free up time of knowledge workers to work on more important things.

Let’s look at the DBA. Every time a DBA has to manually run a script, what is the DBA not doing? The DBA isn’t monitoring performance. The DBA isn’t checking code to see if it can be improved. A DBA isn’t reviewing audit exceptions that have hopefully been reported by an automated check. Think about the typical tasks a DBA has to do every time a new script is ready for modifying the database:

  1. Check out the new script from source control.
  2. Back up the database (possibly).
  3. Execute the script.
  4. Verify the results of the script.
  5. Report back that the script has been run.
  6. Back up the database again (possibly).

These steps, in and of themselves, aren’t hard. We expect a DBA to bring a professional eye to minimize mistakes, but mistakes do still happen (guilty as charged). What if all of that was automated? Then the DBA wouldn’t have to spend the time running through each step. As a result, the DBA is free to do so much more. The DBA can become a key player rather than someone who just executes code. That means a DBA has more time to show his or her importance to the organization. We talk about career security. Becoming a stronger knowledge worker helps move us towards that.

Which is why I say DevOps doesn’t make admins obsolete. It makes the ones who embrace it for what it is potentially more valuable to their current and future organizations.

BK’s Professional Learning Plans for 2018 #tsql2sday

With 2018 coming, I’ve thought about the question, “What do I want to be when I grow up?” I ask this question every few years because it helps me develop a plan of attack with respect to learning and opportunities to pursue. As a result, this T-SQL Tuesday topic comes at exactly the right time.

Back on the Certification Train – IT Architecture

I maintain some legacy certifications, MCSE (NT 4 – yeah, I’m a grey beard) and Security+, and I have an on-going certification, CISA, that requires continuing education credit renewal. However, I’ve not working on any certifications in a while now. Within the IT architecture realm there are several certifications that are out there and they’re becoming more well known in the industry. So one of my focal areas will be preparing for those certifications.

However, there’s a difference between pursuing certifications to get the credentials and preparing for certifications to ensure you have the knowledge those certs are supposed to represent. I’ve always been a believer in the latter category and I tend to “over prepare” for the test because I care about the knowledge. I know this is the right way to go, so there’s a lot in this area alone I’ll need to work on. As with any infrastructure architect, I have areas of deep knowledge in particular segments of IT, however, it will be good to go back and fill in gaps and strengthen areas where I don’t know as much because it’s not an area I work with regularly.

Data Science

I was a physics and mathematics major as an undergraduate at The Citadel, the Military College of South Carolina. Before that, I went to a specialized magnet school for science and mathematics for high school, a school consider a “super school” here in the United States. As a result, the fundamentals of data science are something I’ve been working with for a long time, just not specific to business. You don’t face performing aerodynamic testing (high school) or trying to solve elemental abundance / nucleosynthesis questions (college) without having to do data science. We just didn’t call it data science. We considered a part of proper research. However, as a “separate” discipline, data science is an area I’ve always loved. Looking at data, understanding what it’s trying to tell us, and figuring out the patterns in it – those are things I’ve always loved doing. So naturally I’ll be working on the Data Science track from Microsoft. I’m about a third of the way done, so I’ve got a lot of work in the coming year.

Cloud Stuff

Not “star stuff,” but cloud stuff (physics pun intended). The majority of my experience has been with on premises solutions. While I understand the cloud solutions at the 10,000 foot level and I have a lot of experience in virtualization specifically along with some experience in Azure, none of it compares with what my on premises skill set looks like. The reality is that cloud isn’t going away, whether we’re talking private or public cloud offerings. Cloud offers the ability to get a jump start on delivering a product. That’s a compelling reason right there to pursue a solution using it for organizations. After all, the usual advice is to either be the first or the best in a space. But the reality is that if you’re first with a great story, it’s harder for anyone else to make a presence. It takes a lot more resources to do so. Therefore, I expect that the cloud trajectory is only going to continue upward.

Don’t get me wrong: there’s still a huge place for on premises solutions. That won’t be going away any time soon. However, most organizations of any size have moved to a hybrid approach. If you’re in the data field and you aren’t prepared or preparing for this, you’re making a huge gamble. Our data skill sets will always be useful. After all, we’re collecting more and more data each and every day. However, being able to apply the skill set to where the new technology is will be a determining factor for career/employment security.



Learning to Give Presentations Well (Part 3)

See Part 1 and Part 2.

Perfect Practice Makes Perfect

I can remember my Air Force ROTC class on communications skills where we had to put together a “talking paper” and give a presentation to the class. We were advised to practice with our peers before the class. Several folks did so, and still did poorly when it came time to give their presentations. Why? It’s because although they practiced, they didn’t practice “perfectly.” Let’s look into what that’s like.

Gather People You Know Will Give You the Truth

If you’re learning to present, you need to know what you’re doing right and what you’re doing wrong. The knowing wrong part is especially important because a lot of times we don’t realize we have a bad habit or issue and it takes someone pointing this out. When we start working with a new speaker in Toastmaster, the mentor should be available to help that person prepare for their icebreaker speech. Part of this is to give feedbackĀ before the actual presentation. Truth be told, some folks need several attempts to practice before they are ready even for that initial speech.

After the initial speech, and after every speech for that matter, in Toastmasters there’s an evaluator assigned. The evaluator talks about the good and the bad. Even great speeches have something about them which the speaker can improve upon. As a result, in good Toastmasters clubs, you’ll hear evaluators say things like, “It’s a great speech for all the reasons I’ve already given. If there is one thing you might be able to improve upon…” Obviously, if a talk needs a lot more than that, the evaluator may remark on a few things, but usually focuses down to one thing to work on for the next speech. When giving this feedback, the evaluator is supposed to be honest, but kind. The criticism is supposed to be constructive and encouraging.

If you’re preparing for a presentation, you want the same kind of feedback. Gather folks who will be honest with you, but in a constructive way. If it takes a few attempts to polish your talk, that’s okay. Listen to the feedback, think about how you might incorporate it, and try again. Each attempt to improve moves you towards that perfect practice.

Practice in Similar Conditions

If you’re giving a talk, practice with the conditions that you expect where you’re giving a talk. Have the lights dimmed. Have the projector going. Make sure someone’s running a clock to keep track of how long or how short your practice session goes. If you make a mistake or have a glitch with the demo, don’t stop unless it’s catastrophic. Instead, recover and continue. After all, such an issue might happen during your actual talk. Plan to have time for questions. Your “test viewers” should expect to give you a few.

Most of All, Practice

If you want to give a solid presentation, you have to practice your talk. I had a lot of experience talking and presenting. I was a drug/alcohol prevention specialist in college, I gave briefings to colonels and senior federal civilians my whole time in the Air Force, and I had taught Sunday school and led children’s ministry programs for years before I ever gave my first technical presentation at SQL Saturday Jacksonville. However, that first session I ran out of time. I was rushing the last part of my talk and there was no time for questions. Even though I was a practiced speaker, I wasn’t a practiced technical presenter. I learned from that experience and became a better presenter. However, I still attempt to practice, at least solo, before I give any talk. You’ll find the best speakers often practice a lot. That’s part of what makes them the best speakers. Don’t neglect practice!


Register for Red Gate’s SQL in the City

Aunt Kathi. Grant Fritchey. Steve Jones. They’re part of five hours of training on SQL Server performance and DevOps with the database in mind. And it’s free. And it’s on-line. I’m looking forward to this. If you’re not familiar with what I’m talking about, it’s Red Gate’s SQL in the City. When SQL in the City was first envisioned, Red Gate put on sessions at various physical locations. There’s a problem with that: a lot of folks couldn’t make the travel. So now it’s virtual.

So when is it? Wednesday, December 13, 2017. There are two time slots for the event (times in GMT): 11 AM and 6 PM. One of those times will hopefully work for you. Here’s how you get to attend:

Register for Red Gate’s SQL in the City

As a bonus, they’re throwing in Grant’s new eBook on execution plans when it’s released. Again, free.

Previous Older Entries