Forced to implement what I think is the wrong solution [closed]

Question

Should I listen to the Team Leader or stick to my position?

Here is some background:

This is a repost of this topic, as I think I've missed the site where I need to ask such questions. And I am not a project manager, I am software developer, but I want to ask project managers of their vision of my problem.

We are team of 3. I'm doing some feature, and while doing that I came to design A. One guy of our team thinks, that this feature should be done with design B. I think his design will produce many bugs in the future. I do not quite understand his position about design A. He just doesn't like it. But let's say he also sees some problems in design A to have the situation more clean. Team leader supports this guy, and is forcing me to do it with design B.

My position here: "No problem, but I do not want to implement features with the code I'm already see problems in. If you want to do it with design B - you can do it yourself". He thinks that this is my task, and only I am who should do it. Such situations always repeating, it is not the first time we came to that.

Am I right? Should I obey or stay with my ideology to the end? And should I consider job change in the future? This guy always cut down my designs, and never explains why, and the team leader always supports him.

Answer 1

There are a few options you might consider although I wouldn't choose any of them as a preferred one. It depends much of your context and it's your choice to be made.

1. Do what you are told to.

   I know many engineers who would simply reject to do the work in a way they think is wrong. Yet it is easy to forget that we work in a specific organization and we are paid to do the job which is defined by our superiors. I don't want to discuss here whether telling developers exactly how they should do their work is right or wrong, but as long as such constraints are set they should be respected (to some point).

2. Discuss it through with everyone interested.

   You don't go into details so I can as well consider that you've already done that and it hasn't worked, but anyway it is the part of the answer. Get everyone involved in a single room and go through the whole discussion once again. Be prepared though. If you can back your position up with authorities respected by everyone in the room (or at least by decision-makers) you improve the chances of making your point. Nobody is believed to be a prophet in his own town so if you're trying to come up with something new for your organization it may be really hard to convince people single-handed.

3. Ask for forgiveness and not for permission.

   If you want to take risks, just do it the way you want to do it, and then ask for forgiveness after the fact. Actually, such approach often yields creative results. On the other hand if you're wrong be ready to take responsibility. If later the feature needs rework be ready and willing to run an extra mile to do this, etc. Note: in many organizations such attitude isn't encouraged or even is considered misbehavior. The context is very important here.

4. Change the organization.

   You mention that it is a systemic problem - it happens all the time. I would actually try to challenge that. Why is it so that developers don't have enough space to make their decisions on low level design? Are there any good reasons for that? Again, you can back this challenge up with what's happening in IT business, e.g. concept of self-organizing teams.

5. Change the organization.

   And of course if you fail to change the organization the other choice is, well, changing the organization. You aren't a slave so if the way your company operates doesn't satisfy you leaving is always an option. Don't waste your life in an organization that frustrates you.

6. Challenge your assumptions.

   Last but not least, something that you should do, no matter which option of the above you're going to choose -- consider that it might be you who is wrong here. Maybe the guys are right and you can learn something. From what you write I expect you don't trust their judgement - that's OK. You still can bring detailed description to a problem to places like StackOverflow and confront the ideas with community. Rarely, if ever, there is only one good way of doing things.

Answer 2

I kind of understand how you feel now, but don't think about quitting just yet. If you don't have the necessary background to support yourself without a job, you'll have to look for a job before quitting and you'll have to work in the very same environment in the mean time. So it doesn't look like a win to me.

If I were you I would find out why the team leader supports the ideas of your colleague. It can be a trust issue, or something related to experience, or simply a personal thing. So, solving this issue may start with some discussions.

Working in a team means that sometimes you have to give up your ideas and cooperate with the rest of the members, although you don't want to do it, or you'll see that it will fail. A common reaction is to escalate and go and talk to the team leader's boss about the situation, but this won't solve it. It will make it harder in my experience, because if the case is a trust issue, then there's no way that they'll trust you after the escalation.

My advice is to work on Design A and try to make it happen, but don't forget about Design B. Put down the basic concepts and keep it close to you. If something goes south with Design A, you can immediately "pull it out of your hat", but please don't deliver it with the sub-content: "I've told you so". It won't help. You'll feel better, but the general situation will be the same or a bit worse, because you'll look like a "smart-ass".

So a quick summary:

1. talk to people and find out their motivations
2. prepare your design solution
3. cooperate and learn more about their solution and make it happen
4. show them your solution and be wise
5. do the steps above for a couple of times
6. if nothing changes look for a new job

Answer 3

"There is more than one way to skin a cat." I can say this without knowing what you are working on and either design: Both designs have its benefits, costs, penalties, and risk.

Since you are not in charge, your job is to design an alternative, conduct an analysis of alternatives, find risks for all of them, make a recommendation, then do what you are told and execute it as if your recommendation was the one chosen.

Then, take a strong look at your designs. Challenge them. Try to find what you are not seeing. If you are constantly in this position, while it could be political, it is most likely something about your designs.

Answer 4

I was once fired for sticking to my "design" from a big organization. A technical core appointed to evaluate it fully supported it but by then the technical issue had degenerated in to a political one and I had no idea how quickly all of it would reach a climax. The team leader opposing the design didn't even knew the programming language the system was being developed in but he knew some important people in the management and that eventually paid off.

Answer 5

This guy always cut down my designs, and never explains why, and the team leader always supports him.

(assuming that you have tried to explain situation to your team lead and it didn't help):

Start looking for another job. There is no reason why you should be stuck with people who do treat you like this. Perhaps, they would be much happier if (instead of you) they would have someone who would just follow the orders without asking any questions and you will be much happier somewhere else.

Answer 6

Since you're in a software development project the base guidance is CMMI Dev 1.3. Your team should have a formally approved document with functional and non-functional requirements ("REQM" process area). Every design decision should be made according with this document and in order to satisfy its requirements ("TS" process area). Every design decision should made with possible alternatives ("DAR" process area) - Design A and Design B in your case. Every alternative should be analyzed for its effectiveness according to formally approved requirements.

Looks like if your project all of these process areas are not institutionalized. Instead, your team management is biased by personal relationships between team members. This is the root cause of the problem.