There are two facets to this question: what you can do as WesleyJohnson and what you can do within your organization. Your motivation is making sure WesleyJohnson has a job four years from now. Your organization's motivation is selling more $FOO at lower costs. You need to start identifying or creating happy synergies which align your organization's motivations with your personal motivations in terms of career growth.
I do Big Freaking Enterprise Web Apps at the day job. I do not want to be doing BFEWA in a few years, so I convince my day job that I can deliver projects on schedule and under budget if they give me more latitude with respect to the technologies I'm allowed to use.
This started with the kind of one-off "We don't really care what you do to accomplish this as long as you get the job done" projects and snowballed from there.
A key component of my process was, after saving them a truckload or two of money, I would rigorously document what I did, how much we saved (metrics METRICS metrics), future places we could employ the technology/technique/whatever, etc.
After iterating this a few times, a) when I say "Hey boss, that will work, but I can do it two man-months cheaper if you let me do it my way" they tend to listen to me and b) other people come to consult with me about How To Implement X issues because they've found that I often know what I'm talking about or, in the alternative, can rectify my ignorance with a few weeks of studying and rapid prototyping.
When I'm building stuff for the day job, usually I want to be leaving them working systems or system improvements which will continue to generate value long after I am no longer there (as opposed to daily firefighting). I also want to be building personal capital which will continue to generate value long after I am no longer there (as opposed to daily firefighting).
Note that if you have a small side business, you can create opportunities to use a new technology without having to bring anyone else into the loop at all. Earlier this year I wanted to do some work with NoSQL to see what all the fuss was about. So I picked one of the upcoming tasks that looked like it would be a good fit, and did it. (Presumably you can do the same with OSS if you don't have a business handy.)
Another very good idea and something I hadn't thought of. As I mentioned, I'm only 1 week into the new job, but was given wind of a new project coming in that's going to require a classic ASP webapp to be migrated over to ASP.NET. This may be a great opportunity for me to do just what you've outlined.
A key component of my process was, after saving them a truckload or two of money, I would rigorously document what I did, how much we saved (metrics METRICS metrics), future places we could employ the technology/technique/whatever, etc
How do you generate the difference between the project that you got done with your method versus the project that wasn't done using a different method? Is it real cost of your way versus estimated cost of doing it the other way, are you re-writing a project that has already been written by a different team, or what? If the cost of the other way was an estimate, are the metrics trusted because you have a great track record with your estimates, or do you have some sort of estimate-aiding tools that your employer relies on and trusts?
I do Big Freaking Enterprise Web Apps at the day job. I do not want to be doing BFEWA in a few years, so I convince my day job that I can deliver projects on schedule and under budget if they give me more latitude with respect to the technologies I'm allowed to use.
This started with the kind of one-off "We don't really care what you do to accomplish this as long as you get the job done" projects and snowballed from there.
A key component of my process was, after saving them a truckload or two of money, I would rigorously document what I did, how much we saved (metrics METRICS metrics), future places we could employ the technology/technique/whatever, etc.
After iterating this a few times, a) when I say "Hey boss, that will work, but I can do it two man-months cheaper if you let me do it my way" they tend to listen to me and b) other people come to consult with me about How To Implement X issues because they've found that I often know what I'm talking about or, in the alternative, can rectify my ignorance with a few weeks of studying and rapid prototyping.
When I'm building stuff for the day job, usually I want to be leaving them working systems or system improvements which will continue to generate value long after I am no longer there (as opposed to daily firefighting). I also want to be building personal capital which will continue to generate value long after I am no longer there (as opposed to daily firefighting).
Note that if you have a small side business, you can create opportunities to use a new technology without having to bring anyone else into the loop at all. Earlier this year I wanted to do some work with NoSQL to see what all the fuss was about. So I picked one of the upcoming tasks that looked like it would be a good fit, and did it. (Presumably you can do the same with OSS if you don't have a business handy.)