All Developers are not the Same

There are super stars in every field. After all, you have world class lawyers, doctors, architects, engineers, etc... The same goes for developers. Everyone should be given an equal opportunity to succeed,  but not everyone is equally talented or productive. For this reason managers need to treat their team members differently and even unequally in certain cases. I realize saying this may be controversial, especially to an HR person, so I will clarify.  

Early in my career I had a manager who considered himself very fair and he treated everyone the same.  He was a stickler for details regarding punctuality, appearance and rules and regulations and gave anyone (whether junior or senior) a hard time if these rules were not followed to a tee. Eventually this manager lost all his experienced senior developers. Why? Its because they expected better treatment and perks given their superior work quality and productivity. The lesson here is that you give your best people some breaks every once in a while. They have earned it. Its a reward for good work. This policy is at odds with what an HR Dept typically preaches, that everyone should be treated exactly the same. But  every developer is different, so you don't want to treat them all the same. As a manager, you have to customize your treatment and rewarding mechanism to the strengths and talents of each developer.

In the last 20 years of my career as an IT manager, I hired good developers and ended up with a crack team.  I led this team in writing large custom Windows and Web applications from scratch.  This was quite a privilege because not every developer gets to write software from scratch. Often developers end up installing purchased software packages and doing other mundane work. My team had the privilege of writing custom software for our company when there was no off the shelf software available. 

The key to the success of any IT project is ensuring quality in the IT disciplines of project planning, requirements, UI, architecture/design, code, testing and deployment. Each discipline is a link in a chain representing the project and if one link fails, the project will fail.  Some IT managers believe that developers should excel in all these disciplines and expect them to wear all these hats as they work a particular app use case. I saw that different developers are better at some disciplines than others. Even the ones that are good at everything have one discipline they enjoy the most and do best. I allowed my team members to specialize in the discipline they were the best at. As a result I had a well oiled machine that could crank out complex applications. We cranked out many client and web applications using complex workflow, imaging, relational back ends and content management.

Before I describe how my team members specialized, let me tell you what they all had in common. They were all accomplished technical people with advanced degrees in computer science. In my opinion, a programming background is a requirement for all the IT disciplines to be understood and that even includes requirements gathering. When you gather requirements you have to know what is possible and what isn't, and you use that knowledge to guide the end user towards something that will satisfy them that is feasible. But I digress, back to my team members.

I had one person who was world class in requirements. She could read minds. Requirements are easy when the end user knows what they want. But oftentimes they 'think' they know what they want but they are wrong. She would always hear out the end user and then guide them towards a solution that met their needs that often was totally different from what they requested. She would learn the business, identify the end user's pain, and create a use case document that would solve their problems. People with her talent are hard to find. Many projects fail in the requirements phase, but we never had that problem.

I had a UI designer who was the Van Gogh of the user interface. From the use case document and talking to the end user, he would add that magic touch to the user interface that gave it the WOW factor. Jaws would drop the first time the end user saw their app. The problem with this guy is that creative artistic people sometimes have strange working hours. He was most productive from 1pm to 8pm or even sometimes in the middle of the night. Whenever the muse hit. He could not get up in the morning. I had to look the other way many times when he would come in a 11am to work. It was quite a problem but the thing is that he got his work done and he was the best UI person in the entire company and I would say all of Florida.  Thankfully the solution was to let him work from home.

I had a guy who was working on his Phd in AI who was hands down a world class  architecture/framework design guy. Every app has to have a solid foundation and architecture. This guy would crank out reusable components for us. We had our own custom components for ORM, web UI dependency, validation, business rules and workflow thanks to him. These frameworks eliminated a lot of redundant code and speed up development by orders of magnitude. This guy was a little bit hard to manage at first because geniuses justifiably can have an ego. But I knew that he was too valuable an asset to let that get in the way and after a few years he became quite a team player and a respected leader among the developer community.

I had a relational guy who was the best relational database guy around. A database is the heart of an application and it must be designed properly using normalization. This guy had some minor personality quirks that sometimes led to conflict, but again, I had to let that go because he had too much talent. And in a couple of years we resolved those issues. I had my team for 20 years, so a couple of years storming is worth it to get 18 years of norming/performing!

Last but not least, I had the fasted coder on the planet. This guy's coding productivity was without exaggeration (I know you will think I am exaggerating) 10 time the productivity of a quality normal developer. And he wrote solid code following all our standards.  Having him on the team was like having 10 good developers that work at top efficiency at your disposal for those really tough technical use cases. He was the nuclear option. The thing with him is that he would go into what we called 'code frenzies'. When he went into a code frenzy he would disappear for a few days, not eat or sleep and just sling code. I would give him the toughest use cases and after a matter of days we would demo the use case to an incredulous end user. He ended up working from home too :-) 

My advice to managers is to recognize talent, retain talent and try to deal with any quirks or issues and come up with out of the box solutions. There is no substitute for talent, and oftentimes, talented people are different and have quirks. They need to be treated differently. History has shown that the greatest minds of all time were possessed by people who were far from 'normal.' Its a competitive world in IT land. You need top talent on your team to win on all your projects.