Too many times in our lives as developers, we feel that in spite of our talent, skills and knowledge we just can’t seem to bootstrap ourselves from the mess we’re in. It reminds me many movies (and the great Prison Break television series) where you see a nice, innocent guy put into jail with a bunch of murderers and rapists. After stabbing a guy in order to prevent from being stabbed, our hero gets into more trouble than he started with. This vicious circle goes on and on so by the end of the movie, you are not sure what he could have done different. His skills, talents and knowledge were thrown away, replaced by the need to survive. In many scenarios in life, I feel like that guy.

Avoiding the (really)poor analogy of un-unit-tested\unmanageable\coupled\you-name-it software to jail, I decided to stand up to the challenge(talk about “What not to do”) raised by my friend, Uri Kalish, and share with you my vision regarding top mistakes I have experienced in the last few years. If it will able 1-N (see, I just had to be all geeky about it, even after talking for a full paragraph on jail and murderers) of you guys & gals to change 1-Z things in your world, this post will worth any future creepy comments I’ll get from real ex-prisoners (what?! there must be some ex-prisoners .Net, Java frustrated coders out there, right?).

• “Promoting” best coders into solely management positions
  It is the fear of losing someone and the way our community treat one’s status causing this behavior. To make things worse, in most of these scenarios, the company (somehow)feels obliged to let him\her* manage 4-5 people so there is no fat chance he’ll write code in the coming 2-3 years. I believe that this is the top-1 fatal mistake companies do. They are losing their most talented, most efficient programmers without the right adjustment and natural growth by the rest of the team. The way I see it, this is what a Team Leader should be responsible for:
  
  
  
  • Code for at least 60% of his time. Not 20%, not 30% and most definitely not 50%(this will cause him to fall back into 60%-40% manager). Great war leaders were great warriors, always on the front of their men. If you prefer to be left behind(technology speaking), managing from above, you should not be a Team Lead.
    
  • Get to know your people – what do they like to do after work hours, what are their hobbies, write down their birth-dates so you could buy them something symbolic. Make them feel like home. Spending 10+ hours in the office is more than most of us spend in our home. Notice how a very cheap gesture may change your team’s world – some people like fancy keyboards, some(I’m included) prefer a big LCD screen and others prefer an extra bonus. Let’s say that you invest up to 500$ per person, the ROI is still tremendous(try to think your hourly cost and how fast you’ll return it). People will have everything they need(=want) in their office. Google is famous of hiring the best just because of taking care of the small details.
    
  • Manage your team’s time – help to set the deadlines per sprint\iteration, but more important – analyze the team’s productivity by picking up time estimations and actual time spent, and perform some calculation via various tools to understand the bottlenecks your team experience. Make them see, make them witness of how they can become more productive with the right set of exercises.
    
  • Be a mentor by leading the team with daily improvements. Change the way they think, blow their mind with new stuff. Direct them to “home reading” that you know they’ll enjoy. Make them excited! Be a great developer for them.
    
  • Shield your team members from political business. Make sure no one is interrupting them meeting the deadline.
    
  • Meet the deadlines. Don’t afraid to speak your mind when things are out of track. Make them see you’ve got what it takes to lead them back to the right path. Tough love may create great developers with the right amount of genuine caring.

         This will allow the Team Leader to remain an efficient programmer and the team grow into the new situation.         
 

• Big teams
  Team size should never be more than 4, where preferable(IMHO) is 3. We want our Team leaders to write code, remember? Managing more than 2 people other than yourself will make your TL too busy to code. Even worse, big teams will cause team illness:
  
  
  
  • No matter of how much good-will exists in the team, keeping many people in the loop is simply too much overhead. It will wear off your teammates.
    
  • This will divide the team into smaller “virtual” teams, each one is built around a user story or a complete feature.
    
  • Now it’s getting hard to know when you’re breaking things for others as no one is really into your teammates code or requirements.
    
  • This leads us to the most unwanted behavior – no one in these virtual teams is an expert on their domain as the team switch context all the time to meet the big team deadlines. Context switch and lack of domain experts will kill you team. From inside out.

         Keep your teams small. Managers should sync the small teams and keep the eye on the ball for them. This is their skill, their talent.

• Waste valuable time on the wrong tasks – skills .vs. tasks impediment
  This one really gets me. How many times you’ve been asked to do something you know you shouldn’t have assigned for? Giving a c++ hardcore hacker to write HTML is silly(at best). Now, I can relate to the feeling managers have assigning these tasks  just to keep the deadlines but this shows of lack of creativity rather than good leadership. For example, the c++ hacker will cost around ~X5 then a young talented designer (by young I mean 16 years old cool dude that’s doing it from age 11). Hire someone, even for a few hours a month and let the them do their magic. From some reason, managers never thought about hiring a graphic designer to write hardcore c++ code, right? It will be amazing to measure the ROI you can show your bosses even after 2-3 iterations just by putting the right players in the right positions. The same goes about database, system administrator, (customer)documentations etc. Stop treating someone’s time as equal to someones else time. hardcore multi-threading guru will not enjoy a full day or two of playing with HTML to fit different resolutions. Be creative and make the adjustments! 

I have a lot more rants and tips but I’ll leave it for further posts so be good and stay out of software jail.

^[*] – I’m sorry but writing him\her all over the place is plain crazy. You know I’m no sexist ;-)