As a QA tester for a software suite, I find that I have to install/uninstall builds daily, change system configurations in batches, etc. I find I regularly create .bat's, .vbs's, and .exe's to script actions that I have to repeat regularly with my job. I have a folder of these on my desktop, and use them fairly frequently. I didn't bother with any sort of error handling into them because I didn't have "approval" to write them and wanted to minimize the dev time (most were written in less than 20 minutes), and never expected them to leave my desktop.

The problem is, coworkers have seen me using them, and they would like me to share. If I distribute these utilities, I know that I will suddenly have to support them and anything wrong will be blamed on me, possibly implicating me in damages, and damaging my reputation for something that is really outside of my job description anyway. I'm willing to take the risk of some edge case causing an error condition on my computer (I will probably be able to fix it with little effort), but I'm hesitant to allow that on coworkers computers that I have no control over.

I want to share the tools I developed but I don't have the time or budget to ensure that they're safe for use by colleagues that aren't aware of how they work or what could go wrong.

  • Should I mention the risks and keep these tools to myself?
  • If I want to share them, how do I ensure that they're used with caution and that any problems caused by their use don't reflect on me?
  • Should I make the case for further development of these tools and, if so, how?
  • 5
    @JaneS I'm not so sure. I could just as easily replace the premise with "I found a great new way to skin a cat, but it hasn't been put through peer review, and I can't gaurentee it will work in 100% of cases"
    – Sidney
    Commented Nov 4, 2015 at 21:34
  • 16
    If your employer looks negatively upon you creating things that let you do your job better, faster & more efficiently, you ought to find a new place to work that will appreciate your efforts.
    – alroc
    Commented Nov 4, 2015 at 21:39
  • 6
    Sell the company your toolkit, then everyone wins
    – Kilisi
    Commented Nov 4, 2015 at 21:51
  • 1
    "possibly implicating me in damages". That's complete bull. For starters, you developed these on work time, so you don't own them, your company does. If your coworkers are doing the same job as you, they also have the skills to fix bugs in them. If you want to be proactive, you could suggest to your line manager that you share them and that you want to allow a couple of hours a week for fixing things that people find. No sane manager will knock back someone trying to improve their team's productivity.
    – Graham
    Commented Nov 5, 2015 at 10:45
  • 3
    Voted to reopen. I've retitled this post, reformulated your core question and expanded it with a few other questions to detail what you're trying to accomplish (and avoid this being off-topic as a generic advice question). While this question is (still) not perfect, I frankly don't get why this was closed as company-specific.
    – Lilienthal
    Commented Nov 5, 2015 at 12:08

6 Answers 6


How can I safely share these utilities without putting myself in harms way?

Talk with your manager, and explain your dilemma.

Suggest that you be given permission and time to enhance your utilities so that they are more robust, have a sufficient level of error handling, are well documented, and are well-tested on machines other than yours. Then, you could present the enhanced utilities to the team for their use.

As @cbojar wisely suggests, if your team has an internal tools person or group - you could turn the finished product over to them for continued support.

I was fortunate enough to have a terrific "toolsmith" on my last QA Team. He was a wiz at creating these sorts of tools, tips, and utilities. He shared your concerns, but I urged him share his work with the rest of the team. He eventually did - and everyone benefited. The team became more productive, and the toolsmith got a nicer bonus at the end of the year, and the appreciation of the team.

You might find that your boss would welcome this approach. Or you might find that she/he would rather you not share.

  • 5
    If the OP's company has an internal tools team, they may even be able to hand off maintenance of the scripts to someone else.
    – cbojar
    Commented Nov 4, 2015 at 21:43
  • 1
    Also, don't neglect to QA the tools. Make them a real "product". Not that I've ever had to track down a bug that was in a tool QA was using instead of my package. grumble.
    – ColleenV
    Commented Nov 4, 2015 at 21:56
  • 1
    +1 for manager approval. You'll need higher up backings before you start running off and doing tool testing on your colleague's computers. I was in a similar situation in a call center, and I created tools that provided a huge productivity boost to everyone, but I had to spend time to troubleshoot the tools, and also add in different ways of triggering them since everyone are not me.
    – Nelson
    Commented Nov 5, 2015 at 0:44
  • 1
    If I understood this right, you are suggesting that the OP should take on developing and supporting these tools. That can be a lot of work in itself, and lead to a shift in the type of work he is doing. He may not be willing to do this, not just because of the issue of taking on responsibility, but simply because it's not the kind of work he signed up for. I know I wouldn't want to do it. But then I'm in academia so I don't really know how things work at companies.
    – Szabolcs
    Commented Nov 5, 2015 at 11:01

You are using these tools to make your job easier and your coworkers have seen that. That means they all have a need for it, or are even unhappy with the situation they face at work.

I think you should talk to your team lead or manager about this. Be prepared, show them the benefits of the automated approach and how it frees up time for other things, like actual testing. Then let them decide. A good manager will see how this can increase the efficiency of the team.

If you repeat the same tedious setup process every day and it takes five minutes, then investing 20 minutes to automate it will amortize after less than a week. In fact, it saves an hour of work for a team of five every week. It's also less error-prone if it is automated because you cannot accidentally click the wrong stuff because it's boring time consuming clicking and waiting.

This XKCD comic explains in an easy way when automation of tasks makes sense.

XKCD: is it worth the time?

You can suggest that you can maintain and improve the things for the whole team. Move them from your desktop to a company git and let everyone benefit. That's in the company's interest and your manager will likely be happy to give you time to further improve if properly convinced. Hard facts can go a long way even for the most untechnical manager.


First, creating tools can make you very valuable to your team and employer. You need to gauge the effectiveness of your tools and make your decision based on that. For me, I once developed a reporting system that turned 2 hours of work into 5 seconds of work--and no more missed deadlines.

If you're worried about damaging something, I'd suggest to work that out before releasing anything to your coworkers. You'll need to make this decision after weighing risks.

For me, usually there are little to no risks involved in my scripts and tools. I usually provide them with an AS-IS disclaimer and provide no support. However, it's gotten to the point that I'm formally asked to fix or maintain certain tools that improve workplace productivity.

Finally, if you do have an internal team, it's great to engage them with your work. This can help prevent code rot. In my case, I added a birthday reminder to one of my tools. After getting laid-off and shortly after my next birthday, I was asked to cover for someone on extended leave. I found out, the team maintaining my code had recommended me because they had worked with my code recently.


I think you are making a mountain out of a molehill. Sharing off-the-cuff project specific tools and scripts happens frequently in the development world. Quite frankly, any software developer who isn't often creating their own productivity enhancement "tools" is almost certainly not going to be a very good developer. When developers share these types of tools then everyone knows what they are getting.

What is more likely to happen versus getting blamed is if it turns out that your tool really is useful then the source code/scripts will be added to the software CM system and then the developers will all start adding their desired features. One day your rather mundane tool may blossom into a quite slick application that is a core part of the project's (or even company) development process.

If people ask you to "support" the tools then you just be honest and tell them "I only created the tool for my personal use. I can give you the source code and you can modify it to your liking if it doesn't do what you want". Very simple, you don't end up owning the tools simply because you wrote them and others want to use them.


One way to address the support issue is to make these tools a company-internal open source, peer-supported project. That lets others get involved in fixing the bugs rather than uour having to bear all that burden. Downside is that you'd be giving up some degree of control over the code, and in accepting their fixes you also run the risk of those creating new bugs.... but if you can't confince management to pay you for time spent polishing these tools, this is probably the best way to share both costs and benefits, and it lets you pick other programmers' brains for solutions to tough problems.


As a software developer I too had the same problem. I think there's a very simple and easy way for you to handle this:

Upload your tools, frameworks, utilities to GitHub with an appropriate license. For example I've used the MIT license that has following text:


I cannot give legal advice, so check what license works best for you yourself.

And giving the link to the tool you can specify something like alpha or beta version - that usually gives a pretty good hint that the software can have bugs or missing features.

That should negate any tension in case if your tool doesn't work as intended. At least legally.
If asked to make updates to the tool from a college - tell that you do that in your free time and can't promise any deadlines. If asked from a manager - make a fork and continue the development.

  • 6
    This would likely open you up to intellectual property suites since you created these products on company time. I suggest not following this advice without first speaking with your manager.
    – Brandon
    Commented Nov 5, 2015 at 2:52
  • That should negate any tension in case if your tool doesn't work as intended. At least legally. Are you really worried about the person sitting next to you at work personally suing you for damages because of an implied warranty? That must be a dangerous script. If I could sue for damages every time I observed a software bug, I'd be a wealthy man.
    – Brandon
    Commented Nov 5, 2015 at 2:55
  • 1
    @Brandon You are wrong, if you're going to develop the tool during company time - you're making a fork ( a clone ), from that point onward it's not your copy of code - it's companies copy. And you are wrong again about person next to you suing you - the person next to you would point a finger at you saying the tool caused a problem. The company(!) could sue you for damages. And could doesn't mean will. And you are wrong the third time about script needing to be dangerous - it could be simply a bug that would corrupt the format of a file and thus - a lot of work needing to be remade.
    – test
    Commented Nov 5, 2015 at 3:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .