Am I obligated to share tools I built with my employer? [closed]

Question

I work in a corporate setting and I have put a great deal of work into custom-building specific tools and gathering information which assists me in my job here. I and others have noticed these tools allow me to arrive at accurate conclusions, produce accurate results.

As a result of my self-gathered data and self-built tools, I am able to answer questions with proper information. Technically, all the data by which I arrive at these answers is available to anyone through our proprietary ERP (Enterprise Resource Planning) system.

Am I obligated—or can I be compelled—to share with my employer the tools that I built, or to reveal how I arrived at my conclusions?

I have gathered data X, which allowed me to create query Y, which provides conclusion Z; which is very useful for decision-making.

Am I obligated to explain the steps I took (what data I gathered and how I formulated my query to arrive at the conclusion)? Or is it alright for me to keep my methods to myself, as technically all the data is available in the ERP system, and anyone who was willing to put in the effort I put in could theoretically arrive at the same conclusions?

The workplace environment is quite toxic: I certainly wouldn’t be given credit for sharing my methods, they would merely be appropriated from me, and used by someone else to get the credit.

If I were properly motivated—i.e. incentivized—I would be happy to share what I have built. But the toxic environment precludes this. How can I convey this without angering anyone / making anyone jealous?

Answer 1

If you built these tools at the office, and against existing corporate systems, then they belong to the company. Accept that.

You are worried about getting "credit," which tells me you're part of the toxicity problem, albeit probably a secondary part, and not a "source" of toxicity.

If you're worried about "credit," make a department-wide announcement that you have built these tools, and include your management 2 or 3 layers up. Offer to train your colleagues on it. Kill them with kindness.

Answer 2

Yes, you need to explain your methodology if asked. First because the data and the proprietary tool you are querying belongs to the company not you and second because, you need to make sure your query methodology is correct. No analysis tool should EVER be used without full QA to make sure that it is not misleading. No analysis tool should ever be built to query corporate data without being in source control and available to anyone who might get assigned to work with it. What you have done is very unprofessional.

Third, your attitude is counterproductive. If you want credit, that's fine. Make sure you share the tools in such as way as to get credit. Look at how to do that by reading about office politics. If you are doing data analysis, office politics is a critical part of how you will succeed because you need to convince management to make decisions, you need to know this stuff so that you get the credit you deserve.

Answer 3

As I read my own answer it sounds kind of harsh, but it's reality.

Did you make the tools during working hours?

If I were properly motivated—i.e. incentivized—I would be happy to share what I have built. But the toxic environment precludes this. How can I convey this without angering anyone / making anyone jealous?

The company paying you, and you doing this on company time, was all the motivation you needed.

Am I obligated—or can I be compelled—to share with my employer the tools that I built, or to reveal how I arrived at my conclusions?

How does not having a job anymore sound? Without explanation your conclusions are worthless, and if so you've been spending time on something which has so far gained no worth to the company, i.e. you've wasted company time. Something I'm sure they didn't hire you for.

Am I obligated to explain the steps I took (what data I gathered and how I formulated my query to arrive at the conclusion)? Or is it alright for me to keep my methods to myself, as technically all the data is available in the ERP system, and anyone who was willing to put in the effort I put in could theoretically arrive at the same conclusions?

That comes down to what's in your contract, but most likely. The company hires you to both come to these conclusions and explain how you did so. The company most likely literally owns everything you do/work on during work hours. Even universities own what students create while they study there.

Answer 4

First and foremost, check your employment agreement. This is primarily a legal question, and I'm not qualified to give legal advice, but neither is anybody else here without knowing more details of your work and employment. My only advice for you is that I would tread very carefully, and that generally, at the very least, it's likely that if they paid you to do the work, they own the product of that. But again--IANAL (I am not a lawyer) and it is HIGHLY dependent on your contract.

Answer 5

People have mentioned IP rights, and I really do not disagree with them. You, absolutely cannot, under no condition, turn around to a competitor and sell them whatever you developed.

Having said that, you don't seem to be asking about this at all.

Part of the reality of being a programmer, is that it is one thing to create tools for yourself. It is very different to create tools for someone else. You can tell them you made the tools, and you must give them the source code (they own it), but if they want you to somehow get it to work for someone else, that takes it to a whole different level of responsibility and some type of promotion-like discussion should happen.

You're worried about not getting credit. You seem to think that access to source code means they will then be able to re-create exactly what you can do. While technically true, reverse engineering code is not a trivial task. If they're not self-motivated and skilled enough to create these tools in the first place, understanding someone else's code is going to be much harder, because it will cater to your specific style and methods.

The fact is, it is perfectly safe for you to do exactly what you fear. It's OK to explain your methodologies. It's actually OK to even give out the source code. If it doesn't work for someone else, it isn't your responsibility. If the company wants you to have this responsibility, they need to promote you to do that. If they want to fire you, then that becomes a different discussion, one which you actually have a lot of leverage.

Answer 6

By not telling people, you are making a mistake. Regardless of how toxic an environment, you are either someone who is a benefit to the company or someone who is not. An entirely new position could be created for you. Wouldn't you rather be the person who creates tools for others to use or just another one of the "grunts" doing the same thing over and over?

Encourage others to use the tools. Make yourself known as the person who goes beyond their job to benefit the company. This is an opportunity to leverage your talent. If there is a lay-off of some sort, you would be someone they want to keep; especially, the person (probably higher up) who took credit for your work. They will probably want you to do more of it especially if they are this greedy.

Also, this is something you want to put on your C.V.

Remember, if your boss can't get promoted, you probably won't get promoted.

Edit: Whether it's the tools or the methodology, it's no different. They should still want you to come up with more of it in the future. If not, you need to find a better group of people to work with.

Answer 7

Am I obligated to explain the steps I took (what data I gathered and how I formulated my query to arrive at the conclusion)?

The answer varies company to company depending on the agreements that you may have signed.

For example: IF you signed a form stating, "anything you create on company time is the property of the company" this doesn't necessarily mean that the thought processes belong to the company just the result or physical / virtual property.

As you mentioned the environment is toxic and there could be push back towards this attitude and therefore it's important to have the facts regarding the policies of the company prior to engaging in a discussion about this topic.

Answer 8

It is hard to acquire nice TEM image but it is extremely hard to interpret a TEM image. First you have to have a TEM microscope, second you have to know how to operate it and last, you must know what the image means.

Your case is quite simillar to me. You have built a set of tools - a microscope - but still to get results Your expertise is mandatory. Sharing the microscope won't make anyone able put you aside, they can get same images as you, but they won't be able to conclude anything from it.

You are obligated to explain how it works to your superiors to check whether it works properly.

Maybe it is a matter of the toxicity of the environment.
If any from your peers are about to claim credit for it, make your tool a tight blackbox, go to your boss and show them how it works and why it works. Then the L.Arryn-toolbox may be deployed as a tool to work with. Or there will be a document describing the workflow to be kept from now on creditting you as well.
If you are concerned your boss will take the credit "stealing" the idea from you, you can go higher. But if it is that toxic, asy my colleague told me jokingly, go update your LinkedIn profile.

Taking the issue from different point of view the most valuable "thing" here is finding out, how the tool shall work and making it work. The tool itself is a cheap byproduct and the credit for it is just five-minute-fame thing. in other words, the most valuable "thing" is allready yours and nobody can take it from you.

Answer 9

It would seem you would need to provide the actual tool(s) themselves or acces to the system to be able to use them (aka on a sharepoint sure, etc). As far as being required to proved a manual or guide on HOW to use them is different. As long as you let them have access to whatever you made that’s on there system or computers, your fine, as they can’t force you to sit there and train them on how to use it. You would likely need to look for another company if you did that, but it seems that is a good choice based on what you said the environment is like.

Unless it’s some sort of time machine, I’m sure they can figure it out at some point. If not, then that would be another red flag of the culture there.

Answer 10

Check your offer letter and if you signed an "Employee Invention Assignment and Confidentiality Agreement" or related document which may state that all your work becomes company intellectual property while working on their time, property, and or equipment.

If you didn't sign such an agreement then I suggest legal counsel or talking to your boss and working out an agreement that works for you and getting it in writing.

Employers would be probably be more willing to let you open source tools and libraries if you can convince them that it's better to open it up because the community can provide bug fixes and or catch edge cases that you'd otherwise wouldn't have and that it doesn't expose any critical business logic propriety to the company. But of course it'll just depend on your employer's terms.

Answer 11

If you built the tools while under a contract then it is likely that your employer owns them. Exceptions can exist, for example there are exception in academia in certain legislations where teachers and/or researchers at universities may own the (rights to) result of their work either partially or completely or maybe if you are only hired to do a very specific thing for a company, for example when doing consulting. But most "standard" employments as far as I know (I'm definitely no legal expert) what you produce when under contract becomes your employers.

But... if you built it then it's likely that you are one of the better at knowing how to use it and what to use it for...