Here is a little background: my manager has been with this company for more than ten years. It seems like he's learned very little in the time he's been here and does things the way they've always been done. He is an engineer/programmer, so he works with C++, SQL Server, .NET, JavaScript, and similar technologies. He's been the one to do the front end development too, so he also does HTML and CSS.

Fast forward to present day: I am a UX analyst, visual designer, and web developer. I would say my visual design and web development are stronger than my UX at this time. I've been doing web design and development for quite some time. I am always reading and trying new technologies, such as CSS preprocessors SASS/LESS, templating languages like Liquid, and compilers/environment tools like Jekyll and Vagrant. I use these to streamline my workflow, speed up development, and make my code clean, efficient, and easier to maintain.

I brought these technologies and tools up to my manager and he doesn't understand them. He thinks new technologies are like Dreamweaver (I guess he had a bad experience with Dreamweaver, as we ALL have, and thinks tools outside of hand coding everything will somehow contaminate the code). He constantly makes arguments against them, like how they aren't cross-browser compatible and they'll inject things in that will bloat the code. When I make a point about one thing, he'll bring something else up. I think he just doesn't want to learn? I physically showed him a pretty robust UI kit I had developed over the last few days and he was unimpressed and severely undermined the work by saying he thought I used a drag and drop editor since I am a designer, not a developer (but I am a developer, just not the same kind of developer as him). When I tell him about these new technologies and how they will help our workflow, increase productivity, and cut out development time significantly, he will either shut me down or give some excuses(s) to not use them. He says I can use them, but he just wants the outputted HTML and CSS, he doesn't want the "other stuff".

So, how can I ever move forward if my direct manager doesn't understand my skills or work? And if he can't understand my work, how will he ever see the value I provide? I tried to sit him down and explain these technologies to him, how they will benefit us, how they're easy to learn and use, and how they'll save us previous development time. He just half-listens and then gives reasons why he doesn't want to use them. I heard him out and genuinely tried to address each of his concerns, but he wasn't having it. He just tunes out and gives the same excuses. What can be done here?

  • 1
    Boss is the boss but it is kind of odd they would be stuck on older stuff and still have a UX person. – paparazzo Oct 22 '15 at 1:45
  • 10
    Well, a lot of tools do add a ridiculous amount of useless extra code. An example from my recent work: SharePoint's browser based page editor tends to randomly define spans and divs, and assign the same style parameters to a div, to the single p within it, and to the two adjacent, identical spans that make up the entire content of the p. So I'll go back and strip out the div and the spans, leaving just a single p tag around my text, which reduces the byte count by about half, on average. – Dan Henderson Oct 22 '15 at 7:29
  • 14
    "I use these tools ... to make my code easier to maintain." - Your boss probably wants the code easy to be maintained by others on your team as well. Even if it's something simple like using a LESS preprocessor in the build process, this sort of thing can add up - if your team is not familiar with all the great tools that you added to the workflow, the unfamiliarity can add more maintenance costs than the benefit they deliver. If you want to introduce these changes successfully you've got to do it gradually - sell each one to your boss in a bite-sized way. – Brandin Oct 22 '15 at 11:44
  • 3
    If he says you can use them but he doesn't want to, what's the problem? He just wants a deliverable. If you want to impress him, impress him with your code, not how you created it. If the problem is that your idea of "good" code and his differ, then you do have a problem and you need to decide if you can live with his standards, because it doesn't sound like you will be able to change them. – Francine DeGrood Taylor Oct 22 '15 at 18:00
  • 2

I was in a similar situation a few years back and this is what I have learned from it, though I am more of a server side developer.

Productivity in software development should not be the sole criterion when deciding on software technology. It is actually software maintenance that matters much more.

While some new software development technologies do actually improve productivity, a lot of new technologies are merely exciting fluff that actually decrease productivity in the long run though they may seem to make everything easier at the moment. They are new, exciting, fashionable and the people who use them are considered smart and those who don't are regarded as backward and out of touch. That pressure drives people to adopt the latest fashion in software. No more thought has gone into adopting these than goes into deciding to wear those extra tight jeans or those extra low pants that display the underwear.

Experienced developers have gone through several cycles of software fashion crazes. They have even seen ideas in the software industry go out of fashion, briefly come back into fashion and go out of fashion again, like bell bottom pants. So they tend to look for methods and ideas that provide long term value, not just fluffy excitement. That explains the approach of your manager.

I learned a lot from my manager who had similar ideas as your manager and the team I am in now reaps the rewards of his approach.

  • 8
    Wish I could upvote this more. I've seen many projects torpedoed because the tech that some of the developers brought on that seemed to increase productivity ended up causing far more work when the inevitable changes were requested. The more complicated things that are added to the mix, the worse it ends up. – NotMe Oct 23 '15 at 23:06
  • 6
    I would upvote this a million times. But then some of us have been involved in trying to fix a serious production problem with people asking for progress every five minutes because the company is losing money and having to filter through inefficient, bloated code generated by some tool. – HLGEM May 12 '16 at 15:01
  • 2
    I want to upvote several times, too. There are plenty of new things that are cool, but they should be evaluated against the full lifecycle of the product, not only on their coolness or novelty. – gazzz0x2z Sep 23 '16 at 11:15
  • 3
    I partially agree with your answer. Yes, maintenance is very important. And yes, fashionable fluff exists in software technology. But at the same time, old technologies are sometimes encumbered with real problems, and some of the new technologies address these problems very well. Now I have never used LESS and cannot tell if it belongs to the genuinely useful new technologies or to the fluff. But lumping all new techs as fashion craze is not productive, and if the manager is refusing to understand how they work, he won't be able to distinguish between the fluff and the valuable innovation. – rumtscho Sep 24 '16 at 20:40

Is it in your job description to determine what technology stack your company uses?

If not, then you need to accept that it's not your job to change this aspect of the company.

There are reasons why a company might choose to stick to the old technologies that it's already using - aversion to risk being the first one that comes to mind.

That said you can still make an argument to your manager who does have the role to make changes to the technology stack. It sounds like you've already done that. You also need to accept, that this may be just how the company, for good or for bad, wants to work.

Rather than seeking to change your current company to fit how you like to work, you might want to consider finding another company that already has the culture and technology stack that fits you.

  • 6
    "If not, then you need to accept that it's not your job to change this aspect of the company" - I disagree, it's every employee's job to improve things. But you're right in as much as it's not his job to push it beyond recommending it (or perhaps writing a report comparing the approaches) – Jon Story Oct 23 '15 at 10:19
  • 3
    Just because you don't have the final decision, it doesn't mean you can make strong recommendations. No one asked me to go find a CRM system, I suggested my company needed one and got involved with the selection and implementation. Many people define their jobs. – user8365 Oct 23 '15 at 18:30

Like a lot of programmers, you operate with an engineer's mentality. You logically attempt to solve problems and even when you know something should work, but it doesn't, you keep at it and make the changes until it does.

However, you rarely do this when dealing with people who are less technical. You base something on technical/logical merit and don't understand why people don't comply when they may even reach the same conclusion. You have to keep at it. That doesn't necessarily mean sticking to this same problem. You boss will get irritated if you do.

Think about how you can approach these types of suggestions differently. You're going to have to sell the idea. Technical merit is not enough. Since you're not going to be very good at this, it is going to take time until you find the right approach and learn how to be persuasive.

Gaining this skill will be better for your career and sanity. Don't just expect everyone to think the way you do. Adapt and learn.


I generally don't consider it to be the responsibility of a manager to know every single technology in the stack. It's way more important that the manager knows how to... well... manage the team and get products out. It's unfortunate that he's pushing back against all this new stuff. Perhaps it's best to have an honest (non confrontational) discussion with him about it? In my experience, most managers won't really care what you use provided that it adds value. Sometimes a clear piece of documentation outlining the comparative benefits of what you want to use vs. what is already in use can help. Maybe it's worth finding out if he's one of those kinds of managers. Based on what you're saying, it sounds to me like he might not mind at all if there's an agreement in place and he doesn't have to deal with it.

With regards to the formats of your deliverables, is it really that big a deal if he only wants the HTML and CSS? Is it possible that you want him to adopt your stance so badly that you don't want to compromise on this (comparatively) small issue? If he wants the HTML and CSS, just give it to him. I'd personally avoid the deliverable format battle and save my political capital for something else.


I think you have some good answer but have a bit to had. Hopefully it adds value.

One it does not appear you boss is going to move and you are not going to make him.

Be happy with you can use the tools and he just wants the HTML and CSS.

It is not he does not understand your skills. He just does not want to learn something new.

It looks like your manager just plain has not moved for a while. A least it is not C but C# is just plain more productive. I think we can be sure HTML5 is not a fad.

Your Answer

