My tasks at work have turned away from what I applied to. How do I get back on track?

Question

I started at this company in the Netherlands a bit over a year ago as a C# coder. It's my second job now, after quitting from a job of 3 years also as C# coder.

As I got interviewed for the current job, I was told it would be an all C# project with some small side tasks. This seemed perfect for me, I wanted to do C# most of the time but don't mind a small side task in another program as a change. As I officially started the job, things moved pretty slowly. Already 3 weeks later I (and some other people in the team) had to fill our time with self-made tasks because the project wasn't starting at all. Another team (Database stuff) had it busier and I was asked if I could lend them a hand because I also had SQL knowledge. As I had no other things to do, I just agreed.

Now over a year later I have basically become a SQL guy (within the C# team) with some C# tasks on the side. Not what I was hoping for when I started this job, and I can say I have gotten really tired of it. I told this to my Teamleader months ago and he said he would get me some more C# tasks instead, but that never happened. If anything, he still sees me as the SQL guy and tells people about how they need to ask me if there are SQL issues. I went to talk with the manager as well, but same story there.

Now I wonder how I can get out of this SQL loop and return to my original job? I have the feeling my position got rooted too deep into the company that I have no other option but to quit?

PS: no offense to SQL people. It's just not my thing.

Answer 1

Before you throw in the towel, there is no harm in being be more assertive in your discussions.

1. Bring it up in EVERY one-on-one meeting. Make it #1 item on the agenda for every meeting

2. Ask for some level of commitment from management and/or team lead. Don't make it "negotiable". Instead describe it as a future state. "I was hired as a C# programmer and that's what I want to be. I'm happy to help out with the SQL need temporarily but it's NOT my long term goal. I want to create a transition plan that gets me back into 90%+ C# work. Will you support this effort? "

3. Focus on quantitative metrics and actionable items. "Let's create a transition plan with a timeline and specific actions". "My transition metric is hours spent on SQL vs C#, I want to track this going forward and set realistic goals with you" "I'm happy to help interviewing and hiring an SQL expert"

At the least, that conveys that you are dead serious about this and that you mean business and can't be easily brushed off. It is also still constructive and collaborative. Then start tracking your metric and share it with your management during each 1:1. If there is decent progress, things are good. If not, you have tried your best and you got "no" for an answer, so then it's time to move on.

Answer 2

You have two options: accept the reality or move on.

The business needs SQL work, not C#. Since they are paying you, and you seem capable, they will ask you to fulfill the need they have. When you go to a store, and are looking to buy apples, no incentive will get you to buy kitty litter (if you don't own a cat).

On the plus side, you did pick up a additional skill that may help you land your next role.

Answer 3

I got stuck in a similar situation, although more slowly and I was in even deeper by the time I realized how stuck I was. I was able to get out while staying at the same job, but it was pretty touch-and-go at some points.

From my experience, developers are fairly dismissive of SQL skills (at least, when hiring). The general sentiment seems to be that any developer can figure out SQL*. At the same time, you're unlikely to learn the rest of being a DBA from this (even besides the fact that you don't want to do SQL stuff). And your core developer skills can rust pretty quickly from disuse.

You do have to be willing to leave. From the business perspective it goes something like this: You doing SQL stuff > you doing C# stuff > you leaving. They will only take the second option if you remove the first option entirely. Learn from my mistakes and don't wait until you're entirely fed up with the situation for that to happen.

As long as you are willing to leave, though, you actually have a pretty strong negotiating position...because where else are they going to find someone to hire who is a known good quantity and already knows all of their stuff? And any loss of productivity due to rearranging the team is going to be less than the hit they would take if you walked.

What happened for me was to spread all the stuff I was doing back out onto the whole team. None of the stuff I was doing was that super special that no other developer could do it, and frankly having it siloed in one person was just dumb anyway (what if I threw myself under a bus?). That none of the other developers wanted to do it either was tough for them (not my problem).

I had to be mean for a while about protecting my boundaries. It was very easy for people to slide back into giving me certain kinds of work, and I had to be really firm about taking my share of day-to-day stuff and not even a little bit more than that**. Even when it involved flatly saying No in semi-public (in front of the rest of the team). (Including one incident which involved being called in to explain myself later--although since I had the three e-mails where I'd politely tried to work it out with that person in private before it all came out in public, it turned out OK for me.)

So polish up your resume and look at a few job postings, and go talk to your manager after you have it solidly in your mind that you can leave at any point. You don't have to tell your manager that you can leave, but if you're comfortable with the idea it will definitely come across. Explain that you need to start working on C# stuff, now. Explain that the SQL stuff can be spread out over the whole team, they are all developers, too! Talk about the benefits of removing knowledge silos and bus numbers. And then when work is being split up, speak up aggressively about taking some C# tasks. Relate any day-to-day SQL task that comes up to the skills of your other coworkers ("so-and-so knows that area really well") and brick wall anyone who hints that you might take that task.

Or, honestly, just leave--I'm still not sure all of this was worth it, except that it was a really bad (pandemic) time to leave when I got to the point where I was ready to.

* "Any developer can figure out SQL" is not wrong, exactly, but mostly because a lot of development only uses "hello world" level SQL. (You'll notice a lot of libraries exist to remove developers from actually having to understand the database.) I'm still not an expert, but at least I know that the DBAs are doing something besides twiddling their thumbs all day.

** Actual emergencies always got to the best person. I tried to emphasize that I was completely reasonable about that, although I'm not sure that it really helped--especially since the people who were most annoyed with me were the people who'd been successfully avoiding the **** work all this time.

Answer 4

Remind your team lead regularly that you are unhappy. Your manager too, if they're different people. Emphasise that it's perfectly reasonable for you to be unhappy in this situation, because you were hired as a C# developer with the understanding that you would be writing C#, which is something that makes you happy, but now you are spending most of your time writing something else, and while it's great that it helps the company, it doesn't make you happy.

But also, recognize that it might not be possible to switch back to C#. They might have overestimated how many C# developers they needed and underestimated how many SQL people they needed. Business conditions change constantly.

So your team lead might not be able to do anything about it. But at least they will be aware you are unhappy. If something else comes up that needs doing and is not SQL, they might think of you first.

Answer 5

When you don't want to be the SQL guy, make more SQL guys.

You have a reputation as the local SQL guru, so all SQL tasks go to you by default. That's because people assume (rightfully or wrongly) that you are the only one who can take care of them. When you don't want to do that, then propose that you could train a couple of your colleagues how to write SQL queries, so you can deflect future tasks to them.

I've used that method several times in the past to get rid of workloads I accidentally got responsible for because I was the one guy with the unique knowledge.

Answer 6

Now I wonder how I can get out of this SQL loop and return to my original job?

The answer is you can't. The company has to decide that they want you back doing C# work.

It's normal for companies to have a clause in a contract that says any other duties so you can't claim it's not in your employment contract.

I've heard this from a lot of people of the years as a reason they are moving company so I'm afraid if you've asked to be doing more C# work and they haven't capitulated then I think you will need to look for another job.

Answer 7

In a healthy work environment, your manager is not just responsible for making sure you are getting your work done and giving you performance reviews, they are also responsible for helping resolve issues that interfere with your productivity or might cause you to want to leave the company.

You should discuss the situation with your manager and ask for their help. Your tech lead is not responsible for your job satisfaction. Their obligation is getting the work done within the parameters set by management, and if making you do all the SQL work is the most effective way to do that, it will be difficult to get them to choose a different path. You need the support of your manager to resolve the situation in a way other than "suck it up or quit". They can free time for you to train a coworker and can work with the tech lead to get you involved in more C# work.

At my first "real" job, I was "the queen of (a compression algorithm acronym)". All of my time was spent on that one project and I was never given the opportunity to work on anything else because I was the only person who had the expertise to do it. I went to my management and explained that not only was that a huge risk for the company, it was making me really unhappy. As a result, I was given time to train someone else to do the work and management tried to find other interesting stuff for me to work on, but failed. I ended up moving to a different department in the same company. If I hadn't had a trained replacement, it would have been unlikely that the company would have let me transfer to a different department, so even though I didn't get exactly what I wanted, it helped to get my manager involved. I was able to do what was best for my career without burning too many bridges.

Answer 8

Tell somebody relevant that currently, your team is moving towards a dangerous situation - creating what in my last job, we called a "lone peak of skill". Ideally, somebody relevant will be an agile coach, because agile coaches are trained to recognize the danger in this, and it is their job to prevent it. If you don't have an agile coach, the next choices would be, in that order: scrum master, team lead, or the manager to whom you report. That supposes that your company is more or less following the traditional definition of these roles - you may have to change your choice depending on who you think will grasp the situation, and will react with understanding on the human level too.

The reason why this is a better approach is that it makes them aware that the team has a problem, and through that, the company. As you will be talking to somebody responsible for the team, it makes it a problem they are responsible for. This is directly opposed to the way you have presented it until now - that it is you who has a problem related to personal preferences. There is a tacit understanding that it is management's responsibility to recognize and define the tasks which need to be done for the business to move ahead, and it is the specialists' responsibility to get these tasks done. The current top answers reflect how most people (especially most managers) see this cultural norm. Being choosy is allowed to some extent, but can quickly win you a reputation of being unprofessional. If a manager promises you to try to get you more enjoyable tasks, this is seen as a courtesy, and has lower priority than the current business goals.

If you, or your somebody relevant is not recognizing the problem for the company: a skill being concentrated in a single person is very efficient in the short-term and very damaging in the long term. There is not only the famous bus factor, but also more subtle effects like you not being flexibly available for that new project they wanted you for, because you are stuck maintaining all the company's SQL, and the juniors never gaining any experience, because they stay firmly in their comfort zone.

That state is not only problematic for the company/team, it is also a state that is a natural attractor for teams. It starts out innocently, with somebody getting slightly more knowledge about something than the other team members (if it is not a language, then it is a subsystem, usually one that person wrote first), and then all tasks about it being left to that team member, because they know more about it than the others. In the worst case, it is not just the others being unwilling to jump the hurdle of "I don't know how to do this yet", it is the experienced person not having the didactic fortitude to let them blunder their way to expertise, instead taking it out of their hands and saying "let me show you how it is done". And because it happens on its own, it is somebody's - ideally an agile coach's - job to actively steer the team to a different state, in which expertise is shared, and nobody has (or is allowed to use) the excuse of "but Hunkabonk is so much better at it than me".

In a perfect company, somebody relevant will listen to you, recognize the problem, and take measures to counteract it. It will not result in you never doing any SQL, but rather, in both the SQL tasks and the C# tasks being equally distributed among the team, which will hopefully make you happy (it may turn out that what bothers you is not the hours you are doing SQL - which will be reduced - but the unfairness of you being the only one who has to, or the feeling that you complained and were not heard). In just about any real-life company, you may encounter anything on the spectrum from the perfect company's reaction, to a blank "I don't understand, it's great that you are growing to be an SQL experts, so there is no problem." From there, it depends on your particular circumstances to recognize whether there is hope for the situation to change, or if you have to fall back on Pete B.'s answer.

Answer 9

I assume that you understood the job description correctly on day 1. The fact that they have assigned you different types of work from the initial agreement could be due to one of the following:

• They were being dishonest or imprecise about the content of the work because they desperately needed someone with your background
• They hired you with the prospects of winning projects in C# and assigning you C# work, but then those proposals fell through. When this happened they were left scrambling and decided to just assign you what's available (in this case SQL work).

Either way, you cannot force them to give you C# work. But I understand your frustration and feeling that you have been somehow tricked into this. I would first bring this up to your supervisor and explain the situation. Explain that SQL work was not your ambition coming into this position, and be as honest/blunt as possible about your feelings. Do not jeopardize your relationship with your supervisor.

No matter what they say, even if they promise you more C# work down the line, just go ahead and apply to new jobs which focus on C#. You cannot give them the benefit of the doubt anymore, as they have already shown you that they are capable of saying something and doing something else.

Keep in mind, no matter how stable this seems now, this situation could potentially deteriorate. You are being forced to do work that you're not interested in, and that can have negative consequences down the line. Get out of there as soon as possible, and find an employer who can honor the agreements they make with their employees.

Answer 10

Turn SQL into C#

A SQL job doesn't necessarily have to involve writing SQL commands. Use a C# library that will allow you to abstractify SQL tables as C# classes and SQL rows as C# instances. Then do all your SQL work using this C# API. Or if a library doesn't already exist that suits your needs, you might be able to write one that does.

Answer 11

Be a primadonna :)

Situation in your company (or at least in your team) looks like this : lots of C# developers (no offense, but language is in a decline) and one SQL guy - you! Now, people may say whatever they want about SQL, but it simply could not go away because relational bases are not going away. This gives you one huge advantage over rest of the team - you are rare, they are not.

As such, instead of asking for more C# tasks, you should actually decline them, saying you are busy with SQL. Also, be bold, ask for a raise, better computer, flexible work hours (if working in office, considering COVID-19 situation) , company car, parking space, whatever ... You need to create the felling that doing SQL is a job for a specialist (highly-paid), and C# is something mundane for junior developers.

Company could respond in three ways:

1. They could fire you. This of course depends on your contract and local laws in Netherland, but you should be prepared for such outcome in any job negotiations.

2. They could try to threaten you, to underrate you and SQL in general. In this case you should stay firm, and respond with "do it yourself if you think it's easy". In the end, they would have to share SQL load among other developers, to show you are not special, and you would get more C# and less SQL work (and this is what you wanted, right ? :) )

3. They could actually meet you demands :) In this case, enjoy in your newly won perks until they find another SQL developer in which case you will find yourself either in point 1. or point 2.

There is of course this outlandish advice to simply find better company with the work more suited to your wishes, but I think this is safe to ignore :)