5

Say there are two people working together. Person 1 has more knowledge and skills than person 2. Say person 2 suggests a way to do things. However person 1 sees a better way to do it. Person 1 explains to person 2 why his way is superiour. Person 1 uses his knowledge and skills to demonstrate that. Person 2 doesn’t understand it because he lacks some background knoweldge and skills. Person 1 starts a detailed explanation, but it took person 1 a long time to get this background knowledge, and he cannot explain everything to person 2 in that short time frame. Thus, in the end person 2 still may not understand it and may even perceive person 1 as argumentative.

What to do?

Option 1: Person 1 disagrees and does it Person 1’s way. Person 2 feels resentment. The quality of the product is better, but their relationship is worse. (aka bad team work)

Option 2: Person 1 agrees and does it Person 2’s way. Person 2 feels happy. The quality of the product is worse, but their relationship is better. (aka good team work)

Which is the right choice? Option 1 or option 2? Is there a 3rd option?

Improve this question
1
  • I'm Person 1...I get my way when it's important that it be right.
    – CaffGeek
    Commented Mar 28, 2012 at 21:02

6 Answers 6

Reset to default
8

I personally wouldn't feel the relationship is better if I contributed to putting out a crappy product when I know the solution is suspect. So option 2 -- going with a less than ideal solution -- is something I would have a lot of trouble with and might likely make me feel a bit resentful for having to work with someone who is unteachable.

With that said, it's important to pick your battles. Is this a critical crossroads in the project or is this something non-critical? Is this an area where it's okay for person #2 to make a mistake and learn from it or is this a mistake that could significantly bring down the project?

I would let the answer to those questions be your guide in deciding what to do. If person #2's mistake is something that can be fixed later, maybe let person #2 learn from it. However, if it's a really bad idea, then stick to your guns and continue to find ways to communicate the solution to person #2.

Part of being a great developer is learning from mistakes and having room to make those mistakes. It's a delicate balance between project success and individual growth.

Improve this answer
1
  • 2
    +1 I think this is the best answer - if the consequences are not sever let person 2 try it and if the poor result is not clear perhaps provide breaking use cases or show how it could be done better or. If this is not the case stand your ground. Always try to explain better first though (use tools such as breaking use cases, complexity analysis).
    – Danny Varod
    Commented Mar 28, 2012 at 19:34
3

Option 3: Person 1 and Person 2 discuss the problem/task/topic and possible solutions/ways as well the background. They choose together the best way to do things. The quality of the product is better, and they actually did team work.

My point here is that the persons in questions communicate and both of them will probably learn something from it. Both persons have a different knowledge set and will share their knowledge with the other person. So this option will not only find the best way to go about things, it will increase skills and knowledge.

Improve this answer
2
  • Your option 3 sounds like one of the stages prior to getting to either option 1 or 2. So either this has already been done or it has been done wrong. Sometimes the required background can be pretty vast. I suggest using analysis methods to compare the two and not just a verbal discussion.
    – Danny Varod
    Commented Mar 28, 2012 at 19:38
  • 1
    @Danny - Good points. However, I think Morothar's higlighting some very important points. Sometimes inexperienced people can still bring something useful to the table, so it's important for experienced people to approach the problem as a team and treat the coworker as a valuable unit. Of course, this hinges on person #2 also knowing his/her limits and when to defer judgement to the more experienced people.
    – jmort253
    Commented Mar 28, 2012 at 20:06
2

Have a meeting with Person1 and Person2 first separately and then together. If there is a chance that they may be able to work together, then give them what they need in order to do that.

Set a deadline for yourself, when you revisit the problem - let's say a month - and check whether they are on the right track or not.

If they don't show any sign of possible cooperation in the future, or after the deadline they still cannot work together, take one of them off the team.

For me the team's integrity values more than an individual. I'd rather work with a good group, where there's only average developers than with an inefficient group where there are a couple of "heros" and "wizards".

Improve this answer
2

Neither is an option. These are more signs and symptoms of a team that has not yet matured. It is a classic description of what occurs during the storming stages of team development.

So, you need to look at teaming basics: role description with boundaries, rules of engagement, increased control on tasking, more of an authoritative stronghold by the team leader than what you would have later on, etc.

If your team is exhibiting these kinds of things, you are not yet a team.

Improve this answer
0

Yes, I agree with David Espina here. A good PM will resolve this by carefully manipulating a meeting - that is, question both (not interrogate) in the nomal way, play the dolt if necessary to get them to explain in a way that you as a (supposedly) less technical manager can comprehend, this is a great way for them to explain to eachother the merits of what they are thinking. I spent over 20 years as a developer, I am pretty experienced and it can be annoying when someone comes in at the same level and does not understand to the same technical level - its just human nature. Explaining to someone that should know/understand is one thing, explaining to the boss who is not as technical is another kettle of fish. Fresh minds often do have something to bring to the table, sometimes what sounds great is just unworkable in the long run (we have all seen this!) and the long-in-tooth guy may pick up on this before the e3xpense of discovery halfway down the line. This surely is the most important part of a PM's job, controlling his/her team, keeping production up, but balanced with morale and in the long run, making the deciding decision when the ball's in his/her court. Worse case scenario, get a third ear in on it, another techie (hopefully one they both respect) and let them pitch their cases. As to letting them fail as a learning experience, I'd not. Failures will certainly come - as will experience - I do not want the rest of the team to suffer for one person's training session - and that goes double for my users and my management.

Improve this answer
0

Have you considered using code reviews? Let weaker developer do their job. Review their code and give them structured feedback. Give them time to make changes based on your feedback and re-evaluate their deliverable. If after a certain period of time you start seeing improvements, then you are on a right track and weaker developer will eventually get better.

This is assuming that weaker developer fully understands that he is less experienced and he can take all the structured criticism.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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