Jesse Seymour recently asked this question on Twitter:

This is a GREAT question because many people starting a path in business intelligence, SQL Server, or other technical fields often struggle to figure out what skills are important. Early in my career, I struggled with this too because I simply wasn’t thinking about professional development. I was focused on putting one foot in front of the other, only solving the immediate problems. If I were to begin my career again, here are ten skills I’d start building as soon as possible:

1. Listening for and understanding the desired outcome

The ability to listen is critical.

I repeat: The ability to listen is critical.

Every project, every assignment, every task has a desired outcome. As technology enthusiasts, it’s easy to start mentally sketching blueprints as soon as we hear someone say, “We need a data warehouse in the cloud.” The funny thing is, sometimes that’s not at all what they need — it’s what they imagine they need. What really matters are the requirements and the desired outcome. Maybe what they really want is a lot of historical data with 24/7 uptime, and “the cloud” just sounds like the best approach.

Here’s the catch: right now it’s up to the people above you (senior developers, architects, or managers) to figure out how to pull it off. They understand the technology, the inner workings of your company, the political landscape, etc., much better than you do. Ask what they heard and how they’re translating requirements into a solution. You’ll get valuable insight into the business, established relationships, and why proposed solutions are likely (or unlikely) to work.

Eventually you’ll be asked to do the translating, so start learning how to do that now.

2. Listening for and understanding concerns

In addition to understanding what people want to happen, you must understand what about this outcome worries them. There may be negative consequences associated with this solution, even if it’s successful. For example, implementing a new data warehouse adds new overnight processes, making it more likely a DBA will have to fix it in the middle of the night. Or perhaps launching a new web portal means more openings in the corporate firewall and increased risk of breach. Whatever solution you end up building needs to account for these concerns. Whether they’re legitimate concerns or not, they are real to whoever is expressing them.

3. Understanding how any previous attempts/initiatives failed

The concerns about your solution may be rooted in history. If you’re in an entry-level or junior position, odds are you haven’t been with the company since its inception. Before you arrived, there were other projects — some successful, some not. If the desired outcome has been attempted before, you want to understand why it fell short. By paying attention to what has/hasn’t worked in the past, you’ll learn to match the right solutions to the right problems. Also, if something was such a spectacular disaster that it got people fired…yeah, you want to avoid repeating that mistake.

4. Technical curiosity

There’s a common refrain among the people who rise to the top of their technical field. When they observe a behavior, for example a function returning unexpected results or a report rendering strangely, they wonder why that is. Then they dig in to find out why. They have a scientific curiosity for technology. When Kendra Little introduces herself at a presentation, she often mentions she’s a Microsoft Certified Master, which means she broke SQL Server a lot.

Without technical curiosity, you won’t feel the urge to explore and understand. You won’t spend your spare time reading blogs, building a virtual lab at home, or coming up with your own open-source script to share with the world. Your career ceiling will be lower.

Senior developers and DBAs become senior because they care about why things work. How far you go depends on how much you care.

5. Learning to research efficiently

This is a vital skill, so much so that it’s the basis of the best compliment I ever received in my career. The era of finding what answers you could by scanning a cabinet full of 800-page books is over. (Hey, at least now they’re sold in searchable, portable e-book form.) There’s now an abundance of helpful people on the internet who want to share what they learned in solving a specific problem. By leaning on their experiences, you can reduce a frustrating, days-long quest to fix an error down to a hiccup easily solved before the ten o’clock status meeting.

If you know where and how to look, that is.

The more research you do, the more you learn about which sites and blogs will help you the most and which ones to avoid. You learn what phrasing and keywords get you to the answers you’re most likely seeking. Over time, you learn who is giving you the answers that work. You learn how and where to ask questions that get responses quickly.

An added bonus is that your colleagues will start coming to you for answers, knowing that even if you don’t have the answer, you’ll be the fastest at getting it for them.

6. Self-control to stick to the problem

It’s called “scope creep”. In the consulting world, it’s a reason to say no to adding a feature. In the junior developer world, it’s a reason to say yes. It’s tempting, as you learn new technological tricks, to try integrating them into the project. After all, why not put that new-found knowledge to good use? What you just learned is a shiny object, a squirrel darting in your peripheral vision. You can recommend this new technique or feature be added to the project, but be ready to a) defend it as completely relevant and important and b) have it shot down immediately.

Don’t get discouraged though. It may be the right technology for the wrong project. File it away as something to remember for future projects.

Also, make sure you get approval to explore a new method or feature before diving in. I’ve had a simple chunk of code eat up two weeks of my time just trying to prove it can run before I ever mentioned it to my boss. When I did finally tell him, it was not a fun conversation.

7. Communicating progress clearly

Estimating time is really difficult. One of the most awful questions you can get is, “How many hours do you think it’ll take to complete?”

I hate that question with the fire of a thousand suns.

(I’m not alone in that sentiment.)

It seems especially unfair if you are junior-level because you’ve probably never done this particular thing before. How the hell are you supposed to know how long it’s going to take? Frequently, the last 20% of the work takes 80% of the total time. It’s the nature of software development. You don’t have much control over that.

What you do have control over is communicating your progress. Consistently and clearly state what you’ve done, what has yet to be done, and any anticipated challenges. This demonstrates your willingness to be transparent and held accountable. It also means your boss will be able to better recognize when it’s time to have someone else help you along.

8. Willingness to ask for help

Tenacity and grit are wonderful things. So wonderful that you can grit yourself into being three weeks behind because you just know you’re going to get this feature to work. Be real with yourself. You’re a junior developer or DBA. You’re not going to have all the answers, and you’re not always going to have enough time to find them on your own, either. This is where you can lean on your more experienced colleagues to pull you up. You may be surprised how eager they are to help by explaining a difficult concept, sharing a useful piece of code they keep handy, or offering to help debug your code.

You may not know how to return the favor, but here’s one subtle yet powerful way: let that person’s boss know they helped you. Bosses love when senior staff are willing to teach and mentor others.

9. Willingness to yield for the project’s greater good

You might have to face the fact that the feature or code you’re working on isn’t going to make the cut. Or worse, they want what you’re working on — they just want someone else working on it. If your tasks get cut or reassigned, be a good sport about it. You’re a newbie at this and it’s not about you, it’s about the project’s success. (If this is a continual pattern, however, it’s probably a bad sign that you aren’t trusted to get things done.) Don’t sulk or mentally check out. Instead, gracefully take a back seat, watch and learn, and keep contributing however else you can.

Take heart that this happens to people many years ahead of you, too — senior-level people, even. Rather than delay a project until in-house staff can learn a skill, consultants who already have that skill often swoop in and cover that gap so the project can stay on track. Remember, it’s all about the outcome, and better to be a bit player for a successful project than be the star of a failed one.

10. Entry-level technical skills

The previous nine skills make you good at your job, and able to pivot from one technology to another. This skill set makes you good at doing the work itself.

The proof is out there

Begin investing in these skills now, and like a savings account, the interest will compound. Over the years, you will stand out more from those who chose not to invest. Don’t just take my word for it. The skills listed here will look familiar if you search for SQL Server jobs with the word “senior” in the title. Your skills will match the responsibilities employers are asking for right now. Seriously, these are plucked right out of current job listings for “Senior SQL Server [Something]”:

  • “Work with business users, management, and executives to analyze, define, and document business requirements for the company’s data needs.”
  • “Initiate discussions and advocate for a common approach to data management and data definitions for multiple business areas.”
  • “Coordinate implementations while maintaining a high level of accountability and transparency in order to safeguard the platform and customers.”
  • “Keeps abreast of evolving Database technologies and best practices and recommend improvements as appropriate.”
  • “Ability to manage development resources, assigning and reviewing tasks and providing timely status to management”
  • “Someone who enjoys trying new technologies and techniques, and has experience with high availability and disaster recovery techniques as well.”
  • “Stay current with Microsoft SQL Server tools and technologies.”
  • “Excellent written and verbal communication skills are required as well.”

Note that none of these requirements say anything about a particular version or feature of software. These are the requirements you’ll still see ten years from now. They are evergreen, and always in demand.

Aren’t tech skills important? Yes. Job listings have plenty of technical requirements, too. You want the tech skills to deliver great solutions. But technologies change. People change. You will likely pivot from one technology or product to another at some point in your career. You may get promoted to management and not be a hands-on DBA or developer anymore. These less-technical skills will serve you wherever you go. Your career is an interest-bearing account and the best time to start investing is now.

This post originally appeared at douglane.net.

Categories