What is the most effective way of dealing with overbearing "know it all" developers?

Question

Just to clarify - I'm talking about a Scrum or Extreme Programming Team here not the old-fashioned command-and-control team from the waterfall era.

These are what Fred Brooks would call have called "democratic teams" in the 1970's and what Scrum people today call "self-organizing teams".

... one of the most difficult things to deal with on a project is the "know it all" developer.

Often they say things like "oh, I know" and when you look at the reams of code they've committed - you're sure you've seen enough evidence in there that they don't.

There's a particular problem when these over-confident people guess answers and assert them confidently - because it forces us address dead ends.

Two problems arise:

• How do you encourage them listen if they think they know it all?
• How can you encourage them to participate in teamwork rather than just insisting on their own way?

I'm looking for constructive solutions. Often these people are smart and would be worth collaborating with - if only they were playing the team game.

Answer 1

If they don't know (as stated at the beginning of your question) find out why/how they do the things they do, maybe then they can see why they're wrong.

If they're possibly right, a quiet conversation from a superior (or respected team-member) can do wonders.

Answer 2

Do you do pair programming enough? Team dynamics are not right, and other members in the team should be able to stand up to them.

This can only happen in a team where the know-it-all is accepted as such. You might want to ask all team members individually about the four values of the agile manifesto, and how they interpret them as they apply to your project. There might be interesting differences in response.

Answer 3

I'm dealing with a similar personality type at the moment. We've coped thus far by taking advantage of the fact that 90% of the time spent during our average meetings are wasted anyway, and having little informal "meetings" in the tea room and other places to agree on what to do and then just go off and do it.

The same tactic extends to directives from higher ups when it's clear they're wrong or just plainly don't know what they're talking about. For instance, we're constantly told not to fix or refactor anything in our apps no matter how bad it is, in order to concentrate on new features and pandering to important personalities. But, wherever possible we just extend our time estimates and fix it anyway. Management don't want to hear it, but this has saved them from looking foolish on many an occasion.

So, for me, the pragmatic approach is to accept that you're never going to make a dent in a know-it-all's armour of self-absorption and self-deception, and even if you do they're just as likely to try twice as hard to compensate, so just go around them quietly and without fuss.

Answer 4

In Scrum/Agile terms, this person is causing blocking issues, so the scrum-master needs to resolve the issue (i.e. the person) and ... get them off the team.

If the scrum-master doesn't have the power to reassign this person, then they should raise the problem with someone who does.

Removing them from the team should, in theory, be fairly straightforward. Collect evidence that illustrates how they are blocking progress: this could be the inability to pair effectively, poor code quality, refusal to adhere to proper process, and so on.

The downside is that during the evidence collection process the team will have to work fairly closely to a standard well-defined set of rules. This is rather against the Agile spirit, but if you really have a toxic colleague of this sort it's worth the effort.

What is critical is that the situation is evaluated critically and unemotionally, ideally by someone outside the team.

And if you don't get management support... then I'm afraid it's time to sharpen the CV!

Good luck...

Answer 5

This is one of my favorite Zen stories:

Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.

Nan-in served tea. He poured his visitor's cup full, and then kept on pouring.

The professor watched the overflow until he no longer could restrain himself. "It is overfull. No more will go in!"

"Like this cup," Nan-in said, "you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?"

Maybe it's time to serve some tea (as there is just no way to teach anything to people who don't want or aren't ready to learn).

A bit more seriously (actually, the story above is serious), if you think that this behaviour is slowing down the team's velocity (because of bad team cohesion, lack of skills, rework, etc), then this is an impediment and the ScrumMaster need to handle this situation as such (and this may end up with replacing members of the team). This is at least what Scrum common sense teaches us.

Answer 6

You could start by plunking a copy of Exploring Requirements down upon their desks or any suitable conference table. Personally I think Are Your Lights On? by the same authors is a far more approachable and entertaining volume which still covers the same salient material.

The difference between knowledgeable and being an overbearing know-it-all seems to be at the heart of your question. The heart of the solution lies in clarifying the customer/provider relationship and emphasizing that the job entails fulfilling the customer's requirements.

On the most crass level the customer (or project sponsor, for example in a larger organization) is the party who ultimately funds the project and makes the paychecks possible. Prima donna programmers might not deign to acquiesce to such overtly authoritarian pressures. They can enjoy their time on the rolls of unemployment writing their own superlative pronouncements about the stupidity of management and the obvious ignorance to the superiority of their code (et cetera, ad nauseum).

Of course there are cases where the customer is expressing erroneous requirements. For example he or she may be explaining how something should be accomplished rather than describing the results to be obtained and the interfaces though which they must be accessible. The customer may be asking for things to be done in a manner which deviates from industry standards or legal requirements. Possibly they'll ask for something which is computationally infeasible or asking for a production ready system to implement something which is currently on the bleeding edge of academic CS research.

In such cases the meta-requirements for a lead programmer involve those squishy "soft" people management skills. Such situations call for social engineering. The "requirements" may need to be restated in ways which fulfill the essentials while remaining agnostic regarding orthogonal details (divorcing the what from the how). The customer may need to be educated on some domain specific standards, regulatory requirements or limitations in the state-of-the-art.

But, I'd start with the first book to which I linked. It's a hardbound and should make a satisfying thwack on the table when it's slammed down with a little force. Then pass the other title (softbound) around to your colleagues.

Answer 7

My perspective is a little different. It won't work if those involved are too set in their ways, but....

I would suggest that you focus on redirecting that passion constructively. Keep them fed with cutting-edge ideas and projects , then when they get het up about them, insist they implement them or study them in depth. Encourage their passion and make sure that when they screw up, they screw up in a way large enough that they won't do it again. That is to say, give them honest experience to back their blather up.

Manage them into being people who have a huge knowledge base and want to share it. I think that is much more constructive for all than seeing them as a "problem child" or "someone who sticks up and needs to be hammered down".

Answer 8

Avoiding conflict sounds like your problem. If you continuously find them in error, the rest of you need to tighten up your chin straps and openly disagree. You never mentioned their reaction when it is shown they are incorrect. Do they continue to disagree? Being part of a team means you stand up for and defend your opinion. Maybe the debate can be left to the few members who disagree, so you don't waste everyone else's time. Somehow an environment has been created that lets them get away with this.

Answer 9

Some of these are easy to do and others may be hard, but I'd give these ideas some thought and see what could and couldn't work for you. From "How to Win Friends and Influence People:"

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone they are wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to other people's mistakes indirectly.
3. Talk about your own mistakes first.
4. Ask questions instead of directly giving orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give them a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.