What to do if you discover your team is not responsible for what you were hired for [closed]

Question

I got a job to automate processes in a specific field. My background is in process automation.

After I started, I discovered my team is not responsible for the processes or their automation at all. Another team is and whereas the colleagues are friendly and stress that they welcome suggestions, they also make it very clear that they don't need external involvement and don't see it as recommendable for me to take over any of the automation tasks. My team are just users.

It's also clear that everyone involved in my recruitment knew that I wasn't to take care of the processes as this is not what my team does.

Instead, I'm relegated to much more junior tasks: basically, I need to perform the processes manually. I can't automate the process without the other team's involvement since I would need access to systems, which I can only get from them and they made it clear I won't get it.

Could you please tell me what the solution is?

This situation happens to me for the second time in my life. When it happened the first time, I tried to prove to the other team I could contribute - which was definitely the case given I actually had much more technical expertise in the field than they. I tried to make it cooperatively with them. So I spent a year basically trying to make the very territorial colleagues "like me", being totally cooperative but despite that being blamed by them for even proposing any contribution. I was forced to perform simple manual tasks during that year. I never want to experience that again.

Answer 1

Find a replacement job as fast as you can feasibly do so.

The sooner you can do this the better. Don't wait to confirm that your new boss lied to you directly or try to work around the situation because you already know how this will turn out (I might offer different advice if you were a rookie). Start looking now, you can always cancel the search if you find out that you have misunderstood, or that your colleagues in automation have misunderstood.

If you live in a European country and have been placed on a standard probation then I would be inclined to take advantage of the reduced level of notice required during the probation period. Normally I'd suggest that you owe your employer more courtesy than that but under the circumstances I don't think you do.

Answer 2

Your time is your only non-renewable resource. Therefore, it matters whether this employer is wasting it. You have a decision to make, as you know. "Should I stay or should I go?"

You don't have to decide immediately. Promptly is soon enough. In other words this is not an emergency (yet).

One step to take now: Look for other jobs. Having one in hand makes your "go" choice easier when the time comes to choose.

Make sure your supervisor knows you're surprised by the assignments you are getting. Respectfully say you expected to make a contribution to the company's success using your expertise.

Another step: ask the managers who hired you why they hired somebody with your skills if they didn't need them in your department. Approach this, if you can, as a business question. Depersonalize it if you possibly can. They may have some organizational change in mind. If that's true they need to enlist your support and ask for your patience. At least they need to tell you the plan.

As you know, accusing people of lying makes rational conversation harder, even if they did lie to you. So, if possible avoid that while you're gathering information.

Another step. Decide whether this job really is a waste of your time. Are you learning interesting and useful stuff about their business or your specialty? (It's fine if the answer is "no", but it's good to decide this intentionally.)

Another step: If you can, figure out why this happened twice. Is it something about your particular line of work that makes companies hire overqualified people? Is your particular trade plagued by squabbles between departments? If you know why this happens, you'll be better equipped for your next interviews.

In short, keep your options open, decide rationally, and don't let people waste your time. Good luck and strength to you!

Answer 3

Find a way to automate your department’s processes without the involvement of the other department.

You weren’t hired to play politics, you were hired to automate processes. If the other department isn’t willing to cooperate, then do it without them. If they control the business’s computing or data storage assets, for instance, consider putting it on the cloud. If they control your organisation’s database, and just give you access to a web interface, then build a program that can automatically strip information from those web pages - and maybe even use that information to build a database of your own.

Obviously, any actions you take should have the backing of your manager, however; that way, if the other department pushes back, you can just point at your manager and say “I was just doing my job”. If you have a good manager, they should be happy to go to bat for you because you’re saving the organisation money by improving the efficiency and thus productivity of your department. Removing roadblocks that prevent their employees from doing their jobs is literally a manager's job, and if the other department are making themselves into roadblocks, then it's up to you and your manager to find a way to work around them.

Answer 4

The subject that you need to be studying is "Automated vs. Manual User Testing".

I know you aren't interested in testing the roadblock team's interfaces, but the techniques used (to automate the testing of interfaces intended to be used manually) can also be used to extract the data you need from that kind of interface.

You should write a wrapper, or layer, or whatever you want to call it, that extracts your required data from whatever they send you, and adds your required input into whatever forms or pages they require you to return. The side of this wrapper that faces your process automation should look like a sensible API.

Make it a separate wrapper instead of baking it into your automation, because the roadblock team can change their interface on a whim. You want your response to such changes to be all in one place.

Keep careful separate track of the time you spend writing this wrapper, and especially the time you spend maintaining it. Once you have some useful process automation running in your department, you can report what fraction of your development cost was attributable to the other team's obduracy. Your department can then use this number to convince higher management that the roadblock team should be more cooperative.

If the roadblock team should ever offer a more tractable interface, you will discover another reason for confining your interface translation code to a separate wrapper: you can now remove it.