How to deal with a boss who is resistant to new technologies and project solutions?

Question

Summary: How can we, senior developers, deal with a boss who almost always prefers to apply his own way of coding, structuring projects and introducing or using technologies despite of risks and ignoring benefits from new ways?

---

I work in a small IT company with around 10 employees (our boss, 3 senior developers including me, and other juniors) focused on web development. We all know each other well and also have a good relation with our boss. The juniors report to us seniors or directly to the boss, depending on the project.

Our boss is a former developer who started on his own and now, with a growing company, is taking care of project solutions, management, sales and customers. He still codes sometimes, but it is not his main role anymore.

The main problem we, the seniors, have with him is how to deal with his way of thinking about technical solutions, coding and technologies, and being substantially forced to adapt to them.

In those situations he always prefers to keep the things "the way he knows" ignoring the risks of his ways and the benefits of new technologies, programming patterns or software architectures we present him. I'll try to explain with some examples:

• When structuring projects, he does not take in account several critical and basic steps like secure coding, server side checks and stress tests, due to his background in developing small and client side desktop applications.
• If you point out a flaw in a project that makes the initial development faster, but will create a lot of problems or heavy refactoring later, he ignores the solutions we propose if the required time is even a little higher or if he cannot understand the logic behind it. When the problems emerge later, he asks for fast solutions rather than fixing the issue once and for all.
• When a junior asks his help with coding instead of ours when we aren't available, he suggests wrong and dangerous solutions and approves the merge requests himself, despite we having made clear that his code is prone to heavy security issues. If the juniors point this out as we taught them, he says things like "Why do you want to be so precise, are you (one of the senior)? We need to resolve this issue fast."
• He is very resistant in introducing automated builds and tasks in general, even for our test environments, saying that "is easier and safer for the developer himself to take care of those tasks" and "what if you are not available and something happens? no one knows how to deal with those things"
• When we discover and discuss changes in our framework or projects, that somehow will also change the coding pattern (even a little), he almost always rejects them saying things like "Why do we need to change the coding style? I cannot understand the new way"

The company is going well and nothing really bad happened until now, but we are growing concerned as we are acquiring bigger projects and customers, and also think we could do way more tasks adopting some of the technologies mentioned above.

We also, in some way, understand his way of thinking (aptitudes, keeping costs down, responsibilities) but we also believe it is not worth being limited and staying on the edge by continuing this way.

What we already tried:

• Bring solid evidence of the benefits and almost no drawbacks our changes will bring (faster coding, reducing errors, less tickets etc...)
• Point out the consequences of poor and unsecure coding (data theft, privacy issues, unauthorized data access etc...)
• Show him that the time spent on bug fixing and support tickets is way higher than the estimate made for the "clean" estimate that would have prevent them.
• Make a clear documentation for our code, projects, procedures and automated tasks

Question: what is the best way of communicating with our boss to make him understand that, as we grow, we need to think in advance, keep pace with technologies and put more attention to tasks with no immediate cost benefits?

Answer 1

What is the best way of communicate with our boss, dealing with this situations and make him understand that, as we grow, we need to think in advance more things, keep the pace with technologies and put more attention in tasks with no immediate cost benefits?

Sounds like what you've done so far is reasonable.

The only other thing would be to make sure you and the other senior developers continue to discuss what you feel are better methods. Perhaps you can be convincing enough to at least ask for a trial project to see how it goes.

In the end, he's the boss, and he gets to decide how things are done. If nothing changes, you'll get to decide if you want to go along or get gone.

Answer 2

Your boss was a decent programmer in the past. Nowadays he's a better businessman than programmer. The things you list are classic business / engineering tensions: concrete revenue tomorrow versus abstract and stochastic risk over months and years.

Honestly it sounds like you've made a good engineering case, probably because the boss himself was technical. Some other lines of argument that are worth trying:

• The firm has done what it takes to have 10 employees and x clients with $y revenue. What will it take to grow the firm to x^2 clients and $y^2 revenue?
• Delegating more technical responsibility, including true technical and architectural leadership, gives the boss more time to focus on growing the firm.
• Ensuring his engineers are up to date, and ensuring junior engineers are trained well. Making sure there is an interesting technical career path for staff. Not to put too fine a point on it, that includes your career progress.
• More technical infrastructure and ongoing maintenance has to be expected in a larger, more established outfit.
• A larger firm means greater business risk to the entire firm when there are security or performance problems. How many clients will leave after the first one impacted, once word spreads? Won't it seem stupid that a two line patch by a junior programmer lost the firm $300k because there was no regression tests?

The boss will rightly be worried about engineer failure modes like excessive complexity, bikeshedding on tools, and goldplating versus doing minimum viable products. You need to show ways these would stay under control, so that he can trust the time spent on these things isn't wasted.

On top of this, if you can quickly show there are other shiny technologies out there that you think don't make sense for the firm, you will be showing more mature technical leadership. This isn't about putting Ruby On Rails on the blockchain. There is a certain rhetorical trick here: you can pick some architecture astronaut technology like the Metaverse and use it as a bit of a joke, which shows you have a healthy sense of perspective, but also makes other technical change seem a reasonable middle ground.

Lastly, from your description, senior developers are 30% of the company, and probably 80% of the technical contribution. It's a very hot market for developers. You have built and are building this firm. If you want to put the case for change more assertively, the three of you are in a strong negotiating position.