Did I overstep my bounds by creating a tool "behind my manager's back", during non-work hours?

Question

Context

I am a software developer in the United States. I work on a very, very small team, and we are in charge of developing and supporting a custom mobile app for one of our company's biggest clients. The app itself has been deployed to the client, and they love it. However, a few times a day, a user will call in/email for some tech support which usually requires a modification to some data on the database. These updates require us to jump onto the client's production server and modify the data manually.

For a vast majority of these requests, we have some stock SQL scripts that we can run to find and update the appropriate data. However, these scripts are prone to errors because there are a lot of manual steps to each script. For example, you have to look up an order number, then look up which statuses are valid for that order type, then update the order to one of those statuses (in several places) - updating to an invalid status causes lots of data corruption down the road... We've had to work extra time more than once to fix typos which have deleted/changed more records than they should have. We had a tool made by my manager which could handle one or two of the more complicated scenarios, but that tool was somewhat tedious to use and didn't handle errors very well. (My manager admits this himself.)

To remedy this, I thought it would be nice to automate the process. So, during my own free time on weekends, I put together a new tool using some pieces of the old one as a base. Using the example above, the tool would allow us to to select an order and then simply pick a status. The tool would handle finding valid statuses, and does all the verification "behind the scenes".

The new tool has many more features and options available. In addition to being a lot more error-proof, it also logs all actions performed, so in case we accidentally modify data that shouldn't have been changed, it's easy to look it up and change it back. I specifically designed it to be easy to use so that if our team ever hired a new person, it would be very simple to train them to take care of our most basic support requests.

Some details that may matter:

• To verify the tool actually worked correctly, I tested it on our internal development system, which is the standard procedure at our company for all applications we develop. I only did this at the end of my work day, after I had finished my actual assigned work for the day. No "company time" was wasted on this project.
• Our databases are easily restored from backups, so if I had accidentally destroyed data (which isn't very likely to begin with, but still), it would not have been a major problem. In fact, it's something I could have done myself if need be.
• I did NOT use the new tool on the client's production server, and was not planning on doing so until I had my manager's approval - even if that meant I was told not to use it at all.
• It was always my intention to tell my manager about the tool once it was finished. I told him a little earlier due to the news of a new hire.

The Conflict

As it turns out, my manager recently let me know we were indeed going to be hiring a new developer soon. Figuring this would be a good time to show him my progress, I showed him the capabilities of this new tool. His reaction was not quite what I expected. Though he was impressed at how robust and versatile the tool was, and even stated that he would be glad to replace the old tool with my updated version, he also expressed some disappointment that I hadn't told him about the project much sooner. He said that it was unproductive for me to work on it without his approval since he might not have approved of this work. He has explicitly asked me not to work on any "extra" projects on my own time anymore, unless I talk with him first. Though he didn't come right out and say it, I got the impression that he felt I had undermined his role as manager.

I honestly did not consider this perspective while I creating the tool, but now I completely understand his position. Perhaps I was looking at this project with childish naivete, hoping to surprise my manager with a "gift" that would make our jobs a little easier. Obviously that didn't pan out. I'm now worried that despite my best intentions, I overstepped my bounds as an employee. Did I? What would be an appropriate course of action at this point?

Answer 1

It sounds like you did a really good job of making the tool versatile, but talking about it to your manager at an earlier stage would've allowed him some input on the design, and he could've added some thoughts that you might not have considered. He may also have known some factors that you didn't, such as they were planning to replace the whole system in 2 months anyway, or the work you've done was actually in their plan to be done officially in work-time next quarter.

Of more concern, testing on the company internal servers, even outside hours may have caused problems. At that point you were affecting the company, without telling your manager about it. What if there was someone else supposed to be working on it at that time who didn't understand why you were changing data. Or what if another manager had seen you were accessing the database late and asked your manager about it. He would've been caught unaware which can be embarrassing.
You said "Our databases are easily restored from backups, so if I had accidentally destroyed data (which isn't very likely to begin with, but still), it would not have been a major problem." But your manager having to explain to people why the database was destroyed & having to be restored from backups could've been major.

Don't worry too much about it now it sounds like things are okay, just learn from the mistake and discuss your next idea with your manager. He might even be able to authorize the next tool to be done on company time if you can show him the benefits.

Answer 2

Yes, you overstepped your bounds here.

The issue is not that you did work on your own time: as developers this is a very common thing that we work at home, late at night, who knows. It's part of the job.

The issue is not that you made a tool that will help your job. As developers, this is also very common: as an extreme example, people contribute to Firefox, Git, even Linux, on their own time, and in many cases those contributions help them in their own jobs, and are often the rationale for them doing the work.

The issue is that you did something that could reasonably be considered part of your job. You used company code, presumably company hardware, and did something that you could just as well have done during work hours. Had you done this during work hours, in the normal development process, you would probably have been commended for doing it.

Instead, you did something that's pretty common for newer developers to do. I did it, too, once. I'd bet most of us do it - once, hopefully.

What this looks like, is that you think you know what you should be doing better than your manager, and your team. You said, "I think this process is bad", and decided to fix it. You're probably right - it probably is bad - but that's not your call: it's up to your manager, and your team.

The fact that you used your own time does not matter here. You showed disrespect to your manager and your team, because you didn't follow the process.

The good news is that this isn't a big deal in the long term, if you handle it well. If you make it clear that you understand why you messed up, and that you understand that it's not okay to do this sort of thing even if you think you're right - and you stay away from saying things like "I was right to do it, but wrong to do it behind your back", which sounds like you don't really understand.

Answer 3

What to do now: nothing in particular. You haven't damaged your relationship with your boss, and anything other than that is his job to fix.

But working for the company off the clock (on your own time) may, depending on your contract and local laws, be a problem. In the US unpaid overtime can result in heavy fines and possible criminal charges for the company/manager.

By mentioning your plans to your manager, you would have given him the opportunity to weigh in both on what needed to be done as well as whether it was allowable or not. Possibly he would have preferred to have you do this work as regular overtime hours.

For the future, just run it by him before starting.

Answer 4

Top answers does not apply to this because this is a small company, these don't work the same as big ones. In small companies developers have access to many roles and there's nothing wrong with working on personal projects after work hours.

What happened here is that you made your manager feel inferior and that's always troublesome. You should have included him in this from the beginning but perhaps you didn't know the tool would be so useful. Anyways I suggest you not to use it or talk about it for a while let things cool down and stick to your manager process

Answer 5

It's always a mistake to do work that you're not contracted to do for a number of reasons:

1. You're not being paid for it. Why do work for which you're not being paid?
2. By doing uncontracted hours, you're making yourself look more productive than you actually are, which results in data being skewed, which makes estimates harder to do.
3. By doing work that wasn't asked for, you are undermining those whose role it is to do this.
4. If your work is successful, don't expect a promotion, more money, or gratitude.
5. If you break something, you will not be shielded by collective responsibility as you normally would, and the consequences for you could be grave.
6. Your work will still have to go through the standard testing and verification processes, so you might as well have started there to begin with.

Ideas to improve the system are great, but they should always be discussed with the team and/or your manager beforehand and a ticket raised so the job can be done as part of the team's official work stream.

Answer 6

No. Your time is your time, their time is theirs. As long as you're doing it outside of work hours (not even "when I'm not busy", but strictly off-hours) then it's your project and your time. Jobs do not own you, they're a place that pays you for a certain time on the job. I do not consult with my employer if I decide to write a website for a friend (Non-compete being observed), therefore I don't need authorization to work on any project I deem interesting enough to spend my time on it.

The only thing I see wrong is that you used internal company data for your testing. That's their equipment and their data, even if it's test data. Your best bet in this instance would have been to recreate the schema and some other test data locally on your development box and use it to test.

I don't understand the boss' problem here, other than that. Why would anyone be unhappy about a worker who is willing to put in hours of work without hollering about getting paid for it?

Answer 7

To give the manager as much grace as possible (assuming he isn't just being an asshat for feeling undermined by a junior), consider if he did the opposite: you come in with a nifty gadget that you designed, built, and tested without any feedback, and tried it out on the internal servers. And it worked really well! Great job, you!

So you do it again, and that one goes great as well...

And you do it again, and that one you just needed to quickly test on the client server, just to-

Whoops.

---

Alternatively, you come in, having spent a bunch of your personal time on something, and your manager has to tell you "actually, that was a complete waste of your time, and you aren't being paid for it, and it's your fault because you did it by yourself."

---

Communication is key. In a corporate environment, there is no such thing as a good surprise. There is no need to keep something a secret for a big reveal. If I was a manager and one of my underlings did something like this on their own personal time for work, I'd just say "hey, great job, next time please tell me about it, and then go ahead if it's a really good idea."

I totally get wanting to impress your boss with your hard work though, and wanting to show off with a big reveal. The issue is, it's not worth the risk. Maybe the problem was already solved somewhere else. Maybe it's super risky and you probably shouldn't do it! Maybe the whole system is in the process of getting scrapped and upgraded, so all your hard work is pointless. That would be a shame, and something that could be completely solved with a quick chat.