How do I promote better development practices when facing management opposition?

Question

I've struggled to think of an appropriate way to phrase the question, so forgive the ambiguity of my title, but here's my problem:

I work in a department run by people without varied experience. Some have none, but provide direction regardless, others have experience managing only in this department and never anywhere else. The net result is that we do things in a very narrow way, exactly the way that my head of department wants, and never with discussion. As a developer with less commercial experience, I'm expected to follow the lead and do as I'm told. The problem is, very often I'm expected to do things that that I can see will introduce bigger issues later, for example security vulnerabilities. I can often justify a better way of doing things, but I am told "I want it this way..." and am expected to fall in line.

In theory, they've every right to be telling me how to do things, because it's their department, their rules. But I'm strongly inclined to refuse to just do what I'm told, particularly if I can justify better ways of achieving the same objective.

I've tried reason, I've tried education, nothing seems to work. How do I carry on working in a "better" way, but without being insubordinate?

Answer 1

Do what is required of you, first and foremost. If you can't, it's time to update your resume and move on. Rebelling against shop standards is not a hill you want to die on. It will give you a bad reputation in the industry.

If you are convinced that there are better ways of doing things, design them on your down time and then demo them to your superiors when you have a chance. I assume you're young and fairly new to the industry (less than 5 years). If that's the case, you will not be taken seriously by the more experienced people on your team unless you can actually show them something.

In theory, they've every right to be telling me how to do things, because it's their department, their rules. But I'm strongly inclined to refuse to just do what I'm told, particularly if I can justify better ways of achieving the same objective.

This is a big red flag to me, because 1) It's not theory, it's reality. You are not the one who will be held to account when things go wrong. 2)It demonstrates a bad attitude on your part.

For the sake of argument, I am going to take everything you say to be absolute truth:

Shops need to adhere to standards. I would take a mediocre coder with a good attitude any day over a highly skilled coder who is willing to ignore the rules because he knows better. My other coders won't be able to maintain the code, and the highly skilled coder is employing new ways of doing things that the rest of the staff will be completely unfamiliar with, requiring retraining, expose the company to risk, as the old staff will be in unfamiliar territory, and thus prone to make mistakes.

Given all that, the highly skilled programmer would not be an asset, but a liability.

The simple answer to your question is that you do back down. It's not your place to oppose the company's shop standards. Get more experience, rise up in the company, do some development in your down time and demo it if you're that confident, but do not disrupt the shop standards because you have ways of doing things you believe are better. Even if your methods are better, they will be a disruption. Convince management through authorized action, not disruption.

If you are concerned about being told to do things in a way you feel are wrong, create a paper trail. Do what you are told, but send an email stating your concerns. "In implementing this, I have the following concerns..." then lay them out. If they say do it anyway, it's on them.

Answer 2

In your question, you mention several times that you are in strong disagreement with some of your orders. Quoting you : I'm expected to do things that I find to be either dangerous, stupid or otherwise wrong for whatever reason. You also mention that you have a lot of good, better ideas, but that more experienced people do not want to listen to your advice.

However, I can't find a mention of you asking anyone why are they doing these things this way. You mention being less experienced, but you do not mention trying to understand their point of view.

You should start by placing yourself in the shoes of whoever is giving you the order. Why are they giving you this specific order ? If you can't understand why, ask them. People generally don't mind explaining their reasons when asked, especially as a junior less than 2 years in the company. But saying "I disagree, here is my opinion" will most likely bring an answer along the lines of "I did not ask for your opinion" especially again since you are not a senior yet.

Your role as a junior is not to enlighten your seniors, it's to understand how the job works to be able to perform later on, and it starts with small tasks.

EDIT : Your comment comforts me in the analysis that you do not focus enough on understanding before trying to improve things.

To give a recent example, "I want us to be able to change this more easily in future." When I pointed out that doing so introduced a way for us to make an uncontrolled change that might cause issues further down the line, I was told that it didn't matter, do it anyway.

You seem to jump to solutions too quickly. Listen and try to understand why people are asking what they are asking. You are not asking "Why?", you are asking "Isn't this better?". This is a common flaw when you think you know, but you still have much to learn. I am not saying you are unskilled, but I believe you are still inexperienced.

Answer 3

I'm expected to follow the lead and do as I'm told. The problem is, very often I'm expected to do things that I find to be either dangerous, stupid or otherwise wrong for whatever reason. I can often justify better ways of doing things, but I am told "I want..." and expected to fall in line.

You should just move on. I have been there, people work at a company for 15+ years and don't see the need/benefit for change so they will go on how they always have done it.

But I'm strongly inclined to refuse to just do what I'm told, particularly if I can justify better ways of achieving the same objective.

If you refuse to do the work, they could report you to HR. You need to suck it up and do the work

I've tried reason, I've tried education, nothing seems to work. How do I carry on working in a "better" way, but without being insubordinate?

You can't fix this. If they aren't open to change then there is very little you can do. You could wait for a major bug caused by x and then cite that you mentioned "Y" a while back that could have fixed this, but it won't improve your working environment.

Dust off the suit and get to a place where your input is wanted and appreciated. These sorts of places exist. Just try and work out through the interview process if the next team is like that. Ask about methodologies (Agile, Scrum etc) and try to gleam if they seem more receptive to input from all levels.

I would say though, you still are a junior developer. You may be very capable, but you do still lack experience. Bear this in mind in the future as something that "theorectically" is better, may not be so much in practice, or may raise issues with code maintainability etc in the future.

Answer 4

No, by "dangerous" I mean things that are either directly causing, or could lead to, vulnerabilities in our software system. I'm in the UK. – comment by Ashilta

If you know that there are ways to correct liabilities, write them down, compile them in a list of problems and possible solutions with references to online documents/practices/technologies and present that compilation directly to the manager.

Your intentions seem appropriate, but the more you push your ideas to your workmates while they have no knowledge at all about what you are talking about, it is just natural that they will push you back in a reciprocal way. It is also natural that a department which has successfully accomplished work in the same way for a long period of time resists change.

Instead of justifying what you believe is wrong and right by speaking to them, if you haven't pushed too far already, wait for the manager to read your compilation and let him/her realize that it is in his/her best interest to solve the vulnerabilities you pointed out. He/She may willingly schedule training sessions to the entire team in the practices/technologies that the department chose from your references in order to solve those vulnerabilities.

Answer 5

It's your manager's responsibility to weigh risks and perform cost/benefit analyses. I can fully accept that your methods are "better", but it's your managers responsibility to decide if they are "better enough".

To use your recent example, your manager seems to have decided that the benefit gained by allowing easier changes in the future far outweighs the risk of introducing the ability to make an uncontrolled change that might cause future problems.

Do not let the perfect become the enemy of the good.

Answer 6

This should not be a matter of force.

As an engineer, you may know more about the technical aspects of the software, but your management knows better how that software creates business value. To maximize the benefit of your software, which is business value minus development cost, both aspects must be considered.

If you were to make these decisions, would you know what management needs? Your management does not seem to think so ...

On the other hand, if management makes these decisions, do they know what you do? After all, if management doesn't, results can be rather spectacular.

For better decisions, you can strive to learn what the business needs, or communicate your pertinent information to management. I recommend doing both.

To learn what the business needs, ask your manager (or the customer) for feedback. If they make surprising decisions or statements, ask "why" to understand their reasons (of this is not received well, try clarifying you're asking only so you can help them reach their goals better).

To communicate pertinent information to management, phrase it in terms they can understand, and show them how it impacts their goals. So don't say "this is kludgy" but say "This will likely enable hackers to steal the credit card numbers of our customers". Also try to suggest alternatives.

If it is a serious matter, inform them in writing, so you can prove you did your duty if things go south.

In any case, refusing to do as your boss directs will undermine your working relationship to the point where either he or you will have to leave. Usually, it'll be you.

Answer 7

I've experienced what may be a similar situation in the past:

We were tasked with performing a task and, after hearing how we were expected to implement the solution, I asked why we were pursuing that direction instead of following industry standards. The response I got was "That's the right way to do it normally, but in this case, this is better. Trust me."

That didn't seem to be the case to me, but I did what I was told. I also continued to ask why and suggest alternate solutions to problems... via email when I wanted to make sure my dissent was recorded, but I continued to do was I was told. In some spare time I wrote a solution for one of the problems I expected our current code would encounter.

Fast forward a month, and that problem came up. And, as the junior software dev on the team, I was able to say "I have a solution I can submit for code review right now that fixes the issue." The result of this is my direct supervisor got praise because the problem was almost immediately resolved, and he knew that I am the one who saved his butt.

Fast forward another six months and now we're well on our way to practicing those industry standards, because I've proven that they work better.

Ultimately, you only have a small amount of rudder you can apply to where this boat is headed, so pick your battles and choose battles you can win: You won't be able to alter the development paradigm as a junior developer. You, as a deck swabbie, don't have much say over where the boat is headed -> but you can influence those who do.

There is an interesting book you may want to look into, called The 360 Degree Leader, by John C. Maxwell, that offers advice on how to sway people who don't answer to you. I'd recommend reading it: I used it during my time in the military and at every job I've had since.

The single best takeaway/strategy from that book: if you can convince them they thought of an idea, you've won the battle before it started.