13

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?

  • Comments are not for extended discussion; this conversation has been moved to chat. – Jane S Oct 13 '17 at 13:14
33

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.

  • 12
    "testing on the company internal servers, even outside hours" -> ESPECIALLY outside hours. If you mess up you now have to call people in – Stephan Bijzitter Oct 5 '17 at 7:45
  • 9
    "he could have added some thoughts....etc...." - hell, he could have PAID OP for their time! – PoloHoleSet Oct 5 '17 at 16:45
  • @PoloHoleSet Agreed, that was kind of my point in the last sentence. On the other hand, the OP shouldn't go to their Manager and suggest getting paid for doing something on their own time when it could've been done in company time. – Dragonel Oct 5 '17 at 20:10
  • 2
    He was testing in dev -- I would hope "I screwed up dev" is an "offense" on the scale of taking the last donut. – Rob Crawford Dec 11 '18 at 20:31
  • 2
    @RobCrawford Depends on their routines for handling "dev" systems. If someone else ("Joe") was testing on that dev system because nobody knew OP was doing anything, they still could've caused issues. So I'd say it could range from "I took the donut that was specifically earmarked for Joe" to "I erased Joe's 98 hours of priority testing just before his deadline" – Dragonel Dec 13 '18 at 17:42
6

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.

  • 3
    IMHO, this is ridiculous. Any manager or "team" that is offended by a member spending their personal time to make their lives easier needs to grow up. Anyone who values process this much needs to step away from the bureaucracy and try getting things done instead. – Rob Crawford Dec 11 '18 at 20:33
1

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.

0

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

-1

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?

  • Someone would be unhappy because he is just the manager. Any cost savings are not in his pocket, but the company's. The loss of power (employee doing good work outside work hours and outside manager's control) is the manager's loss. Of course discouring the employee is not in the company's best interest, but in the manager's. – gnasher729 Oct 5 '17 at 13:41
  • 9
    This work depends entirely on the intellectual property of the employer: the design and meaning of the database contents. It is nothing like "a website for a friend." Doing it after hours is not a magic "feel free to extend the software we own and rely on" permission slip. – Kate Gregory Oct 5 '17 at 14:49
  • Non-compete being observed tacitly covers both compete and use of software. No gain is being made by the employee outside of the company for any reason, therefore you don't need a "magic permission slip". – SliderBlackrose Oct 12 '17 at 19:05

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.