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.


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.

  • 32
  • 73
    this is a bad idea. don't do it.
    – Fattie
    Commented Jun 12, 2017 at 18:02
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Jun 13, 2017 at 22:38
  • 6
    The situation you describe is beyond crazy. There is no reasonable course of action other than the second one you don't want to hear. The only alternative is to go over your manager's head and give their manager an ultimatum that your manager goes or the entire development team goes. Commented Jun 14, 2017 at 5:48
  • 2
    The manager will probably say that you sabotaged the in-house project, taking longer to finish it, so the one with newer technologies would look good. Really, this is a very bad idea. Don't do it.
    – T. Sar
    Commented Jun 14, 2017 at 14:10

14 Answers 14


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.

  • 5
    I agree with this answer. That's why I posted this question, and with a big doubt whether we're doing the right thing. We're willing not to get paid. We're willing for the company to own our project should they accept it. We have succeeded in getting the manager to accept (though, at first, reluctantly) other "previously banned" programming such as inheritance, creating and implementing interfaces, and meaningful variable naming, so we figure we could have any ounce of success with newer technology. I appreciate and agree with what you're saying, though. Commented Jun 12, 2017 at 17:53
  • 78
    No inheritance or interfaces? Uhhh... even without your proposed project, you have a serious problem on your hands. Seems you are working for someone really unsuited to lead a development team.
    – Xavier J
    Commented Jun 12, 2017 at 17:57
  • 66
    @MickaelCaruso inheritance and interfaces are things you can work around if you have to, some languages don't have them at all, but if your manager doesn't understand the value of meaningful variable names, you would be better off to find another job.
    – bluegreen
    Commented Jun 12, 2017 at 18:12
  • 61
    If I had this kind of work environment, I wouldn't be afraid to escalate things. Either the manager change, the manager gets the boot, or I go.
    – Alex
    Commented Jun 12, 2017 at 20:59
  • 3
    @Blaisorblade - I did it last night, the 5th paragraph. Commented Jun 14, 2017 at 0:50

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...

  • 41
    "Speak their language, not yours". Best advice when dealing with managers, imnsho Commented Jun 12, 2017 at 19:15
  • I agree. The manager is also one of the developers whenever they wish to edit or write code. Commented Jun 12, 2017 at 19:49
  • 5
    @MickaelCaruso managers who write code when they feel like it don't know how to do their job (or they don't like it)
    – Erik
    Commented Jun 13, 2017 at 6:08
  • 3
    Getting buy-in from the manager for your trial project ahead of time is probably the only way to make him accept the results of it. Selling it to him may take some effort; expressing it in terms of whatever criteria he finds important - which will take some knowledge of his personality and background - will increase your chances of success. Is he motivated by code quality? Maintainability? Predictability? Looking good to senior management?
    – psmears
    Commented Jun 13, 2017 at 12:40
  • 3
    I did this at one of my jobs. The manager insisted on using a flashy new technology Y, that had "big impact in the future", but lacked any sort of community support, libraries, open-source anything, etc. I asked said manager if I could do a "feature comparison" - what would it take, and how long would it take, to implement X in framework Y and framework Z. It turned out that Z, having been in development and active for over a decade, took 10% the effort of Y, meaning the manager would save 90% time and money. They of course allowed the change to Z immediately. Commented Jun 14, 2017 at 16:08

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.

  • 2
    I feel the questioner's pain, but this answer is correct. Commented Jun 12, 2017 at 17:21
  • We already know what we could be facing. Yes, this answer is correct. We are taking a huge risk, but we also see some opportunity which makes all of it worthwhile. Commented Jun 12, 2017 at 17:31
  • 7
    "but we also see some opportunity" what opportunity? just go work for another company that has technical direction more as you wish. (You'll get a raise in the bargain.)
    – Fattie
    Commented Jun 12, 2017 at 18:04
  • 6
    Opportunity is in the learning and having something tangible to show, even if we probably shouldn't because it's potentially defiant. If ever the situation calls us to seek employment elsewhere, we're better equipped. Commented Jun 12, 2017 at 18:18

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.

  • This is the best answer
    – Tony Ennis
    Commented Jun 13, 2017 at 23:13
  • This answer can generally make sense—but this manager used to forbid "meaningful variable naming" and "source control" even though he was also a coder. So I wouldn't trust him in either job. Commented Jun 14, 2017 at 0:59
  • In this case you're not going to change his mind with logic
    – Thomas
    Commented Jun 14, 2017 at 9:19

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.


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.


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.

  • THIS. Company is a hierarchy, use it.
    – Agent_L
    Commented Jun 13, 2017 at 15:16
  • 1
    I think improvement proposals should not be restricted to come from managers. Commented Jun 13, 2017 at 22:46

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.

  • We have already done these things. The answer was a big emphatic no. The manager specifically told us that it is a problem if we used any technology or practice they do not understand. This is why we're contemplating to work covertly. I hate to put it that way. We are working on plans on how and when to approach our manager with the least amount of friction. Commented Jun 14, 2017 at 16:04
  • @MickaelCaruso - so I'm not sure how this overcomes his objection, and accomplishes anything but belittling (even if it may seem deserved) the manager. The answer will still be no, since it won't change the problem of the manager not understanding the technology. I was afraid that this might be the case, but other than being a catharsis for your group's frustrations, I don't see how this helps or alters the problem you have. That's the main objection I have. Unfortunately, I don't have a solution for how to get the manager on board and get your team working more efficiently. Commented Jun 14, 2017 at 16:13
  • Our course of action at this point is just to develop as told and hope that the manager's vision becomes vivid enough that their preferred legacy technologies won't be able to accomplish. Commented Jun 14, 2017 at 16:17
  • @MickaelCaruso - I hope it works out for you. Good luck making the best of a difficult situation! Commented Jun 14, 2017 at 16:28

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!


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.


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.


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."


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.


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.

  • 8
    this is borderline ridiculous in any civilised context. Commented Jun 12, 2017 at 23:02
  • 1
    @NicholasKyriakides Note the :p I think this answer is facetious and not necessarily to be taken seriously. It does spell out that "get all of you fired" is a reasonably likely outcome. Commented Jun 13, 2017 at 21:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .