Tuesday, July 5, 2016

My First SQL Job Part 2: Making Sense Out of Chaos

I was way in over my head. That was the bottom line.

My manager had assured me he knew I wasn't very experienced. He assured me that he would teach me what I needed to know for the tasks which lay before me. He also gave me some additional information: He had never done an integration project of this scope and magnitude before. He didn't know what direction to take.

A week into the project my manager told me he didn't have time to teach me. I would have to learn what I needed to know on my own. This caused me a lot of anxiety because I didn't know where to start.

He had told me that he wanted certain views created within SQL to confirm the integrity of the reports that another employee had been running. However, his focus changed quite often. I would find myself on the cusp of completing one of his assignments when he would tell me to stop, and work on another assignment.

I tried to get him to hammer down the priorities he had for me. However, after repeated attempts to get what was important to him conveyed to me I eventually gave up. His priorities changed often, and he didn't know which ones were or weren't important at any given time.

He was under stress from upper management to show progress towards the merger of these two, separate databases, onto Salesforce. He also needed a database created for a department within the company which did salary surveys. Prior to standardizing on SQL this department had used MS Access. After years of use their database was quite large. Many queries were taking literally days to complete!

My anxiety levels went through the roof when he would ask me if I had completed the tasks he had assigned me. I was all over the place. I lacked focus because he didn't particularly give me direction. He also didn't teach me much so I had to learn as I went. So there was this huge learning curve that was just up to me and Google to get over.

I remember that during this time I reached out to my SQL Instructor. I had taken a SQL class for 6 weeks a few months earlier. It focused mostly on certifying for the MCSA in SQL.

I emailed my instructor and briefly explained to him my situation. He told me that what I was describing was Sr. Level work in SQL. He asked what my progress was, and he was shocked at what I had accomplished. He said that I should be proud of myself. (My anxiety had led to feelings of inadequacy. My manager expected high level work from me. I felt that I couldn't deliver to those expectations. My instructor's affirmation helped me a great deal).

Here's something my manager did teach me which was immensely helpful. He had a notebook which had dates, tasks assigned, and the progress made on each task. I had copied what he had for my own notebook format. This was my template of sorts.

I strongly advise anyone in any profession to keep a notebook such as this one. It serves as a journal of sorts. When a manager has asked me what I've accomplished on a particular day, or for a particular week, I can give him facts. I don't have to try and remember what I accomplished a week ago, or two weeks ago. I have it instantly available.

My journal was setup in this way. I'll use a sample entry to show you:

7/5/2016 (Monday)

Had morning meeting with <manager>. We discussed connectors for the SQL Server which would allow us to send data to Salesforce. We need to find a cost effective connector, and test it out thoroughly. I'm to create a very basic SSIS package. The package should be able to convert from an abbreviated state such as 'FL' to the spelled out state. This data should then be written to Salesforce. This is something <manager> wants completed by the end of the business week.

Tasks:
1. Find and test Salesforce connector (Due End of Business Week)
2. Continue work on views
3. Continue documenting SSIS packages in One Note.

As I worked on each task I would jot down my progress, and anything I had learned. As I finished each task I would put a red line through it. I tried to put as much detail in each entry as I could. I also made it a habit to repeat back whatever my manager discussed with me to make sure we were on the same page. I would often follow up with an email for further clarification.

A year later at another job our entire database department was being grilled by a top executive. He didn't feel that we were making much progress with a new online backup system we were testing. Unfortunately, this was due to the fact that the software had some quirks to it. The technical support department for the software had long turnaround times for their support issues. So oftentimes we would have to halt our work until this outside vendor had a solution to our particular issue that week.

In any case, the top executive asked us in frustration, "Just what have you people done this week?" You could see the looks on each face as they tried to remember what they had or hadn't done that week. I opened up my notebook and asked, "Would you like a summary of the week, or would you like to see what tasks were completed on each particular day?"

I said this without disrespect. I've long felt that employers have a right to know just exactly what they're paying you for. This is especially true as a contractor. Some jobs have quantifiable systems. Take a help desk job, for example. You use ticketing software such as Spiceworks. Within that program is quantifiable proof of what you've accomplished.

Not every job is like that. As a database person you don't work within a ticketing system. It depends on your database role. You do have particular tasks that you have to get done, or are working on at the moment. But that information must be conveyed to management. If management doesn't exactly know what you do because they aren't computer people, then you have to have some definite answer for them.

And for non-computer folks you have to have an answer they can understand. They also need to know the importance of the tasks in the context of what the company's particular goals are. The top executive I'm discussing had tasks for us based on what particular goals the company had. It was up to us to "express" these tasks at the SQL level.

I was later told after that meeting with the top executive that I had saved the jobs of the other database staff. By responding with quizzical faces to the question the executive had asked it made it seem that not much was getting done. My response had given him what had been accomplished, what had yet to be accomplished, and why a particular task hadn't been accomplished yet.

No comments:

Post a Comment