And How To Lead Them As An Engineering Manager
After nearly two decades in my career, at various levels, I have met many technical people – worked with, worked under and led them. Although each person is unique, if I put them in groups, I would divide them into ten clear sets.
As an engineering manager, this knowledge has helped me relate empathetically to them and adapt my leadership style accordingly. The “one-size-fits-all” approach doesn’t work with respect to technical teams. In addition, companies benefit from diversity. Recognizing these different types of developers allows me to translate their individual successes into the overall success of our business.
“what?” you can imagine, “Ten kinds?” In my experience, definitely!
“What else are there?” Definitely! Nevertheless, these are the ones I have chosen for the spotlight in this article! Let’s delve into their features and how you can manage them effectively.
These are unique developers of their kind. They are super-efficient and extra-productive. A part of his abilities can be attributed to natural talent and inclination, but the rest is about his qualities, such as being committed to writing beautiful code, learning continuously, demonstrating a positive attitude and vision, making a high Balanced with enough delicacy. Effective Team – A 10x team.
How to lead them: Give them a problem, make sure they have the space, time, and resources to solve it, and then get out of the way.
Being a cowboy (or cowgirl) is a derogatory term used to refer to developers working with minimal process or discipline, writing spaghetti code and using ‘quick and dirty’ techniques that work wonderfully but Will definitely need attention later. They are either inexperienced or, in most cases, given too much autonomy over the development process because of their quick coding skills. Still, this speed results in cutting corners.
How to lead them: Ask them to build prototypes and develop tools, but never (ever) let them touch production code. Ask the tech lead to advise them until they follow your team’s SDLC.
The cool achievements are close to my heart as I was described as one early in my career. Give them a job, and they’ll do it while others still argue about roles and responsibilities. They are hardworking, rational and respect those who know them. Sadly, they are recognized in the wider organization only when they have good managers who promote them. They usually do all the ‘glue work’ without any fanfare and minimal need for bounty.
How to lead them: Let them know that their achievements are being noticed and that their career development is being taken into account. Try to get them out of their comfort zones by involving them in leadership roles.
Scholars are very academic. They know theory inside out, are experts in algorithms, can calculate the complexity of code (Big O notation), debug assembly code, and read all white papers on any computer science topic. The problem is that when you assign them a simple task, they make it more complicated. Usually, because they get adapted prematurely or get lost in a small detail and overlook the big picture.
How to lead them: Ask them to spend their energy on important details and keep them focused on the task at hand. Don’t ask them to design a system from scratch; Let them research what an optimal solution would look like.
A superhero’s heart is in the right place. They really care about the work and the code they write, and they are motivated and highly engaged. Often perfectionists, they take pride in their output and refuse to say no to new assignments even when overworked. They are in danger of getting burned, but they justify it because they believe they save their projects or organizations. They enjoy attention and visibility, especially when they save everyone’s day, for example, in PROD emergencies.
How to lead them: Emphasize the importance of work-life balance, helping them prioritize their work, and making sure they have the right resources (including people and budget) to accomplish it. Also, protect them from unreasonable deadlines and demands.
These developers are any engineering manager’s dream and, as such, are key participants in all high-profile projects. They are easy to work with, and absorbing criticism is not a problem for them as they have an intrinsic drive to succeed. Although not at the same level as 10x engineers, they require less guidance, and you can count on them to complete projects on time.
How to lead them: Assign tasks to them, but make sure other programmers are involved as well. Otherwise, they will be indispensable and will be the only people able to deal with the problems.
Regardless of major project milestones, PROD problems, or any other deadlines or emergencies, this developer will end assignments mid-day, leaving their team hanging on exactly when the clock is 5:00 PM!
Their workday is not determined by their workload but by their contracted hours. They never go above and beyond, as they lack initiative, enthusiasm and ownership. In other words, it is pure mediocrity at its peak! Quitting has become a popular term recently, but in this case, it is not a reactive behavior but a specific attitude towards work.
How to lead them: Motivating the developer who consistently does minimal work, even if possible, isn’t easy, so the best approach here is to recognize and reward employees who work hard to reinforce a positive culture within the organization. make extra effort.
These individuals are probably the smartest people on your team. They are fast, very rational, great problem solvers, and are satisfied only when they code. “Good enough” is not for them. They are talented but can be eccentric and often poor communicators or prone to interpersonal conflicts. They prefer to work alone and avoid interactions with others. Nevertheless, they are essential to innovation and technology delivery and, as such, are valuable members of any engineering team.
How to lead them: Irrational decisions, inconsistent policies, and meticulous management will expose the geeks’ worst behavior. A managerial path is probably not suitable for them, but they may progress down the path of an individual contributor (equivalent to a typical engineer/fellow).
The hyper-focused developer knows exactly the limits of their work, and they won’t want to do any other work. If you ask them to debug a poorly performing SQL query, they will refer you to the DBA. If they need to work on the Continuous Delivery Pipeline, they’ll say that’s the job of DevOps, etc. They don’t feel confident being out of their comfort zone—possibly because they’ve never been empowered to change their tunnel-vision tendencies, or it may be because the day-to-day grind of their work keeps their minds busy. be busy.
How to lead them: Present the big picture to them and train them to have a more circular view of the project, their role, and their impact on the wider organization.
I left till the end which I feel should have no place in team setting as they hurt everyone’s morale. Generally well-liked and emotionally intelligent, critics appear professional from the outside but are completely unfit to work in a team. Despite their shiny façade, they always find ways to subtly undermine other members (developers or managers alike). Whether through backhanded compliments, passive aggression, narcissistic comments (“Nobody can do what I do”), or blaming the code design or performance of others, they thrive on negative attention, and their toxic intentions can be contagious.
How to lead them: Give direct feedback and explain the results, but realize right away that some people never change. So, manage them – in an exemplary way!