Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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.

share|improve this question

closed as primarily opinion-based by jmort253 Oct 17 at 3:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Next time you cross post a question, please remove the one on the other site after posting on a new one. It helps to avoid the noise. Thanks! –  Pawel Brodzinski Jul 5 '12 at 10:51
    
This isn't really a project management question, is extremely localized as currently posed, and should probably be closed as it solicits subjective answers. –  CodeGnome Jul 12 '12 at 19:02
    
For now, we're keeping this open as an experiment on our site scope changes. See meta.pm.stackexchange.com/questions/369/… and Project Management Meta for more details. –  jmort253 Jul 13 '12 at 16:07

6 Answers 6

up vote 14 down vote accepted

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.

share|improve this answer
1  
I like the list, and want to add that before thinking about "which option do I want to take" is to consider what option mostly fits the current company organisation and culture. Especialy (3) can get you promoted in one company, and is a sure way to get fired in another. YMMV –  Huibert Gill Jul 5 '12 at 10:14
1  
Thanks! Really nice list, and It makes me think about my actions a lot. –  Archeg Jul 5 '12 at 12:05
1  
+1 for the thorough answer. @Archeg I would weigh the pros and cons of each solution (option 6), discuss it (option 2) and if I am sure I am right, go with options 3+5. Software engineers aren't supposed to be soldiers that just follow commands. You boss should trust you to work without micro managing you, or fire you if he doesn't think you are capable. If your boss isn't smart enough to understand that, quit. –  Danny Varod Jul 6 '12 at 1:23

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
share|improve this answer
    
Excellent point on working with the team. Being in a team means not always being right or being right and not being in the majority. A decision was made, you should find everyway to make it work. If it doesn't, don't ever say or even imply "I told you so." Just buckle down and help the team solve the problem. –  Joel Bancroft-Connors Jul 5 '12 at 15:41

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

share|improve this answer
    
I'm always try to think much about my design decisions. I like solving puzzles, and I'm not the guy that sees only his view and not the others. There were some cases when I understood that I'm wrong, and I'm open to that. But as the experience tells, I'm mostly right. And doing the thing that I'm told to do... I can do that, but I will be very unhappy about that. It is like being in an army. It's easier to just change the job. I didn't have such problems on my previous jobs, so I assume the job is the issue but not me (I'm not saying that I'm fully right - I'm saying that I'm not fully wrong) –  Archeg Jul 5 '12 at 12:15
1  
You may be right about your designs. Either way, however, you need to execute per your orders, as that is the way you will want it when you are the one accountable for the design. You need your team to be an extension of you. You want them to advise, but then execute at your direction. –  David Espina Jul 5 '12 at 13:22

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.

share|improve this answer
2  
Hi @SamHouston. Welcome to PMSE. It would be great if you could expand your response to answer the question more directly. Based on your experience how do you think the questioner should proceed? –  Willl Feb 1 '13 at 10:48

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.