Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

To the experienced SQL people out there: How are you titled/how do you title yourself? Expand / Collapse
Author
Message
Posted Tuesday, January 29, 2013 10:48 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 21, 2013 10:26 PM
Points: 9, Visits: 57
I'm a programmer. I've been a programmer for about 14 years, starting with C and C++ (games development), then moving into business apps with (of course) VB6 and .NET. For 11 of those 14 years I've been working with SQL, and for the last... let's say... 8 or 9 I've been specializing in SQL. I also think of it as more than a job, one of the reasons I've learned a lot is because I'm one of those people who actually *likes* programming and SQL puzzles and will go and do this kind of thing on the weekend or on holidays just for fun. I'm not a 9-5, clock punching, "just a job" programmer.

At the various placed I've worked I'm generally seen as "the guy who can do your SQL", and there's no doubt that this is my currently most-used knowledge pool. But I also find that I do a lot of other things. Where I work right now my responsibilities are something like...

- DBA: focusing on administration and maintenance of all SQL instances, performance, permissions, disaster recovery, capacity planning and all the usual stuff (this was my original job title here)
- Lead SQL developer: When upper management needs "the hard stuff" done in SQL I get the call, or I am enlisted to help the developer officially assigned to the request. I also, basically, "teach" all of the SSA's here TSQL, database design, optimize their queries and show them how to do the same.
- Application development and design: My current job title is "senior systems analyst". I still jump into C# on occasion, and I still find myself teaching other senior systems analysts how to use C# effectively, especially when it comes to working with data.
- Software architect: I work with the architecture team pretty much daily. The lead architect, the infrastructure manager and myself are the people who generally set the direction of new projects in terms of technology, integration patterns, hardware requirements, and so on.
- Project management: I try to stay away from this, but because there are only a few of us here who know all the projects underway and what they all need, or are currently using in terms of hardware and software resources, I find myself drawn into these kinds of meetings pretty regularly.

So this leaves me with a question: What am I? If I say I'm a "DBA"... well, that seems not to be a good title career-wise here in Australia. It seems to be considered a more junior position than a SSA. If I say "SSA" then that would put me on the same level as the other people here... to whom I am obviously senior in knowledge and experience. It also seems to leave out my most "important" knowledge specialization. If I say I'm an architect it again seems to leave out the fact that I am hands on with SQL every day, C# once a week or so, and am mentoring the other developers daily.

I'm sure there are other people on this site in similar positions in terms of their diverse knowledge and experience due to their interest in technology and programming. So what do you call yourselves? The title of "SSA" seems to leave me off the radar of, say, Microsoft reps when they come in: we just had a technology preview offer which went to the two people I mentioned earlier as well as the apps manager and IT group manager, but I was not on that list. I was forwarded the invitation internally, but things like this make me worry that I'll never be "visible" and that this is severely limiting my career path.

I do tend to "undersell" myself when it comes to salary negotations and so on, something I've only recognized recentl... I always thought that when I worked in a bigger company my level of knowledge would be overshadowed by colleagues, but after 14 years I've finally figured out that maybe I do actually know quite a lot after all. But getting the right title might just be the first step.
Post #1413448
Posted Tuesday, January 29, 2013 11:41 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 2:16 AM
Points: 2,840, Visits: 3,983
This put me on surprise, the guy who is having 14+ exp (i must say pot filled with drinking water) getting confused with his title (which doesnt matter often)
the thing is , when i talk about asian countries (india, china, singapore etc) here we treat(titled) "generalist" who is having good exp in almost every area and small or even mid-size company love hire these kind of fruit.

But when we talk about US/westernb countries they prefer to keep "specialist" in there pool (the person who knows everything about one thing but nothing about anything else ).


-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done
Post #1413465
Posted Tuesday, January 29, 2013 11:46 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, December 17, 2014 2:16 AM
Points: 2,840, Visits: 3,983
Danah (1/29/2013)
I do tend to "undersell" myself when it comes to salary negotations and so on.
totally based on your confidence how you project your self and you experience infront of interviewer (i must be watch my finger carefully as you have almost double of my exp ) , generally when poeple interview guy who is having so much of rich exp they ask about the ideas/appraoches/terminology/architecture etc etc. and i am sure you will be master of it.

We have to often express ourself by "what we have done and what we can do"


-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done
Post #1413467
Posted Wednesday, January 30, 2013 1:47 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, December 15, 2014 2:26 PM
Points: 5,466, Visits: 7,647
Danah (1/29/2013)

- DBA: focusing on administration and maintenance of all SQL instances, performance, permissions, disaster recovery, capacity planning and all the usual stuff (this was my original job title here)
- Lead SQL developer: When upper management needs "the hard stuff" done in SQL I get the call, or I am enlisted to help the developer officially assigned to the request. I also, basically, "teach" all of the SSA's here TSQL, database design, optimize their queries and show them how to do the same.
- Application development and design: My current job title is "senior systems analyst". I still jump into C# on occasion, and I still find myself teaching other senior systems analysts how to use C# effectively, especially when it comes to working with data.
- Software architect: I work with the architecture team pretty much daily. The lead architect, the infrastructure manager and myself are the people who generally set the direction of new projects in terms of technology, integration patterns, hardware requirements, and so on.
- Project management: I try to stay away from this, but because there are only a few of us here who know all the projects underway and what they all need, or are currently using in terms of hardware and software resources, I find myself drawn into these kinds of meetings pretty regularly.


First, I'm American, so my view is biased. Just throwing that out there. I have absolutely no idea how the Australian Tech Market works.

Second, what's an SSA?

Bhuvnesh above called it, for sure. There are a few people out there (you may be one, don't know) that can keep up in multiple facets of the industry with all the new methodologies. In general, though, around here the higher in a single facet you are is how you describe yourself initially. If not, you describe yourself as to where you want to go. Your title doesn't mean much usually here, particularly as a contractor (again, another one of my biases) as your title is assigned by a company and doesn't necessarily describe the skillsets available.

However, if someone with your skill listing (not seeing your resume and brag sheets, of course) attempted to hire on as a SQL Dev here at where I work, my initial reaction would be that you couldn't possibly be well versed in everything you're describing, there just isn't enough time in a day where one actually sleeps and eats as well. I'd expect to be hiring at best a solid Level II SQL Dev, certainly not a data architect.

So, we definately concentrate on specialization here in the states, primarily because of expectations of the catch-all developers. They're fine for smaller or maybe even mid-level shops, but once you get into our big-business, we expect specialization because we expect teams of specialists to handle their particular facet of a project. When it works, it works very well. When it doesn't, it fails spectacularly. Small businesses (and I should clarify, I don't mean the mom and pop grocer on the corner) usually don't have the funding to bring in the five or six specialists needed to properly build a single project as well as others to maintain the infrastructure, so they end up using one person who's strong in some places and weaker in others, depending on where their interests lie and what seems to break the most often. Generalists are seen as newbies, still figuring out where they want to go.

The only place generalists can really shine in the states is at the management level, where they understand enough of the tech from all parties to keep things well oiled and organized, and to make sure goldbrickers can't blow smoke and sunshine. That generality allows them to communicate intelligently with their specialists and help bring all the pieces together.

If there's a name for it besides 'IT Manager', I'm afraid I have no idea what that title would be called. I intended to get to the point eventually, just felt it needed to be approached with my biased reasonings.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1413763
Posted Wednesday, January 30, 2013 4:52 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 21, 2013 10:26 PM
Points: 9, Visits: 57
Thanks for the replies. That's a really discouraging view ;)
"SSA" here stands for "senior systems analyst". At my present company it's stapled to every developer regardless of skill level or specialization.

Titles seem to mean a lot in Australia, because employers use the average salary for a title to figure out what the market rate for a position should be. There's not much room for individual ability.

The company I work for is, IMO, "big enough". Not if you compare it to huge global behemoths of course, but we have 2200 active users on the 550GB primary OLTP database at any one time, clusters and VMs everywhere, dynamix CRM, biztalk, K2, two data warehouses, highly distributed locations and mobile services, patridges in pear trees.

I'd expect to be hiring at best a solid Level II SQL Dev, certainly not a data architect.


I don't know what a "level II SQL Dev" is assumed to know, and it's very difficult for me to try to describe how much I do or don't know, so I'm not sure if it's fair. But level II sounds rather low. As a complete guess I'd expect someone with "level II" knowledge to be able to write their TSQL without needing their hand held. I, on the other hand, am the one in the position of "holding the hand" of other developers who themselves have years of experience, usually (but not always) with respect to anything data-related, and particularly with respect to anything directly in SQL Server.

Is there an implication there that "data architect" is the next step after "DBA"? Because I guide our data architect....

I wouldn't consider myself a generalist, I'd consider myself a SQL specialst who also has a significant amount of past experience with OO languages.
Post #1413796
Posted Wednesday, January 30, 2013 5:37 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, December 15, 2014 2:26 PM
Points: 5,466, Visits: 7,647
Danah (1/30/2013)
Titles seem to mean a lot in Australia, because employers use the average salary for a title to figure out what the market rate for a position should be. There's not much room for individual ability.

They can mean a lot here, depending on who you talk to, but not from a consulting standpoint. There it's "What were you making at your last position?" You pretty much negotiate from there, if you let the company do that to you. I refuse to release that information personally, and base my negotiation around the skillsets required and market.

The company I work for is, IMO, "big enough". Not if you compare it to huge global behemoths of course, but we have 2200 active users on the 550GB primary OLTP database at any one time, clusters and VMs everywhere, dynamix CRM, biztalk, K2, two data warehouses, highly distributed locations and mobile services, patridges in pear trees.

LOL, watch out the partridges don't perch over the rack's air vents, it makes a mess.

Yeah, I'd say you're in at least what I'd consider a middle sized company, if not a large one.

I don't know what a "level II SQL Dev" is assumed to know, and it's very difficult for me to try to describe how much I do or don't know, so I'm not sure if it's fair. But level II sounds rather low. As a complete guess I'd expect someone with "level II" knowledge to be able to write their TSQL without needing their hand held.

Roughly, yes. Not sure if it helps any but I wrote this article a while ago and while there's a bit of disagreement about what a III can be, and if there's higher (check the discussion afterwards) it may be of some help:

http://www.sqlservercentral.com/articles/Career/71608/

I, on the other hand, am the one in the position of "holding the hand" of other developers who themselves have years of experience, usually (but not always) with respect to anything data-related, and particularly with respect to anything directly in SQL Server.

Meanwhile I've met a lot of II's who are good mentors but don't have the incredible depth of knowledge that you'd expect of a III. Most places never need a III, just a good II who can pass along knowledge as required. Again, I don't know you, but speaking in more general terms.

that "data architect" is the next step after "DBA"? Because I guide our data architect....

Data Architect is almost a different skillset entirely, and can depend on who you speak to. An architect in a particular system (say, SQL Server) is different than a classically trained architect who can organize data relationships and lay the groundwork for developers to work from. Most good devs have the basics of a general architect, but may not have all the pieces they need.

I wouldn't consider myself a generalist, I'd consider myself a SQL specialst who also has a significant amount of past experience with OO languages.

Then I'd market yourself as someone with heavy SQL experience who can communicate well with developers, and figure out how to 'title' yourself from there. I've found that being able to 'talk the language' with your front end devs can be a significant selling point in interviews. Also, 'old titles' tend to linger for people when they've advanced in a company far beyond their hiring point. One of the tricks I use on my resume is to list my actual title in small font but highlight what the actual duties were, and what I considered the general position to really encompass. I find it helps to clarify things with future employers, but I make sure I back it up with a few bullet points to confirm the duties.



- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Post #1413805
Posted Wednesday, January 30, 2013 5:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 21, 2013 10:26 PM
Points: 9, Visits: 57
What you've advised tends to line up very well with what I've been thinking. I suppose it all comes down to how and where you actually present yourself, something I'm unfortunately not very good at. I'd rather keep my head buried in a database than go to a "training" course where the training is underwhelming and the networking coffee breaks are the main attraction

Edit: Really nice article by the way, I would say that my responsibilities definitely lie at the level III layer and are split between database architect, administration and development. Mostly architecture and administration, I tend to deflect a lot of the day to day development stuff simply due to lack of time, jumping in for "the important stuff", or when people are getting stuck or things aren't performing as they need to be. I appreciated the article because it was the first time I've seen summaries to which I could point and say "yes, THAT'S what I do!" :)
Post #1413811
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse