17

My Question
Should my boss value something I've done to increase productivity, but isn't necessarily part of my job or something I was asked for to do ?

About my job
I work as a manufacturing technician in a big company and my job is to monitor, setup and work with cnc machines, similar to a mass production. Its very monotonous and repetitive so I though of a way to make my work a bit easier.

Because of my general interest in programming, I've started learning C#, SQL and "In-Depth" programming of our Siemens cnc machines over the past year.

I wrote a (in my opinion) solid C# application and made some modifications to our machines, which increase the overall productivity in my department. The app makes all the repetitive work, facilitates the setup and monitoring of the machines and reduces rejected parts due to human error.

We doubled our part output and reduced time for setup etc. In fact, one operator can now work with two machines instead of just one.

Nonetheless its not actually part of my job or apprenticeship. Nobody asked me to do this. I did it to make my job more interesting and because it was fun to write the code for the app, automate the process and to improve the whole concept.

Unlike my colleagues, my boss does not really value the work I've done besides my actual job. But I would be happy with some kind of small appreciation. Don't get me wrong I don't want to get a raise or something. A small "good work" and a handshake would be enough.

Do I demand too much ?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Snow Feb 2 at 14:49
23

Do I demand to much ?

No, you don't. You increased your company's performance which should impact on the numbers which is all management usually cares about.

I recommend you prepare a small report where you explain what you did, and what was the improvement you achieved. After this you can ask your boss if this kind of initiative is encouraged or not. Based on that you can determine if you are working in the right place according to your career expectations.

If I were your boss, not only I would congratulate you and try to get you a bonus, but also try to sell to upper management the goods things that happen in my team

  • I think I'll try this in one of our "personal performance reviews", since I think that my boss is generally open for improvements in our department/company. Thanks for the advise. – Eric97 Jan 29 at 17:16
  • 13
    @Eric97 Make sure that you have well documented your improvements in order that someone else could easily take over from you. Not that I expect you to be fired, but to more so show that you are really doing this for the benefit of the company and not so to create your own work "kingdom". – Peter M Jan 29 at 18:07
  • 1
    You'll also want to document any steps that are needed to make this production ready and highlight any risks and potential mitigations. Make sure your boss is aware of and signs off on these. Otherwise the positives could quickly turn very negative one day if something goes very wrong (see my answer below). – bob Jan 29 at 20:59
11

Firs things first, good job.

I do not expect you to choose my answer as an answer it's just a different perspective.

In general, taking initiative is a good thing. It shows you're interested in your work and the work the team needs to do. You're prepared to make a difference that counts and you're prepared to make changes to make things overall, better.

But... There are some concerns around this...

First, the software. It's designed and built by one person. My first concern is: Is it well tested? Has there been any real QA? Is it efficient? Does it consider all possibilities. Without knowing the software itself and the context of its implementation. My first thought is "..is the software ready?"

Second, there's a couple interpersonal concerns. One of them is if the work of two men can be now done by one, that means management can cut staff. Now, you may or may not care, that's fine. But having a reputation for trimming people's livelihoods can be challenging. I know that's the economy, but still. Colleagues might not celebrate your achievement if you've gone ahead and put fellow employees in the unemployment line. Management will love you and that might be a good thing. I'm not saying any of this is the case, but I could definitely see this being the case. Always remember, efficiency and automation aren't "free" someone pays for it and that is the way of the world. But not every person is going to be happy about that, and rightfully so.

Third, they didn't ask, why should they receive. Voluntary work is a tricky thing. If a change you make is very impact-full and make a huge difference in productivity and efficiency, then the manager has to explain that to someone. While on the surface, that might feel like a good thing. Sometimes higher ups don't like people who take initiative like that because there's usually a protocol in place for doing something like you did. So, not every manager will be happy with what you've done and I know for a fact, there are managers out there that would have you reverse the process. Because organizations are often hung up on process, for good or bad reasons.

I'm not saying you shouldn't expect a "thank you". I'm saying, we should always be cautious when we try to "do good". The best intentions can lead to some very strange incentives.

So keep that all in mind. Should you expect a thank you? Depends on how much harder or easier you made your manager's life. Delivering what wasn't asked for isn't always a welcomed thing.

  • First of all, thanks for all the different opinions and comments. I really appreciate it! 1) The software was written by myself and I'm continuously improving it and adding new ideas. I validate each user input and with the help of my colleagues I try to find as many bugs as possible. To be honest, the app is a bit of a overkill for that what its supposed to do (UI framework,MVVM, async/await), but along with writing this application I learned C#. 2) At that time our department was missing one employee on each shift, so luckily no one needs to be fired or something else. – Eric97 Jan 29 at 18:30
  • Nevertheless I'm not near a software developer, its just one of my hobbies! But for the task its supposed to do and for the problems with connecting multiple different machines, the software works very well. – Eric97 Jan 29 at 18:37
  • 1
    I think this is the best answer. I think OP's initiative is awesome and highly commendable, but this sort of things comes with significant risk. I know this from experience having taken similar initiative many times before myself (not with production processes, but with purely software systems) and what I've learned is this: it's easy to get a prototype that works 80-90% of the time, but that last 10-20% is incredibly hard to achieve and cause expose crucial flaws in the prototype. Generally the result of my "hey look what I built" experiments have failed, sometimes rather badly. – bob Jan 29 at 20:17
  • 1
    My advice to OP: 1) keep up the initiative! 2) talk with your boss or whoever else is appropriate to discuss what QA is needed to ensure that your solution is truly production ready (including establishing a process of how to handle downtime/failures with your new components). There may also be training considerations. Basically I think you want them to know that you've introduced risk and that what you've made needs additional QA. Because you want it to get that QA. All production ready software undergoes massive QA. Yours needs to as well. Else it will fail badly someday. – bob Jan 29 at 20:20
  • 2
    And 3) in the future make sure that you're creating a prototype in a low-risk environment, not in production, and make sure that management is aware of and signs off on all risks both when creating a prototype and especially when fielding it into production. – bob Jan 29 at 20:21
5

Should my boss value something I've done to increase productivity, but isn't necessarily part of my job or something I was asked for to do ?

The answer to that, for many workplaces, is "no".

Management will often pretend to encourage "self-starters" and people who take initiative without being told what to do, but when it actually happens some have serious problems with it.

For one thing many managers who use a "command-and-control" approach (machine shops are definitely this way in my experience), don't like it when things happen that are unplanned-- even if they're good.

Looking at it from their point of view, they're on the line if something goes wrong. A "rogue" application written by an apprentice that controls expensive machines definitely will raise concerns. What happens when you leave and everyone has become dependent on your application? What happens if the machines get updated and your application can't work with them anymore? Who do they call 5-10 years from now if the application needs updating? These places expect SLA's for their machines, they can't afford to have "line down" to hire an outside consultant to figure out what an ex-employee did years ago (admittedly-- that DOES HAPPEN more than you would think-- I made a living doing that once!).

It seems to me that your manager may be taking a wait-and-see approach and formulating a careful response. He probably appreciates what you did but isn't exactly over-joyed at the prospect of having a nascent C# programming team spontaneously growing in his shop.

Your best approach is perhaps to make a compelling case for how the company can support this application in the future.

  • 1
    For clarification, I'm not an apprentice anymore. I get your point, but for me that was a bit of the risk or "bet" I'm willing to take, to maybe get some chances for a future promotion. I definitely don't want to sit the next 40 years in the machine shop on a 4-shift model and to the same thing over and over again. The important thing for me was, that everything works the same without my programs. So if something breaks and I'm not there to fix it, they can still run the machines likes they did back then. Without the benefits obviously. – Eric97 Jan 29 at 18:55
  • 1
    @Eric97, yes, I am on your side on this. I am just trying to explain their point of view (as I imagine it). You may be right that they can always "go back" to the old way of doing it, but no one will like doing that if it means a productivity hit. In a way you are forcing their hand and creating a dependency. – teego1967 Jan 29 at 19:03
4

Your initiative is commendable, so keep it up (with caveats)!

Initiative is great! It's a major asset for any company. But it's important to recognize that initiative tends to introduce risk (I speak from experience!). The goal is to practice initiative in a way that makes your management chain aware of the risks ahead of time and gives them the opportunity to sign off on and mitigate any risks, or to reject them, in which case you stand down. You don't want to take risks on their behalf without their knowledge. That kind of initiative, while well-meaning, can get you in trouble.

Why isn't your boss saying thank you?

There are some reasonable possibilities:

Your solution might not have helped your boss

Maybe your solution doesn't increase a key performance metric for your boss. Or maybe it has caused him/her more work. Or even just more stress.

Your solution may not help the company long term

Prototypes, which any solution that hasn't been thoroughly tested is, introduce significant risk. Eventually they will have to be made production ready or replaced with something that is or simply taken out of service. Any of these processes could take significant time and money, and could cause production disruptions at the worst possible moment. So there's a chance, and a pretty high one at that, that this solution will eventually prove to be a net liability for the company (even if the solution could help the company in the long term, it may cost more than the company is willing to invest to get the prototype production-ready, and doing this without approval could force their hand). This doesn't say anything about your skills (though unfamiliarity with tools does increase risk), it's just a truism that putting a prototype into production is almost always going to cause problems at some point.

Communication is key

A key takeaway is that initiative is good when matched with good communication ahead of time. You need to make your boss aware of all potential risks of what you want to do before you do it and allow him/her to sign off on, mitigate, or reject those risks (in the latter case, you stand down and don't do what you wanted). It is also very important that your boss understand the state of your software with total accuracy. If it is a prototype, the boss needs to understand that it is not production ready.

What to do next

In your current case I strongly recommend talking with your boss, explaining what you sought to do, explaining what you did, discussing the benefits quantitatively, discussing the current efforts to make it production ready, along with a full and honest evaluation of where it is on that continuum. Ask whether your boss would like to continue to use it, and if so what (if any) additional QA measures are needed, what documentation is needed, what legal approvals if relevant, and what process adjustments are needed as well (e.g. will someone need to be on call if something goes wrong with the program at 3am during a production run?).

But my solution works!

For now, yes. Maybe it will forever. But unless you've made it fully production-ready already, which seems like a stretch unless it's very simple AND unless all required updates to the production process have also been made (QA, procedural, legal, documentation, staffing, etc.), then the likelihood is (and I speak from experience on this) that it will fail at some point, and as it is made more production ready it is more and more likely to fail in some pretty ugly ways. It's an unfortunate trap for programmers that putting together an 80% solution is quick and easy, and so it seems like making a production-ready solution will also be quick and easy. And even that a 90% solution might be ready for production without much risk. That's simply not true. I have a handful of failures under my belt to back up what I'm saying. Learn from my mistakes and expect this one to fail. Do everything you can now to help prevent or mitigate that failure. At a minimum your boss needs to know and fully understand what happened and any risks involved. This is key. It will be uncomfortable, but it's better than waiting until after a major failure to explain yourself to your boss.

Bottom Line

I would not stop taking initiative and I would also not ask for a "thank you". Instead I would do everything I could to keep this from becoming a liability for the company and I would make sure next time I communicate with my boss up front.

  • Couldn't agree more. Unfortunately OP is in damage control mode now, but for the future this is a good lesson. – bob Jan 29 at 21:13
  • @JoeStrazzere I've edited this to emphasize your point more strongly. – bob Jan 29 at 21:18
3

Think of it in terms of software you might use. A lot of effort and overtime was spent in delivering the end product. Even more so, post release, people sometimes might work overtime to deliver the product. Yet nobody thank the dev team when this happens. People might be more outraged or even switch to a competitor product should anything go wrong. They could care less if someone spent 50 hours or 1000 hours on it. They could care less if you lost your spouse and now have to go through a tough divorce battle and your kid going to grow up not knowing who dad is.

With that said, I don't think your boss is going to care now or even in the future. I would also think if anything goes wrong, you might get into trouble as the "last guy who messed with it." Even if your program never touched those parts.

1

Your task was worth doing, as you can tell from the appreciation of your coworkers. There are certainly bosses out there who would and do appreciate such things. Your boss does not appear to be one of them, though, and that's not unfair. After all, you were never asked to do it, and apparently didn't even discuss it with him while you were making it happen.

Now, if your question were one of "how can I get recognition for this?" there are some things that you can do, but you aren't in a position where it's reasonable to demand anything.

1

Self promotion is not a bad thing. It's how you get ahead.

Just mention to your boss.

Hey! Boss! I figured out a way to do XYZ in less time! Can I show you?

Then demo if he asks.

He'll either appreciate it, or he won't, but you've gotten the information out there. It may or may not help you on this job, but you have a healthy attitude which if not at your current employer, will help you advance your career during your lifetime.

Keep it up!

  • Thanks for the advise! I'll combine this with @Homerothompson answer. I don't want to self promote me in a bad, arrogant way. – Eric97 Jan 29 at 17:20
  • 1
    @Eric97 The way to self-promote in a good way is to follow the CAR rule, which stands for Challenge, Action, Result. Put things that way, and you'll never look bad. "I saw it was slow, I wrote some code, Now it's faster". No way to make that look bad – Richard U Jan 29 at 17:32

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.