You grow when you teach others. You also grow when you ask for help when you’re stuck.
We need to teach students to accept both sides of being humble.
In the software engineering courses I teach a certain student often turns up. This person is self-confident and knows what they are doing in the programming aspects of developing an application. At the start the team finds this person useful. Later, this same person causes problems for the team. Yes, you read that right. Good at first, then they become a pain point. What’s going on?
Being the expert problem person
This student knows the coding side of software engineering. The person quickly takes the lead on deciding architecture, framework and other aspects and points people to useful examples, to carry the work further. They often do a lot on their own. At this point, two versions of the person appear: Type A will stay in control and keep overseeing the team’s work. Type B will start to step back and take less interest in the work.
Type B figures they did their work, and will stop contributing to the team’s effort. This person figures they did ‘their bit’ and that’s sufficient to pass the contribution component of the course. Appeals for help from the team are often ignored, and the person doesn’t turn up for meetings either.
Type A will keep contributing. In extreme cases this person will rewrite other people’s code in order to bring it inline with their beliefs about what the code should look like. Less and less code will be left over from other team members, as the person spends ever more time making decisions without the team and rewriting the codebase.
The curse of the expert
As you probably noticed neither type A or type B really collaborate in the team. They are the ‘expert’ and use this status to bolster their self-esteem.
B does what seems obvious based on their experience and then stops helping. They did a lot at the start. Anything the team learns about later isn’t taken into account. Their work might prove irrelevant, or wrong when the team knows more.
A keeps making more work for themselves, and thus gathers more stress too. This isn’t good for them, and the team feels more and more discouraged too as they are ignored more and more.
The really sad part is that I’ve encountered Type B as a ten-year old and had developers tell me about forty-year old people like this in their teams. This is not a good place to be.
Experts need to become collaborators
In our classrooms we need to show these experts that they need to learn to become team collaborators. Yes, they do great on their own, but now they need to practice their professional skills and collaborate. By collaborating they will learn to share their skills, and thus reduce their stress. This will also help their team.
We need to show them that while they spent lots of time learning their skills, not everyone had the same opportunities, or interest that they did. We should create a time and space for them to learn more about their fellow team members. Encourage the expert to share their love of the topic with the rest of the team.
The excellent Coke Mentos comic from XKCD tells it all.
The expert and the non-experts
On the one hand, experts are surprised that people are unfamiliar with something they have known about for ages. The bad response in this scenario is to be arrogant about it and to hold it over the other person. The good response is to enjoy their excitement as you show them this stuff.
On the other hand, the team members who are asking for help might be nervous about asking for many reasons. There could be cultural, age, and social issues which make it harder for the person. Whatever the case, the team expert should empathise with this. There will be areas, such as collaboration where they are less skilled, that will appear as time goes by.
Teach students to be kind to the person asking the question. One day it will be them asking the question, as they move onto new topics. They will want to set a good example of how to help the other person.
Apply this in your classroom
I have dealt with this situation in a few ways over the years. I try to address it in a few broad approaches and then more targeted as required.
First, create opportunities for teams to build empathy and familiarity with each other before they know too much about the application they are building. This provides space for them to find shared interests beyond the work they’re doing, which should reduce the ‘expert’ barrier.
Second, point out to all students the benefits of doing the work together as a team, or in pairs, instead of as individuals. This makes it easier for experts to share their skills with one person instead of everyone.
Third, if necessary have one-to-one discussions with the person and point out that this path is (a) not good for them in the long term, and (b) will probably not help them the way they envisage in the short term either. The team will disintegrate in the worst case, and divide into two with the expert left on their own as the more likely outcome.
Teach all students to be humble; that it’s ok to ask questions, and that experts grow when they share their knowledge.
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form, or follow me on LinkedIn