Our small-but-cozy software boutique was contracted by a major international client to carry out a huge project. We were given eight months, but that was too short of a timeframe, so we had to scale up our team.
We hired an additional engineer. In the beginning, he was given small tasks like documentation updates, some bug fixing, and regression testing. He delivered on everything in record-breaking time. I was really pleased with his work, so I started sending him tickets from our client project.
I knew that he was a fantastic engineer with a really bright future ahead of him. During recruitment, he nailed all of our tests and got in really well with the other engineers. Soon after I started noticing some other traits that I did not expect to see like impatience, aversion to being told that he was wrong, and his constant desire to prove himself.
We always say that our software studio has a flat hierarchy and that everyone can contribute to improving our systems and workflows. But we didnât expect him to take his contributions to such a dangerous level.
He wanted to introduce a JavaScript framework that he had developed on his own to our current project. I didnât think he was serious because he said it in passing, next to the water cooler. I told him our frameworks were sorted and that making a change now would slow down production if not halt it altogether. He shrugged his shoulders and simply said, âSure, no worries. I understand.â
A few days later, during a standup, he started to voice his opinions, this time more forcefully, which came across as arrogant. I told him, again, also a bit more forcefully, that we couldn't make the changes. So what did he do?
He went rogue and started systematizing a different code set on his own. Where were my code reviewers? Were my code reviewers fed up and just letting things pass through just to ship out faster? This was another problem I had to deal with. I guess this is the life of an engineering manager.
Later on, when we started on the third module, he said in a standup to write code differently because all the work he did, much of it behind our backs, would create blockers and huge slumps in production.
Thatâs when I lost my s*it. But before I took action, I had to do my due diligence. I needed to enter the mind of an overachieving software developer.
Understand the Mind of an Overachieving Software Developer
To effectively manage disruptive, ego-driven, overachieving software developers, you really have to know how their minds work. Only when you understand this personality type and the motivations behind their behavior will you be able to manage them in a way that doesnât cost the company money.
Here are a few insights Iâve learned about overachieving software developers:
1 - They get a high from completing tasks above and beyond expectations. However, the bigger the challenges they seek, the harder it is for them to get that rush of dopamine.
2 - They get bored easily, and when that happens, they tend to leave the company.
3 - They focus on one task at a time and often miss important details or other opportunities to keep feeding their egos.
4 - They may look unfocused, but trust me - theyâre in the zone, too much in the zone!
5 - They are sensitive. They donât take criticism well.
6 - Theyâre too forward-focused and want to get to where they want to be in their careers.
7 - Money doesnât motivate them - projects and experiments do.
8 - Have you ever told an overachieving developer that they were wrong? Exactly.
9 - Have you ever micromanaged an overachieving developer? Exactly.
10 - They think they donât need help or mentoring - they think they can mentor the mentor.
How To Handle an Overachieving Software Developer?
Set clear boundaries
If you have a disruptive, ego-driven, overachieving software developer, you need to have a one-on-one meeting right away to nip the problem behavior in the bud.
In general, you should confront each issue as it happens. If you neglect it, no matter how small the problem is, you let things build up; and when you finally address the problem at its breaking point, youâre liable to cause an emotional tsunami. Remember, overachievers donât take criticism well.
In my case, I explained to my overachieving developer his role and expectations. I said that I was responsible for the business side of software development as much as the people side. It seemed to me that he needed to understand the team aspect of building software, that software is built by people for people.
Also, I made it clear that he canât unilaterally go off and do what he thinks he needs to do. Such actions require my approval as well as the teamâs buy-in. At our agency, we have a team-first approach, not a tech- or developer-first approach to solving problems. If he wanted to grow at our company, he had to understand that.
Honestly, I needed to stand my ground. Had I allowed him to experiment freely with our client's money and it failed in epic fashion, then I wouldâve looked bad. Next thing you know morale drops as well as productivity. My direct reports wouldâve lost trust in me and the C-suite wouldâve started calling me up to explain myself.
Focus on the process, not on the outcome
After addressing the problem, I started finding ways to align his personality with our objectives. Overachievers are driven to perform at peak capacity, but they often tend to fixate too much on the end goal. And sometimes, the outcome of the end goal canât be controlled. So, the idea here is to help them focus on the process - the variable they can manage and control.
Get your overachieving developer to prepare an actionable plan where its steps are outlined and can be marked off as done. This plan will help them stay focused on what is important right now to reach the goal, rather than fixate on the goal far ahead into the future. By reaching each milestone, they will get that rush of dopamine, which overachievers crave.
Help them find balance, or they burn out
Iâve had some experience with a variety of overachieving types. On one project, when I was leaving the office, they were still crunching code at their desks; and when I came back to the office the next morning, they were still crunching code at their desks.
Overachievers understand the importance of health and wellbeing, but they keep their blinkers on and keep going no matter what. They push themselves to the limit, working long hours, skipping meals, and depriving themselves of sleep. When they're sick, they keep going, and that puts them at risk of experiencing depression and burnout.
So, as an engineering manager, you have to be strict and enforce breaks and vacations. But donât just say that your overachieving developer needs a break - make this a policy for all your developers, and whoever doesnât follow it then address it in a 1:1 meeting with a boss ceremony.
Hereâs what could also help: because overachievers are big on goals, make âfinding a balanceâ a part of their goal and make sure it can be tracked and measured. For example, you could make it a part of their KPIs to take a mindfulness course, see a therapist, take a day off, or take some investment time to just chill and learn something.
Treat them the same, but different
As I said, we have a flat hierarchy in place and we ensure equal opportunities for everyone. However, there are certain individuals like overachievers who need to get a different kind of attention. Iâm not talking about rock star treatment here đž
Because they work fast, you need to provide them with the tools to fast-track. Arrange 1-on-1 mentorships and help them develop their career plans. Other things that help include providing training and educational opportunities. Probably the most important thing is to give them the flexibility and freedom to be challenged. Remember, this is a unique group of individuals who will always work hard and give 110%.
By allowing for flexible work hours, WFH, or other perks, the organization will only increase the overachieving developerâs loyalty and job satisfaction. At the end of the day, you don't want to hold your developers back just because âthat's how we do things around here.â
Your job as an engineering manager is not only to deliver a product on time and within budget but to be a great leader, foster a healthy company culture, and help your developers be better coders (and people) every day.
Wouldnât you prefer to lose your developers because you mentored them and helped them achieve the next level of their careers? I like the expression: developers donât leave companies, they leave their managers. Donât be that manager!
Encourage teamwork through pair programming
The reason why high-performing dev teams are very successful in building software is because they know how to collaborate well together. Itâs important for your overachieving developers to understand that. The best way to drill this into their heads is to get them to work in pairs.
Pair programming is a software development practice where two programmers work together on the same computer, collaborating on a single task or problem. In this approach, one person takes on the role of the "driver," actively writing the code, while the other person acts as the "navigator," reviewing the code, providing feedback, and thinking strategically about the direction of the work.
The pair continuously switch roles throughout the programming session, with the driver and navigator roles swapping frequently.
This approach allows for real-time collaboration, knowledge sharing, and immediate feedback. It can enhance code quality, promote creativity, and improve problem-solving. Your overachieving developer will also learn that others have great ideas (and sometimes even better ones!).
If you can get them to redirect some of that extra energy into being a good teammate, it could put them in their place and slow down the mayhem. They can earn their stripes before getting put back in the âplays well with othersâ column.
Investment Time is a time to experiment
Most big corporations have a robust system in place that has a lot of complex moving parts. So, itâs nearly impossible to shake things up. Moreover, big corporations have strong technical and process guardrails that preserve their precious and costly infrastructure.
When overachieving developers work in such an environment, when they put forth ideas and canât seem to break the mold, they lose motivation and quit.
As an engineering manager, you really need to take this into consideration. If you want developers on your team to just follow the lead and do what theyâre told, then hire a cog to churn out the work for you. Otherwise, you should let your overachieving developers go.
But if youâre willing to understand that your developers have a lot to offer, and if they have a proof of concept, you should give them the freedom to explore ways of turning their nuanced ideas into a reality - but not on your clientâs time nor with their money, right?
If your overachievers fail on your watch and on your clientâs dime, sure theyâll get punished, but theyâll probably get angry and leave the company, and youâll be left with cleaning up the mess.
What we did:
Because changing frameworks was out of the question, we allowed him to create a new branch, a sandbox, where he can show everybody if his other ideas worked or not, if they were better or not.
The result? It passed some code reviews and tests and performed only a bit better, so we didnât incorporate the changes into the next release. We then did a post-mortem without any finger-pointing to give him feedback, so that he could learn something.
Mentoring
An overachieving software developer is a multiplier and can be a huge asset to the team. Because they love challenges and constantly want to learn more, I helped him build on that by pairing him up with a mentor.
The mentor, a brilliant principal engineer, gathered information from 360 feedback and a competency matrix. Got to know him a bit better too on a personal level.
Our mentor showed him all the resources he could think of, recommended good books to read, and encouraged him to blog about his ideas and share them with dev communities. The overachieving developer started threads about his architecture ideas, and asked community members if it would handle certain features and if it would be scalable. The answers he got didnât always validate his idea to the others. His ego deflated a bit.
Overall, mentoring helped him:
- Experiment in a way that didnât affect team morale or the code base.
- Understand how difficult it is to build consensus on a team and deliver a solution.
- Understand that you're there to support him and improve his skills.
On a final note, Iâd also say this:
Change your mindset to understand your overachieverâs mindset.
As an engineering manager, you have to start seeing the overachieving developer as a different breed of developer. At the end of the day, wanting to do something different isnât exactly a bad thing. You just need to have a certain kind of situational awareness and understand your business environment and who your stakeholders are.
After all, wouldnât you prefer a junior on your team whoâs pushing the limits to become a 10X engineer? Or someone whoâs delivering mediocrity and taking forever to carry out half-day tickets? â
