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 ?

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

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.

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.

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.

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.