Research and proof of concept work for an unapproved project

Question

I've been rolling an idea around in the back of my head for a coding project at a company I was recently hired on to that would add significant value to my company's primary software package. My manager, however, is of the opinion that if a customer isn't paying for it up front, it's a waste of time.

I feel that If I could prove the concept to my boss, he would see it as a viable replacement for aging (10+ years) software. The existing software is not only hard to use, but its components are in varying stages of deprecation — to the point that attempting to take certain actions that were at one point legitimate could now harm the software’s back end database. These few components are only still in use for a few “low level” features that comprise roughly 5% of the original intended purpose of that particular component.

I feel I would have to do a chunk of this preparation in my off time. It’s not approved work and I do have other more pressing issues to attend. Honestly this doesn't bother me much, since I see it as:

1. Improving my own skill set.
2. Showing to my boss that I can take initiative to further the goals of the company.

I’m not sure my boss would take the same mindset though.

So is it acceptable to research and work for projects intended for a company off the clock? Are there are guidelines for situations like this? I don't believe I'd spend so much time I'd even bother asking for compensation for the work I did, but I'm not sure how that would sit with my boss either.

Answer 1

It's great that you have a new job, and that you can see good ways to improve the company's software product. Don't ever let anybody tell you to stop thinking about ways to improve things.

Go ahead and experiment with this change if you have time while you are still doing your regular job with excellence. Be careful doing that, though. Make sure it's OK to take the company's source code home with you if you're doing this at home, and make sure you follow the company's other intellectual property and security rules.

But, seriously, slow down trying to persuade your supervisor to accept your change. Being an agent of change is hard and painstaking work. Here are a few points about that.

1. See if you can find some business books on being an agent of change. One of the best, but hard going, is The Fifth Discipline by Senge.

2. The company needs to trust you before you successfully can propose changes. You haven't been there long. Do your job well and build up your respect. It takes time, at least a year, to build up respect. It will take longer if you neglect your regular job to work on side projects like this.

3. With respect, they don't need you to rescue them. This product you mention is ten years old. That means it has been debugged and already has success (which isn't easy). As you propose changes, honor that success.

4. If there's a power base (like a senior developer now in management) who is afraid of change, you need to know who that is and figure out how to work with him or her.

5. Before you make changes, you need to know a lot about the ecosystem your company's product lives in. You already know it uses some aging tech infrastructure. What you may not know is whether some of your best customers are stuck with older tech as well. It's likely in the real world.

6. Get to know the product manager if there is one. Ask her how projects for new features and product updating get imagined, approved and funded.

7. Ask your supervisor, or someone else to be a mentor to you. Say "how can an ambitious hotshot like me become most effective at doing my work and really contributing to the company's success?" Then listen to the answers.

8. Try to get some customer-contact assignments. Ask to go along to listen on some sales calls. Listen in on help-desk calls. Learn about day-to-day customer concerns.

9. Don't even think about being paid extra for your experimental work. I need to explain that statement. When you're brainstorming and prototyping this way, you need to stay focused on the tech, rather than giving yourself the illusion that you're saving the company from doom or creating lots of new value. It may be that your tech will create value for the company somehow, but that is a long way in the future. Innovation is part of your job.

Now, if you work slowly and carefully as a change agent, and a year from now your supervisor is still saying your ideas are unwelcome, it's time to move on. You will have learned a lot.

Answer 2

You say this:

I feel that If I could prove the concept to my boss, he would see it as a viable replacement for aging (10+ years) software.

First red flag. If the code is 10+ years old & failing do you think you are the first person to have ever brought this issue up? You might have an idealistic idea of “changing the company from the inside out”, but I am pretty confident it won’t work this way. 10+ years and software failing without real action reeks of some larger organizational issues at play that a simple recoding won’t solve.

For example, perhaps the decision to use the system is not based on it’s real value but rather a political one. Such as an ex-employee everyone liked coded it. Or maybe someone on staff at the company made a decision to use this software & moving away from it would make them look bad which is something your boss does not want to touch with a ten foot pole.

I feel I would have to do a chunk of this preparation in my off time - It's not approved work and I do have other more pressing issues to attend. Honestly this doesn't both me much, I see it as:

1. Improving my own skill set.
2. Showing to my boss that I can take initiative to further the goals of the company.

Your first point is the best reason to pursue this. I code in my free time to do exactly that. And sometimes my projects are born out of the needs of an employer. Sometimes it’s just me experimenting & learning. And you never know: Your experiments could impress your employer to follow your lead to rework code for the company.

But your second point I am not too sure about. Perhaps they will see initiative. And that is good. But perhaps they will simply not care. You cannot bet on something like the second point.

I’m not sure my boss would take the same mindset though.

Don’t ignore your intuition.

So is it acceptable to research and work for projects intended for a company off the clock? Are there are guidelines for situations like this?

You can research & do anything you want off the of the clock. That is your time. That said, if you will be working on your time on a project, you need to absolutely make sure you get something out of it. And I do not mean compensation or recognition.

You should basically see if doing a project like this on the side can be something viable in the rest of your career beyond this specific job. Meaning can it be made generic & applied to others in the same field? Can you open source it on your own to share with the world & perhaps grow a great project into something bigger?

In general, code this for yourself with an eye of this being a project that will help you yourself and perhaps show your boss this proof of concept is worth pursuing. And if your boss doesn’t think much of the proof of concept? Well, you still have code worth doing something else with.

Also, if the best case scenario for you plays out, the chances of you getting compensated for off-hours work is zilch. The best you can do is hope that this coding will lead to a promotion or raise in the future. But that is it.

Answer 3

The fact that your manager said anything that customer's aren't paying "up front" for isn't worth doing is a key sign that you are working in a "convergent" business.

They have a set of customers who are buying what their selling and who, from time to time, will make feature requests. There are probably contracts and maintenance agreements in place, as well as support and training services. The key decision makers in your company see this as a steady "pipeline of money"-- something which is NOT to be tampered with or disrupted for any reason.

What you're proposing, however good, is disruptive to them. From their point of view you are talking about taking a leap into the unknown.

If you want to pursue your idea in your current company (a long shot), you have to find a different angle: get involved with sales and marketing. In a convergent business, activity is driven by sales, and not by random folks in engineering. Like your boss says, the customer has to pay up-front... and they do that after engaging with sales.

Alternatively, you might more happy in a start-up which by definition is an "emergent" business where you create the market.

Answer 4

The problem, is not knowing how your boss will feel about this. The main problem with all corporations, they get extremely nervous when they hear the word change. You need to ask your boss what his views on the current existing software. If he is doubtful, does this software bring money saving changes, if so, do it. If not, discard the project.

Also if this software is useful, get it patented, most of the upper people got there due to others work credit.