Overcoming Introversion
The story of a brilliant engineer who learned to work in a team
In this first article on the soft skills required to effectively manage an engineering team, let’s look at a real life account somewhat fictionalized to protect people’s identities.
The rising star of Unikorn Inc.
Eddy liked to work alone. He completed his Computer Science degree at one of the top universities in Hong Kong with flying colors, and joined Unikorn straight out of school without even taking the almost mandatory end of studies holiday trip with his classmates.
He was nervous during the interview but his qualities shone through. Soon enough he was helping out on different core features for both the Android and the iOS client app, though he somewhat preferred Android as “there is nothing like the source code to understand how the OS works”, as he liked to say.
He had a great sense of ownership, meeting all deadlines he agreed on even if it meant staying in the office till late at night. All of his work was always completed on time and with good quality. This was especially impressive for a junior engineer, and we thought we found a rare star.
However, what nobody seemed to notice was the frequency of the late nighters he used to pull. Initially, he spent maybe one or two days towards the end of a sprint to tidy up things before release, but after a while it seemed that he was always in the office before everyone else and the last one to leave.
What was happening to Eddy? Was he just bad at estimating his work? Was he biting off more than he could chew? We had to observe him more closely.
Socialization with the rest of the team was good initially. He would join the office banter and had a good sense of humor. At lunch, he would usually grab takeaway with a variety of teammates, unless he had some work he wanted to finish in which case he would go downstairs later by himself. He also played card games with the rest of the team after lunch at least twice a week.
Work-wise, his interactions with the rest of the team were somewhat more restrained. You would hardly see him reaching out for opinions, and in return he was rarely approached, also because he always appeared very busy. Over time, as he got even busier and more involved in his work, his social interactions started to degrade as well, becoming more infrequent and standoffish.
We couldn’t figure out why, until he screwed up pretty badly on a task.
The turning point
The assignment was pretty straight forward, or so we thought. Eddy had to investigate three libraries and propose the one to use in a core component to access a third party service.
The libraries were selected by the technical architecture team from a quick precursory investigation, mainly via online searches. They matched the company’s legal requirements which were unusually strict.
Eddy was pretty possessive of the task as it was his first research endeavor after many weeks implementing feature enhancements. However, his daily updates at the morning sync-ups were somewhat vague (“I’m still working on it.”, “I will be done by Friday as agreed.”, etc.)
After a week, which was the time agreed for the investigation to be completed, he presented his findings to the most senior members of the team, including his manager and the CTO. That is where everything went horribly wrong.
After a quick look through the three libraries he was supposed to look at, Eddy had decided to use a fourth library that he had found himself as he deemed the original three too difficult to integrate with the current codebase. He then spent the majority of the week building a proof-of-concept based on this library. The proof-of-concept was in an advanced state of completion, making its integration in the product quite trivial should the team decide to do so.
What he did not know is that the technical architects already came across that library during their precursory investigation, and they had discarded it due to serious legal concerns.
Eddy failed to reach out to them when changing direction, and his lack of updates meant that the task was carried out until completion without supervision, resulting in a week’s worth of work being wasted.
The breakdown
When confronted about the issue, Eddy became overly emotional and defensive, as he saw it as a personal attack. In his eyes, he was unjustly being victimized: he found a solution which was much better than the three initially proposed and worked very hard to implement a working proof-of-concept. He was refusing the legal argument for the unsuitability of his solution as just an excuse from the architecture team.
The real issue was indeed his relationship with failure.
Since primary school, his parents always pushed him hard to be at the top of his class. They would not accept anything but straight A’s from him. Growing up, he convinced himself that he had to show to the world that he was smart all the time.
To him, failure was an unfortunate circumstance better swept under the carpet and forgotten about. Knowledge was something to be acquired through one’s own hard work, without any help from others.
Breaking through the wall
Eddy was shaken and unhappy about the incident for several weeks. It took him a while to understand that making a mistake did not mean that he was stupid. We had several one-to-one chats about it, and what it meant.
The core of the issue was a fundamental lack of confidence in his abilities, driving a constant need for external validation. This was usually in the form of awards and good grades: artifacts that he could understand objectively to prove his own worth to himself and to others.
This was tiring, and he saw it too. He wanted to change, but he did not know how to.
Turning around
We devised a two-way approach for Eddy: one that would build his confidence while increasing interaction with the team. The first objective was directly related to his recent failure, whereas the latter was born out of his self-perception as an introvert who prefers to work on his own.
Eddy agreed to become a mentor to Alice, one of the interns for the summer. This allowed him to receive external validation in a more positive and fruitful manner than just relying on grades and awards, and to make a positive impact to others in the process. Initially, he was hesitant about this agreement as he saw it as a distraction from his work, but he gradually overcame that and he found interacting with Alice gratifying.
Alice initially would reach out to him with questions that he considered silly. Gradually, he saw that as she became more familiar with the company, the codebase and its guidelines, her enquiries grew more interesting and challenging. From Eddy’s perspective, she appeared to grow smarter every day thanks to their interaction.
Also, he agreed to pick at least five code commits a week that he did not understand well, and to find occasions to discuss them with other engineers. This was hard for him at the beginning, but as time went by he realized that people did not think less of him for asking questions, and he grew more comfortable in doing so.
In turn, the other engineers started reaching out more to him to gather feedback on areas he was particularly good at. This further boosted his self esteem and his integration with the team.
These changes did not happen overnight, but stayed with Eddy for the long run.
Gradually, he stopped working 60-hours weeks. He learned to stop and ask for opinions before going down rabbit holes, and his velocity improved as a consequence.
Unikorn eventually got acquired by a famous tech giant. Eddy still works there, and now leads a team of engineers. There are still times when he doubts his abilities or gets emotional about failures, though much less frequently than when he was a junior engineer.
He still sees himself as an introvert, but he has learned to overcome his introversion when necessary to achieve his goals.
No person is an island. Mutual help goes a long way in achieving results together. Team sports exemplify this very well, for instance in baseball where the pitcher can only defend the score when helped by a good catcher making the right calls, and good fielders catching grounders and fly balls.
Conversely, the game cannot be won if the batters do not score. Good collaboration is about finding balance in different roles and playing the team in the right positions, and communication on the field.
In order to foster good collaboration in the team, we need to balance a few different aspects, see how they interact and adjust our processes and guidelines accordingly:
- People : The behavioral traits of each team member needs to be understood. We need to learn what drives them, where they come from and their aspirations.
- Culture : There are different layers of “culture”, such as company culture, team culture, and individual / local culture. These also need to be understood, and we need to tweak team culture to gel well with company and local culture.
- Trust : The team members will not be really collaborating if they do not trust each other. They need to be comfortable enough to share mistakes candidly, and genuinely suggest improvements to benefit the team.
Team collaboration is a complex and deep topic. There are many issues that we have not even touched on, such as conflict resolution and the difference between homogeneous and heterogeneous teams. I am hoping to examine these aspects in further articles.
For now, I hope you found today’s story an insightful introduction, with some useful pointers for the management of your team. If you had to deal with situations similar to Eddy’s, I would love to hear how you handled them and discuss further approaches.
Meanwhile, keep on making great software and see you in the next article!
