Is it acceptable to collaborate with coworkers on a project outside work to prove something to our manager?

Question

I think it's perfectly fine to work on a project with coworkers "just for fun" outside work as long as we're not on company time, and we're not using company resources.

But our situation isn't playful as mentioned above. We are facing a situation where our manager is adamant about not using frameworks, technology, and other modern development practices they do not understand, even when their requirements are easily and directly addressed by the newer tools. We are forced to write hacks to get the older technology to make things look and operate like a modern product, and it is taking a very long time to develop in such a manner. Also, our manager insists on using the same older technology for any future projects (which are more demanding of modern technology in nature) for the foreseeable future. Our manager does get uncomfortable and does get angry when we suggest that a feature in a newer framework easily addresses a problem we have in our current project. They even told us that there is no proof that the newer technologies and frameworks are faster to develop than legacy ones, which inspires us to pull this feat.

So instead of trying to win the manager to implement newer technology and practices in the company's current projects, we decided to work on a outside project, including logging the time it takes us to discuss, develop, test, and document the product and process. Yes, we intend to submit all of our documentation and demonstrate the working product to our manager in the near future, with the main intent of proving easier development and more importantly, far less time to develop and deploy. So we'll accept the current requirements for the current project, but are fighting for modern development for future projects. To be clear, we will not develop the outside project under company time; we will develop it in our spare time at home, including our communications. We are willing not to get paid for this side project. We are also willing for the company to ultimately own it should they accept it.

It does seem like our ultimate goal is to gloat at our manager. That is far from the case. We just want to deliver quicker and more importantly, more effectively. We just see our newer technology proposals as beneficial for the company as well as a better experience for everyone.

We realize that pulling this is risky and probably offensive and disrespectful. But in the past, there were programming and development practices that were previously "banned" like inheritance and creating/implementing interfaces (because those confused them but our main language has those features), meaningful variable naming (because it took too much time to think of and type the appropriate names), and source control (because it required a learning curve that would take time off current development). We have managed to get the manager to embrace those (by showing the amount of duplicate code we no longer have to write, by asking the manager what they meant when they wrote variables like temp1, temp2, etc. and they couldn't tell us right off what those meant, how quickly we can roll back the project to a previous successful state), and so we may have a shot at getting the manager to adopt/accept other tools and frameworks, again, for the appropriate future projects as each project deems necessary. Some future projects are basic enough that the older technology will suffice.

But we somehow feel that we could be backstabbing or disloyal for pulling this feat, and at demo time, it feels like defiance. What other approaches may we take in our quest to win this battle?

We request that you do not provide the following two suggestions, as we've seen those in enough posts:

1. That we have no business being in software development if we are unable or unwilling to develop with such debilitating restrictions, then work in another field.
2. Leave the company and apply to another or found our own software company. (This is our last resort, and as much as possible, we don't want to choose this option).

We would appreciate your feedback.

Afterthought

Thank you very much for all of your input regarding this. A vast majority of you have advised against what looks and feels, even to us, controversial. We realize that there are interpersonal and financial implications with our plan, and that our chances of overall success are practically <= 0%, despite being able to claim some technological victory.

We still plan to work on projects outside work, but we have changed our approach to be more on the defensive side, and our primary purpose no longer to prove ourselves (which unfortunately also reads prove the manager wrong), but to build our knowledge and experience. This way, we are ready in case the manager accepts newer versions of our framework, other frameworks, tools, and practices in the (hopefully) near future, or we are better equipped/more marketable in the unfortunate event that we may need to seek other employment.

Answer 1

You're wasting your time and potentially creating a situation to cause yourself undue stress with.

The manager's "stuck". Other than by the issue of an explicit instruction from someone above that manager, this probably isn't going to change. The manager probably has issues with delegation, and a fear that a new technology isn't something he/she can roll up those sleeves and address personally in the absence of others. It's highly counter-productive, yes. I've been in your position.

If you build something during off-hours, and then present it in a sweeping overture to said manager, what happens then?

• Will you get paid for your off-hours work? Probably not.
• Who will "own" the work? This in itself could cause a mess.
• Will it change the manager's mind? If those heels are already dug in, probably not.
• Will it make the manager even more defensive? Probably!

Essentially, you're trying to stage a mutiny as a means of being "right". I don't think you're considering the down-side, because an insecure manager may decide to fire every single person involved and replace you with people who are more loyal. I'm sure there are other means to intervene over this technology-stack issue in front of you, but I'd really frown on ganging up on the manager in this way.

Answer 2

Ask the manager if you can perform a trade study that demonstrates and compares the ROI (return on investment) for each solution. This will allow you to prove the benefit/cost/maintenance/quality metrics to support your solution and to also point out the overall costs of staying with the old way of doing things.

Remember, as a manager you cross into the "management" and not so much the "technical". You need to prove the new technology saves budget and also will deliver a solid quality and maintainable solution to the client. Find out the key hangups the manager has with the new vs. old technology and do a full honest compare/contrast with ROI for each one. This usually works best to sway management one way or the other and also to build confidence in your abilities and opinions.

P.S. Investment in a technical sense includes rework/extra, verification/validation, etc...

Answer 3

If the outside project uses anything company-related such as databases access or servers or proprietary information, then you could be in legal trouble. This includes using company requirements. If it is company related, then they own the software (in most jurisdictions) even if they didn't ask you to do this.

The most likely outcomes of such a project done unofficially are that you get fired or you make an enemy of your current boss. People in authority don't like to be embarrassed and they have to tools available to make sure that doesn't happen again. I don't know your boss, but based on the bosses I have had and worked with, I would estimate your chances of succeeding to be well under 30%. Based on the fact that he wasn't even willing to entertain the discussion of other tools, likely success rate might even be under 10%. If you are willing to take such a risk, then go for it.

Answer 4

You never win an argument with your manager.

Even if you prove your point, you'll be labelled as a problem and this cause you problems; it could be right away, it could be later, but most likely it'll be subtle and not good for your carrier.

I started as a programmer, and I used to think managers "didn't get it". 25 years later, I've been responsible for up to 350 people at once and led many teams that were in the 40-80 people range.

There may be a lot more at stake than the technical merits of a solution. Sometimes there are much better ways to do things than what the business is doing, but as inefficient as the current solution may be, the team may be used to troubleshooting it, supporting it, maintaining it, upgrading it, etc.

Having predictability is often a lot more valuable than efficiency, especially in large teams where a deviation from the plan can be very expensive.

So, you're having these situations where you can save X hours of work and that saves $Y, but changes always involve risks; if today's cost is acceptable and budgeted for while the risks are low, a better technical solution may not be better for the business.

Now, to get back to the question:

The best way to deal with your manager is to make an assessment of the current situation and your projections with the new solution, on your own time.

That way he will know you have another opinion; if he is a good manager, he should explain you why he thinks the 'wrong' solution is better for the company and it is fine to explain that you reached different conclusions.

When comes the time to do a change, upgrade, etc, most likely he'll look at you as the right person to work on it; and even if you don't end up with that task, he'll know you were right and this can be quite valuable for your career.

Many times I had to make choices where I'd have the team implement crap just because we had some deadline to meet and we had the budget and time to redo the stuff later. No one likes it and, no matter how you explain it, the team doesn't accept it. But at the end of the day, it puts the product in the hands of the customers and keeps your team employed.

I know it's frustrating to do things in a way that's not efficient, especially if you know that you will have to work more as a result; but there is more than technology to a project and the other parts are sometimes more important.

Answer 5

Manager's Concerns?

Cost to the Organization

In your description, I do not find where you attempted to discover why the manager insists upon a certain technology stack and certain development practics, other than "they do not understand."

But, "do not understand" can be a valid reason - it is standard management practice to reduce the number of technologies and practices that an organization must know and support to keep the cost of keeping and replacing technical staff low. That is their job - keep the cost of the most expensive resources (developers) low.

Humans are Expensive

Introducing new technology that requires specialized training/skills (frameworks are mostly opinionated and therefore, specialized) reduces the options for replacing and/or adding staff at cheap levels.

Consider this possibility - hiring cheaper developers to do the work the "old way" may still be less expensive than hiring more skilled developers to do it the "new" way, even if the old way is slower.

On top of that, every new technology also costs money every day terms of support, on-boarding speed for new employees, patching, bug-fixes, etc.

You should be 100% sure that cost of your new frameworks and practices outweigh the benefits.

If you can prove that, you probably do not need to make a proof-of-concept project as you have the business reason to introduce it, not a technical one.

Manager's Reaction

If you proceed without being able to demonstrate a business/financial benefit to the organization, your manager will most likely lose respect for you, and may possibly become angry.

Why? Because you are intruding upon the manager's job duties without being asked, and making a technical case (which means nothing) instead of a financial case (which means everything).

If you really want to move to the newer technology, you need to prove financially that your new approach reduces costs and risks to the organization - i.e. you need a business case, not a technical one.

Answer 6

Other answers have addressed well why your idea is inadvisable. I'd like to suggest a couple ways you might approach your dilemma more productively.

One thing we introduced at our company that has been very successful is Hackathons. Basically, once every 10 weeks people can form teams to work on whatever they want for a day, then present a proof of concept the next day to be voted on by peers and people from the business side. Winners get a steak dinner and a certain amount of clout to actually get the ideas implemented in production. You can get a surprising amount done in a day. Every once in a while they will make it a week instead.

Another idea is called 20% time, and is sort of the same thing but on an individual team level. Engineers are allowed to spend time on exploratory projects as long as they report their results to their teams, success or failure, and it doesn't take more than 20% of their work week. Project managers worry this will suddenly cause velocity to decrease by 20% across the board, but in practice, engineers tend to use this somewhat sporadically, and usually when it is most beneficial due to inefficiencies in their official assignments.

Our company is just as risk averse as the next. These sorts of programs allow them to spend a predictable, limited amount of engineer time trying out risky innovations, while making sure the ones that show the most stability and promise receive the visibility they need.

Answer 7

I see 2 options:

1. He's your boss, do as he says.
2. Take a risk. Go over his head, present to his boss explaining why you believe you should be a manager, and why it makes commercial sense to adopt new policies. Do not speak negatively about the current manager - you're not there for him or to bad mouth him, you're there for you and to improve the companies bottom line. You can then suggest that you lead a small team following your proposals for 3 months, and then should it be decided that your proposals weren't working then at least it was tried.

Bear in mind if you try #2 and it doesn't work, you'll be looking for a new job.

Answer 8

Even if the intent is a benevolent "see the light" initiative, it's pretty much impossible, especially if one is already resisting change, to not take it as "see, dummy?" and as a rubbing of one's nose in being wrong, wrong wrong. The situation you are in is very bad, but this approach will probably turn up the setting to "toxic."

Instead of just looking at the manager's point of view as resistance, assess what the objections are, and try to take a more pro-active approach.

Go to the manager, in a formal requested meeting, probably as a group or as an agreed-upon representative of the group. State your objective case for using more modern tools and frameworks. Then state your understanding of the manager's objections, and ask if you've missed anything.

Then you ask the manager if there's any way you could target a smaller, lower-profile task or project to use as a "proof of concept" - to allow the manager to see the value of such an approach, but with minimal risk.

It's entirely possible, if the manager fears being obsolete or unqualified to work with a team using these techniques that the answer will still be "no." However, if that's the case, the more confrontational, high-profile, in-your-face approach would probably also have gotten a "no," but pretty much drawn battle lines in the process.

At least, with this kind of approach, it's less personal, it's offered from an objective, professional, good-for-the-company work improvement perspective.

Answer 9

Firstly, what are the benefits to working out of hours on this project to prove to your manager that your approach is better than his? I don't see any, if your manager is stuck in his ways as strongly as you suggest:

1) He is probably not going to change his mind simply because you can prove you have a faster way to produce results, since you have already shown him that modern approaches are better suited to your problems.

2) He may be offended that you and your co-workers went behind his back and wrote code to prove a point to him, which implies you are all also talking behind his back about how he makes poor decisions for the team

3) It shows an lack of respect (regardless of whether it's reasonable) for the decisions of your manager.

Whether or not your manager has made the right architectural decisions for the software you are developing, it is your job as a developer to follow his instruction. You are of course right in trying to explain to your manager that there are better approaches to solve your organisation's problems, but if the issue has been raised and settled, there is not much you can or should try to do.

It is probably not worth the time for you and your co-workers to work off the clock due to the incompetence of your manager, as you will likely not see any positive return for your time!

Answer 10

You are trying to prove to your manager that the company would be better off without him, and it would appear that he walled off (consciously or not) previous attempts of you and your colleagues to do that on company resources.

So you intend to do it outside of his control.

I really cannot see this ending other than people getting fired or quitting, externally or internally.

If you sever your ties with this manager in order to complete a project outside of his control successfully, how do you expect to resolve the situation without heads rolling? What do you expect the manager to do while still earning his wages?

You are trying to turn an unresolved conflict now into a larger unresolved conflict later. Try figuring out whether there isn't an actual way forward under this manager's direction that does not involve releasing him from his responsibilities.

Answer 11

If you succeed in completing the project faster than you would at work, what you are actually doing is proving one thing to your manager - that if you don't have to be paid to do the work, then you are more productive.

Although this is a fairly well known phenomenon, for the sake of your future pay rate, it may not be the best thing to convince your manager of it.

Answer 12

You can propose your idea to your manager:
"Sir/Madam, you don't want to introduce new technologies and I don't understand your reasons for it, and hence I don't agree. Therefore I'm thinking of developing the new project together with some collegues in our free time, just to convince you that that new technology has major advantages. Obviously we will monitor everything in order for a realistic comparison to be possible. If we manage getting this new project to work using the new technology and we can present a working product during a demo, what arguments would you have at that point for further blocking the introduction of that new technology?"

As answer your manager might agree, or (s)he can come up with arguments maybe you didn't consider yet (financial aspects, maintenance and other contracts with technology supplier(s), ...)
As an example: my company is working with a very old-fashioned installer creation technology. I've proven that using a newer technology would heavily reduce development and maintenance costs.
My manager then pointed out "You are right, but we are not only buying installer technology from that firm, but also other technologies, all together in a package, causing a price reduction. If we would decide not to use anymore one of those technologies, we'd still need to pay for the whole package in order not to lose the reduction, so we'd face a financial loss anyway."

Answer 13

This is the way innovation happens. Its uncommon for everyone to agree on a given course of action but the context here is the hierarchical position of the person that disagrees. I would recommend trying to understand why. By experience I can tell you people tend to be uncomfortable with the unknown. If so remember the purpose of your side project is not to develop a tool to be compared with the current one but to fill the gap of the unknown.

Make a list of the most common operations your team makes, write down the code to achieve them in the new framework. Make it easy to follow, like a guideline, something that anyone reading it would need nothing more to achieve the same. If you really want something to shine make it easy and approachable. We tend to be a lazy species.

Benchmark against the current framework and conceptualize the new things the team can achieve with the new tech (and possibly not in the old one). Compare development time and level of proficiency required to deal with the new tech (1). Do you need to change your current paradigms (different design patterns, different architectures)? How long would it take for someone to be fully integrated with the new tech? Would the tech transfer be smooth? I would ask this and other questions if analyzing a situation such as this. Build a case study scenario, with each of the steps your team is doing with the current framework, and show how it would happen in the new one.

As a final note I think what you are doing is good (its supposed to happen in any tech company). The way you approach it is the thing that is going to make the difference between positive initiative and rudeness.

As final warning the same way its common for people to be uncomfortable with the unknown is also common for them to get over excited with something that hardly represents a technological leap. Make sure the new stuff has true advantages without ambiguity.

(1) This might seem strange but the easier the technological platform the better for the company. Not only it makes the team less dependent on particular individuals but also provides new possibilities for new hires. If every person you hire needs to be a specialist in framework X than you'll be loosing, by default, a lot of people with very good skills (UI, architecture, data analysis, etc.) just because they have little to no experience in that framework.

Answer 14

If you decide to go for it, first present it to the manager alone, get all of you fired, then present it to the manager's manager and ask for a raise to come back to the company. :p

It's a risky move, but if you don't wanna get stuck in the middle ages and lose all chances on finding a decent job later in life, I would recommend to take the risk. Assuming all your bills are paid and you can find another job easily.