#GeniusDeveloper #HandlingGenius #TechIndustry #ProductManagement #TeamManagement
🌟 Genius Developer – How to Handle Him? 🌟
As a Senior PM in the MarkTech industry, I understand the challenges of managing a team of diverse talents. One of the most common dilemmas I’ve encountered is how to effectively handle a developer who is exceptionally skilled and productive. In this article, we’ll explore the best approach to managing and maximizing the potential of a “genius” developer in your team.
Understanding the “Genius”
Before diving into strategies for managing a genius developer, it’s crucial to understand their unique characteristics and contributions. A genius developer, as the name suggests, possesses exceptional skills and knowledge in various areas of computer science. They are often sought after for their insights, problem-solving abilities, and the speed at which they produce high-quality work.
Challenges of Managing a Genius Developer
While having a genius developer on your team can be a valuable asset, it also presents specific challenges that need to be addressed:
Impact on Team Dynamics: The exceptional performance of a genius developer can sometimes overshadow the contributions of other team members, leading to a sense of demotivation and reliance on the genius for all tasks.
Risk of Dependence: Overreliance on a genius developer can create a dependency that poses a significant risk to the team’s performance if the developer were to leave the company.
Strategies for Handling a Genius Developer
Now that we’ve identified the challenges, let’s explore some effective strategies for managing a genius developer within your team:
1. Encourage Collaboration and Mentorship
– Pair the genius developer with other team members to share knowledge and skills.
– Encourage them to mentor junior developers, fostering a culture of knowledge sharing and teamwork.
2. Challenge and Engagement
– Provide the genius developer with challenging projects that push the boundaries of their skills.
– Create opportunities for them to lead initiatives that require strategic thinking and long-term planning.
3. Balancing Workload
– Distribute work evenly across the team to prevent over-reliance on the genius developer.
– Utilize their expertise for critical projects while empowering other team members to take ownership of their tasks.
4. Professional Development
– Support the genius developer in pursuing additional training or certifications to further enhance their skills.
– Provide opportunities for them to attend conferences, workshops, or technical events to stay updated with industry trends.
5. Succession Planning
– Develop a succession plan that identifies potential successors for the genius developer’s role.
– Encourage knowledge sharing and documentation of critical processes to minimize the impact of their potential departure.
In conclusion, managing a genius developer requires a delicate balance of leveraging their skills while ensuring equitable opportunities for the entire team. By fostering collaboration, challenging the genius developer, and implementing succession planning, you can create a harmonious and productive team dynamic.
I hope these strategies provide valuable insights for managing a genius developer within your team. Feel free to share your experiences or additional tips for handling exceptional talent in the tech industry. Together, we can create an environment that nurtures the growth and development of all team members.
#TeamManagement #TechGenius #ProductCentric #TechIndustry #DeveloperManagement
The first question that comes to mind is why aren’t the tickets managed? At the start of the sprint define the tickets that everyone does based on their objectives and knowledge level, then define a few backlog items that anyone can pick up. If he starts encroaching other people’s work, have a talk with him and perhaps work out a side-project with him instead of letting him take over the team.
If you don’t get him promoted, he will leave.
Sounds like a great aspect of engineering for your man to grow in is transferring knowledge. I like to work in teams where individuals are responsible for, and expected to be proactive in, minimizing the impact of them ‘being hit by a bus’ (disappearing for whatever reason). Documentation doesn’t happen nearly enough because engineers typically dislike it, and managers see it as something that doesn’t add value (right now, so not at all). As an aside, in the same forgotten aisle you’ll also find maintenance.
He enjoys the attention for now, but eventually he’ll get bored and leave for new opportunities. Better prepare for that and start milking him to document everything and get other people to internalize his projects. As he is now, he is basically high risk asset since you never want knowledge to personify to any single individual.
Also it’s funny that some people claim the 10x engineer is a myth but it’s really not. Some people live for this stuff and it shows.
Dunno if you have the authority to place him on some high-risk, high-reward skunk works project you can both use as your lottery ticket up and out if it succeeds but won’t hurt either of your careers if it fails?
Just wait a year and when he doesn’t get a raise the problem will self correct itself. Your company will never pay this kid what he’s worth and once he figures that out he’ll be like the rest of us that are great but put in minimal effort because it doesn’t pay off.
Encourage him towards tasks that enable other engineers. Scoping projects, reviewing designs, doing designs, creating epics of work for others to do, and then still doing some individual contributions to the most important projects. Look into traditional staff engineer roles which sounds like he is in spirit at your company.
Formalizing this in his expectations is the way to do it as well. Don’t make him a shadow consultant for everyone. Work with management to get that a part of his reviews formally.
This increases his scope and impact from being the genius who can push great code to the engineer leader that levels up the work of everyone around them and still pushed great code on the most important stuff but not overshadowing everyone as an IC.
As for him leaving. The problem with smart highly motivated people is you have to keep them interested and paid. So do what you can to fulfill those requirements.
If he has no interest in increased scope and collaboration (does not seem to be the case). Then I would have a different answer.
If your team doesn’t have challenging projects that really need his intelligence, he is going to leave your team soon. If he stays with your team for a longer time, especially with him not getting paid what he’s worth, it’s not good for his career and growth.
Make him teach.
If he’s so good that he’s 60% of the team’s productivity, and the rest of the team has grown complacent then there are two ways I’d use him. Firstly, he’s going to be our trailblazer, the guy who solves problems the team has never seen before. Secondly, he is then responsible for showing everyone how to walk the trail he’s blazed, and why he’s taken the approaches he has. He still gets to be your star performer and you still gst high quality, fast work, and the rest of the team has an easy and built in path for upskilling.
Overtime the ceiling and floor for developer quality on your team will both increase, and the product will benefit as a result. The only people likely to have a problem with this are those who don’t want to learn new things, but that’s a different problem you’ll need to help them confront anyway.
As someone who used to be in his position this is the approach that was used with me and it resulted in A LOT of people getting promoted as a result
You need to have a different type of conversation with him about how office politics works, but in a non discouraging way .
Tell him how talented he is and how great of an asset he is, but be transparent about how you feel like you are being to us.
This guy has a good head of his shoulders, don’t tell him he’s doing anything wrong, tell him he’s talented and you want his help helping everyone rise. Ask him directly how you can challenge him more. Tell him how he makes the others feel in a non combative way. Suggest to him to pick up an extra certificate instead of taking on another ticket next time.
You said he’s fresh out of college? I’m guessing he has no idea how his work is impacting the vibe of the office. I bet he thinks he is just suppose to work, work, work.
>if he leaves the company, we will lose a critical ‘piece’ that knows ins-and-outs and we will be screwed.
if the kid is as talented as you claim, he will be poached to Big Tech in less than a year
it’s not a matter of *if* he leaves the company, it’s *when*
Is anyone in the leadership chain able to keep up?
– Find a mentor above him that knows as much as he does (maybe an architect).
– Balance his IC time programming vs design (don’t let him complete 60% of the tickets, let him do 50% and spend 10% helping design new features instead)
– As he gets better at the non-coding parts, let him teach/mentor (force multiplier). This isn’t a day-1 thing. Most new grads cant actually do it and it frustrates them (it takes time to learn how to teach and read people, it’s a soft skill that he may not have today)
IMO you really should try to encourage him to balance his work/life more. I’m sure it’s tempting to keep giving him more and more to try to keep him from “getting bored” but as many others have pointed out that’s not really sustainable. If he continues to prioritize work he WILL get bored and leave eventually, likely leaving with a large chunk of your knowledge. Things are new enough now to keep him engaged, but even if you give him various side projects eventually he’ll have “seen it all” and there won’t be a new thing to conquer… except at a new job.
I’d recommend having a one on one meeting to talk about his future goals, his hobbies, encourage him to utilize his PTO, etc. Treat him like a human being, not an asset.
If he continues this current track he’s either going to burn out and leave or more likely get bored and leave.
Ok, several things come to mind based on what you wrote.
1. I know he lives to work. Been there, done that, bought the burned out T-shirt. You seriously need to talk to him about taking vacations. Or his manager does. Living to work is not sustainable.
2. KT sessions with the rest of the team. I do it with mine and vice versa. You cannot have one person be that important.
3. Find out what their passion is. What does he really want to work on? Once that knowledge is known, make it happen.
4. Money. Enough said.
5. When you get him taking vacations, doing other work, the rest of the engineers will pick back up.
So you’re saying he’s intelligent, and he wants to help.
So it sounds like he wants “the best outcome” to be the thing that happens.
Which means that if you can convince him that “the team having opportunities to learn the layout of the code, and to stretch their skills, etc” is what the best outcome is, you’ll have him on your side and willing to *not* work (or maybe be a point of consultation for anyone struggling, etc) in order to improve the skills and outcomes of the team around him.
You already know he can do the job, but he’s accidentally standing in the way of others improving as well. If he can see/understand that, you can probably get him to work towards the same goals you have.
I think there’s a lot of good ideas here. I just want to say that when this guy leaves (we all leave our jobs one way or another), you shouldn’t look at it all as your fault. There’s a lot of theories out there on why good engineers leave (and the more positive why they stay), that I’m sure you as a PM already know. My anecdotal experience is that people really just stay due to a mix of their direct manager providing consistent support for them, and the team their on meeting their work needs. I’ve seen one “rockstar” dev leave due to engineering politics getting out of control, and another because our manager and him never saw eye-to-eye. The other obvious factor here is money, but a lot of people will gladly turn some amount of salary (it varies by person) to have a good manager and a good team.
Praise him to the skies, let him see you do that, and bubble him up through the firm ASAP.
He won’t forget your support when he is very senior, so he could well ensure you have some protection against layoffs etc in later years.
Does he connect well with the other team members? Aside from just collaboration, I mean.
Asking because I have had a few quite intelligent coworkers, and I’ve noticed that one of the big issues—on top of the eternal getting-bored-with-too-easy-work problem—seems to be a loneliness-inducing communication gap between them and other people. Difference, good or bad, often goes along with some side effects, you know?
I’m stereotyping, but this is some of what I’ve noticed: the quantity of info that they consumed was staggering, which is nice and all, but they wanted to be able to *talk* about some of what they learned with others, and they couldn’t really because the breadth just wasn’t there for the proper background context and further inferences. And learning was often their favorite thing to do, but others talked about learning as if it were a tiring thing, so that narrowed how they could even approach new topics with others. And they sometimes would get excited about a topic, forget themselves, and talk too quickly for people to follow, or in a way that took for granted some thinking styles that they should not have taken for granted. And often the level of detail was something that no one else cared about.
Basically, unless they watched themselves, a lot of people couldn’t follow what they were talking about, why they were talking about it, and how they talked about it—and then they’d get implicitly or explicitly told stuff like “you need to slow down because you are exhausting.” Which sucks for everyone involved.
Were I you, I’d try to hire another person or two who communicates/thinks in a similar way. People leave when they’re bored AND lonely.
And pay this dude well.
Y’all really gotta stop posting about me
I don’t have a good full answer on what to do with this person, just things to make sure don’t happen. Don’t let them steamroll everyone, don’t let them take work from others because they think they’ll do it better, don’t let them become the hero programmer that solves everything. All of those are bad for their future and your teams future.
As others have said, figure out where they can fit in to be a multiplier for others and make sure they’re helping, no doing. It’d be easy for someone like this to start to look down on and disrespect the rest of their team and you do not want that.
He’ll leave the moment someone offers him a higher pay – that could be tomorrow. Make sure your team is fully aware of “bus factor” concept and your team won’t get screwed when the guy leaves. Why is the guy contributing 60-80% to the project? Is he doing other people’s work? There is a process and tickets with names assigned to them – if other devs are slacking because this rockstar does most of the work – you need to whip your team in shape. Give the guy workload equal to the team members, if he completes earlier, then let him fuck around and do whatever he wants, but don’t give him more work. You have 4 other guys – make sure they do equal work. I know it sounds counterproductive, but when the kid leaves you don’t want your team to be dumbfounded and “well John did it, so we don’t know how to”
Kids like that need to be challenged, but they also need to be taught to communicate their feelings well. They tend to work themselves until they burn out and don’t even realize they’re burning themselves out until it’s too late.
In regard to your team. I would allow your other developers to create the unit tests for the stuff that he’s developing and help document his work, occasionally give other developers projects that he’s not a part of, and ensure people are communicating their feelings well. Resentment can be squashed if people are able to communicate in a healthy manner their feelings and thoughts.
I’m currently working with an older developer who is a unicorn amongst unicorns, and learning how to communicate well has saved us a lot of headaches. He butts heads with all of the new developers, but after helping mediate a bit. All parties walk away feeling positive about continuing to work together.
I am a junior on a team with someone exactly like this. Thank you for thinking of how it impacts the other developers on the team. Often times, the challenging tasks get taken by this individual which limits the rest of our growth. We aren’t able to get stuck or learn through problem because this coworker instantly solves them or just takes the tasks
Have you actually talked to the guy to see what he is interested in and the direction he wants to take with his career? Also, if he is as good as you say he is and he builds you a bunch of good products/tools/whatever then leaves, you’re not screwed. Part of being a great engineer is building things that other engineers can understand and maintain.
Keep him interested, well paid, and feed him all he can eat of what he likes. You might need to rearrange the teams and get him with some similarly skilled people if you have any, with some people that complement his skills and like/are good at the things he doesn’t like doing, and/or with people who won’t get discouraged or slack just because they can’t keep up with his output.
You should always be preparing for the day that they leaves your team or the company. I’ve been “that guy” at a couple places, and I’ve also worked at companies where “that guy” left. And there’s definitely a catch up period.
Just let him know that you are concerned with burn out as you noticed him working after hours.
Otherwise let him continue to contribute at his level. It’s his responsibility to manage his health and downtime. Continue to gas up your other team members about their contributions, and enjoy having a high potential on your team
This is a good problem to have. Think bigger, if you had unlimited dev capacity what would you have your team do? Are there alternate designs for your product? Have him be the sole dev on one track while your team builds another then A B test… have him prototype the project w the latest tech, etc use your imagination
This where matrix orgs fail. PMs start calling it MY TEAM and do dumb things like pulling back on a high performer. Your problem isn’t the high performer — it is the teammates that are saying “why should we bother”.
Just talk to him (and the rest of the team) about how you can work together to increase overall velocity.
There is something to say about the risk of one employee “getting hit by a bus” impacting biz continuity. Talk to his engineering manager about it vs trying to solve that yourself. The two problems aren’t the same and don’t necessarily have the same solution.
He is an excellent builder. How about you do your job: make excellent features for him to build. Be an excellent product. Maybe this is where an excellent relationship begins…
Ask him what are his expectations, what he would like to do. Same as you would with most people. Then you can figure out how to make best use of his skills for the company while still letting him fulfill his aspirations.
The best approach is to let him run. Have him work on something where he doesn’t need to wait for other engineers. Just make sure he keeps doing PR reviews and follows the normal coding processes. He’s clearly at a point where he wants to code a lot. Do what you can to give him what he wants.
Everyone ALWAYS thinks “if person x leaves we will be screwed”. Its simply not true. I’ve been in this situation where I thought that because I couldn’t save someone from leaving that it would be horrible. What ends up happening is others step up to fill the void. You cannot treat him differently than others. Encourage him to take time off, it is a benefit and if he doesn’t use it he will burn out.
At the end of the day if they want to leave they will leave and there is nothing you can do to prevent it. If the rest of the team is leaning too hard on him then that is a major TEAM problem, not his problem. Reinforce to the team that they need to pick up their share of the work.
It really sounds like an immature developer who knows a lot and can contribute a lot but doesn’t know how to cope with the other aspects of the job.
Pay him more – and give him the senior title he obviously is qualified for.
Ask him what he wants. Offer ideas if he is not forth coming, like 4 day work week, higher salary, flexible hours, more holidays, remote etc. What ever you think your company would allow.
Give him space to stretch and take himself seriously. Restrict his work time on your projects to 60%, with the remainder of the time spent looking for what he thinks would be most worthwhile. Could be personal projects not related to work (there will be carry-over eventually), partnering with other areas of interest to him (tactfully clue in relevant parties), or finding/making his own opportunities for individual contribution at work.
Good on you for recognizing his skill, not taking it personally, and looking for ways to help him. Chances are there are very few, if any, places that will meet his needs. Giving him the freedom to figure out how to do so on his own is probably the best thing you can do for him, and your company will benefit.
For better answers, ask on quora.
This reads like it was written about me. There are some key differences though, so unless you deliberately changed some facts to obscure it, I don’t think this is actually about me. Anyway, I can probably provide you perspective from the engineer’s point of view. First of all, your engineer will almost certainly feel undervalued because he will be. Companies aren’t setup to promote fast enough and adequately reward the best engineers. The engineer’s only way to get some reasonable portion of what he deserves is to job hop, spending maybe a year at each company. Expect to lose him. Even if you only have him for a year, that’s a year where you got essentially a full development team worth of production from one person. You won’t be screwed when he leaves. If you are, your company was going to fail anyway. People leave, sometimes several at once, and you need to be able to handle that. Try to treat the engineer as well as you can. Do everything in your power to get him promoted, recognized, etc. Take advantage of his big production, but never rely on it. There may be sprints where he wants to contribute at a standard level. That should always be okay.
When we had one of the kid geniuses as an intern, while he was still in college, I handled it by giving him my business card and asking him to keep in touch once he inevitably started his own multi-billion dollar corporation.
Is he single
You need to do everything you can to get bullshit out of his way. No corporate delays, no meetings with overpaid idiots who don’t know what they’re talking about. No interactions with anyone who wants to talk about strategies and future visions.
Give him interesting challenges and he will excel.
Make sure his work is recognised. Make sure his pay aligns with his ability. You have a responsibility not to break this persons spirit.
I think there are multiple dimensions:
1. How to promote him at the right pace and give him enough tasks to motivate him so that he stays. This includes being careful not to promote him to a position he won’t be happy / successful in.
2. How to keep the rest of the group motivated. There I see a problem with the other people. They should be striving to be as good as that guy, instead of giving up and becoming lazy. Either the way the company motivates people (e.g. through compensation or promotions) is broken, or these other devs need a firm talking to.
3. How to not lose critical knowledge and ability to operate if / when he leaves. That’s probably through code reviews and great processes.
4. It’s great that you worry about this, kudos to you. But why isn’t his direct manager handling this? Is he or she up to par?
I’m one of these guys. When you said “freshly after college, with 10+ years of experience,” I felt that. It kind of sucks because when I apply, they always tell me I don’t have enough years of experience, even though I’ve been coding my entire life, and I can’t even get past the initial screen because of my “lack of experience” and the fact that I’m still in school. So I don’t even get the chance to demonstrate my skills during an interview.
The first task my lead gave me for my first job, they planned out one month for me to finish, but I took about 2 days. For the majority of my first year working, my lead kept running out of things for me to do. Rarely, I would ask for him extra work and he would just tell me to study. Eventually, my lead stopped managing my work and switched to focusing on helping the backend (I’m on frontend) because backend would always be lagging behind. So what do I do? I would finish all the work assigned to me for the sprint in the first one or two days, and then I would just do random stuff. During standups, I will tell them I did X and Y today, when actually I did X and Y a week ago. Occasionally, our CTO (it’s a small team) will reach out to me and have me build an MVP, or I might help out another team, but most of the time, I’m studying or walking around or whatever. No one cares because they know I’m probably already done with everything.
Even though I work fast as an individual contributor, by no means do I feel I provide the most value for the team. My goal is to be good at one thing: frontend development. I have no interest in dealing with backend or DevOps or management or design or marketing (at least not in my day job). So that means that other members of my team don’t need to worry about me overshadowing them. My goal is to basically be a critical “piece”, but not the whole. I’ll handle my part, and I’ll handle it well, but I’m not handling anything else. I actively try to avoid scope creep. Why is that? I don’t want to become difficult to manage. I’ve been assigned a role, and if I try to do too much, it can backfire. I’ve made the mistake too many times already.
So what can a manager do? You don’t need to do anything. Just don’t scope creep me and punish me for working fast. Try to improve my experience just like you would any other developer. Make sure I’m not blocked, help with communication, etc. I find my own ways of challenging myself. I’ve been building projects since I was a kid and I’m not stopping now. I’m still in school and I don’t need to be given extra work to be satisfied.