The Unexpected Danger of Typecasting in Engineering Teams
Does this sound familiar?
Your team has a Wizard programmer who solves hard problems but lacks follow-through.
Or maybe a Firefighter who only delivers under pressure.
Or maybe you have a Front-End programmer who “can’t figure out SQL,” or a Lone Wolf who insists on working in isolation until their code is perfect.
These types of programmers can be great… but they can also drive you crazy. If you’re like me, you’ve found yourself wishing they were less stereotypical and trying to figure out how you could get them to act differently than their “native type.”
Maybe you’ve also thought, “But what can I do? That’s just who they are. A leopard can’t change its spots.”
I used to think that way, too.
But after fifteen years of leading software teams, I’ve come to recognize that it does more harm than good to typecast programmers.
The surprising danger of typecasting
The biggest danger of typecasting is that it limits the feedback you can offer members of your team.
After all, you wouldn’t ask a leopard to become a lion.
Or a hearing-impaired person to “listen better.”
You wouldn’t ask me, who stands 5-foot 5-inches tall, to become 6-foot tall.
Asking those things is both pointless and offensive. They are characteristics that cannot be changed. Our culture is very sensitive about offending people. Suggesting that people make any change always risks offending someone.
But when your Wizard flounders with the “boring” parts of a project, or your Lone Wolf avoids collaborating on a feature, it’s not because they can’t do those things. It’s because they won’t.
The reason they won’t is simple. Past situations, environments and people taught them how to act. We learn from experiences, finding what leads to success (or failure!)
Okay, once again.
- Your Wizard can learn to successfully work on boring projects.
- Your Lone Wolf can learn to successfully collaborate.
- Your Firefighter can learn to successfully plan their work.
- And anyone who can learn *#&^$ CSS can certainly learn SQL!
Each person can learn to change, but they need your help to do it.
Think back to school
You help them by giving them feedback, not by keeping silent.
You can do this by coaching with words like:
- “I know you can do this.”
- “Here’s how you can approach this.”
- “Here’s how your team would benefit.”
- “Here’s how you’ll personally benefit.”
- “Let’s talk about one small step you could take.”
But as long as you believe “that’s just the way they are,” you’ll not ask them to change.
Think about your favorite teacher in school.
When you struggled with a subject, did they say, “Oh, you’ll never figure it out. You’re just not a math | English | science type”? Probably not. Instead, they probably said, “Keep practicing. Don’t give up. You’ve got this.” They knew that the material could be learned by anyone who applied themselves, not just by certain kinds of people. These teachers were probably your favorite because they pushed you to be better, and they believed you could achieve more.
In her book Mindset, Carol Dweck, Ph.D., describes two distinct mindsets that impact how we see ourselves: the fixed mindset and the growth mindset.
Someone with a fixed mindset sees limitations. Someone with a growth mindset sees challenges.
Someone with a fixed mindset believes if they are good at something, it’s because they were born that way. Someone with a growth mindset believes if they are good at something, it’s because they learned through effort and practice.
Your job as leader, manager, and coach might be to believe what the other person does not believe. To envision what they cannot yet see. You need to have a growth mindset about your programmers, even if they have a fixed mindset about themselves.
Personally, I’ve found that people who believe in me have a tremendous effect on my belief in myself. Have you found this as well?
They didn’t type themselves, you did.
While some people will loudly declaim about what type of person they are, your team members (probably) didn’t label themselves with these types. In fact, they might not agree with them at all. In that case, you may have developed a fixed mindset about them. In this case, it’s you who needs to change perspectives.
It’s easy and convenient to see people through the lens of stereotypes, and it appears useful at first. After many months of unsuccessfully prodding my Wizard to finish a project, I approached my boss about how to handle the issue.
My boss told me, “Jim is a Wizard, and you need to keep your Wizards happy. Give the project to Jane to finish, and let Jim play with something else. You don’t want a team full of Wizards, but you do need one.”
It’s easy to imagine that great software teams are assembled from a combination of types, like a recipe, and that all you have to do is find the right proportions:
2 Lone Wolves
Unfortunately, not only is that silly, it’s harmful.
Yet I’ve personally talked to hundreds of engineering leaders who, when trying to figure out how to deliver a late project, resist the idea of asking someone to work outside the type they have cast them into. “I can’t ask Jane to help deliver the front-end, she’s more of a Wizard.”
Of course, they can ask Jane to help deliver on the front-end, and Jane may do a great job. But they never know because they never ask.
Types are not strengths
Some leaders confuse types with strengths. Strengths-based leadership, popularized by Gallup, is not the same thing as typecasting. Each person brings strengths and weaknesses to a team. Leaders who only play to people’s strengths never give them the opportunity to grow. People grow when their team allows them to use their strengths and challenges them to improve their weaknesses (and supports them in doing so). The acknowledgment that no one is perfect and everyone brings both strengths and weaknesses to the table creates an environment where it is safe to work and learn. Perfection is not expected, but growth can be achieved.
In the same way, some leaders confuse types with communications styles. Communication styles are formed early in life. Personality tests, such as the DiSC Profile, may help teams understand each other better and improve internal communication. Yet these are very different from harmful programmer stereotypes that prevent us from offering constructive and truly useful feedback.
How to begin
If you have withheld feedback because you’ve typecast someone, it’s time to think again. Start by considering your own expectations:
- What unspoken expectations do you have of them that you don’t have of others on the team?
- What unspoken expectations do you have of others that you no longer have of them?
- What opportunities could you give them to grow in a new direction?
- How can you reset your expectations, and possibly their own, and encourage them to think outside of their type?
- Is it time to apologize for typecasting and clearly discuss your expectations?
While the trends of micro-specialization may continue in the job market, you don’t have to continue to typecast your team members. Instead, discuss and negotiate expectations with your team and provide opportunities for them to grow.
With your coaching and encouragement, your programmers can do the best work of their lives, which will make you the best boss they ever had.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.