People are not “resources”. Everybody is unique and different and you as a leader should be very empathetic and sensitive to individual people’s quirks. However, at the very high level you can classify programmers into one of four rough categories, that require four different strategies.
This category doesn’t really exist, but I’ve met people insisting that it does, so let’s start with busting this myth.
A Slacker has all the skills to do a quality work, but is inherently too lazy to do so. Surely, such people happen. But way less often than one would think. And in the industry with such a steep learning curve as programming?
Programming is hard. It requires continuous self-education. A ton of it. Maybe – just maybe – there are a few lonely Slackers at the most entry-level positions. But among the skilled, experienced programmers? How would they make it that far?
When you hear your programmers talking about the cool tech they played with in their free time, and then see them doing a poor job at the office, it’s definitely not because they’re lazy. They may be Misfits or Impeded, but not Slackers.
And what if you really have a Slacker in your team? Just fire him. There is no much else you can do. But, so far, I still have to meet one.
The exact opposite of Slackers. The other end of the spectrum. Skilled, motivated, reliable, aligned with the company’s mission and jaw-dropping productive.
Such programmers, let alone the whole teams, aren’t common, but unlike the Slackers they do exist. Although, they seldom just happen. They are typically a sign of a mature organization, with stellar leadership. If you brought your team to that level by yourself, then you don’t need my advice. But let’s assume you were lucky and just got hired to lead such rockstars. What do you do?
Leading Ninjas on a day-to-day basis is easy. Just blend into the background, leaving them as much autonomy as possible. They will do their job with flying colors without your intervention.
The hard part is to bring them to an even higher level. How can you do that if there aren’t any obvious impediments to remove?
The primary thing you can do is to arm them with the right metrics. Top programmers don’t have to be coached about their craft, but they’re often not as experienced in the process related techniques, especially at the team level. And as an old adage goes, you can’t improve what you don’t measure.
Another thing you can do is to encourage experimenting. Growth comes from trying and making mistakes. Don’t treat them as failures, but as learning. It may seem counterintuitive to expect mistakes from Ninjas, but no matter how good they are, they need the same process as everybody to improve.
Companies have various cultures, ranging from very rigid and formal to almost completely anarchistic. Culture is extremely important. It’s the most defining factor of the company. And there isn’t a single best one.
I can see you passionately disagreeing right now. I’m almost dogmatic about this, too. But believe me, I’ve seen programmers that can’t stand having a daily meeting at the same hour every day as well as ones that were glad to be guided by hand by their manager.
We could argue where the sweet spot lies, but what’s non-arguable is that a programmer struggling with a mismatching culture will be demotivated and her productivity will drop, no matter how skilled she is.
What can you do with such Misfits?
You can try to convert them. This is definitely doable, even religious beliefs can be changed. But the success rate will be low and the effort won’t be worth it.
You can force them into submission through so called “motivational” (read: “rewards and punishments”) systems. This is short-sighted solution, and although it may work for some time, it’s guaranteed to backfire.
The last option, sad but unfortunately the best, is to fire such a cultural Misfit. Instead of struggling with him, you should focus your energy somewhere else – at your recruitment process.
First of all, you must be transparent. Don’t over-advertise during recruitment, in fear that by being honest you may lose an outstanding candidate. If a candidate doesn’t fit your culture, you’ll lose her anyway sooner or later, only with much more pain for both sides.
Second, you must be very sensitive to the candidate’s cultural preferences and inquire her thoroughly from this angle. A candidate may not be experienced enough to properly assess your company’s culture, even if you are transparent, or may simply be unaware of the importance of a cultural match. It’s your, not her, job to catch this.
We’ve got to the last category. Our programmer is not a Slacker, she is aligned with the company’s culture but she still doesn’t perform like a Ninja. Why?
She’s Impeded. Something stops her from reaching her full potential. Identifying and removing such obstacles is your primary job as a leader.
There are three main categories of impediments.
The first one is the lack of skills. The solution, although not quick and simple, is straightforward: facilitate learning. Provide coaching, professional training, learning materials, organize peer code reviews or pair programming – create an environment where growth is inevitable.
The second common source of impediments are organizational problems. Too slow Continuous Integration server, noisy office space, Product Owner difficult to reach, poor understanding of Agile process by stakeholders. These problems usually require you to coach or negotiate with non-tech people “upstream” of the dev team or to lobby the executives for necessary purchases.
The last and the most tricky category is the lack of motivation. A common error is to treat an unmotivated developer as a Slacker or Misfit. However, there may be many more causes of low motivation.
Sometimes they may be personal, e.g. family problems, but most often they result from organizational or leadership problems like outdated tech, unclear product vision or too much pressure. The role of a leader is, again, not to blame or press developers, but to focus on removing or mitigating the root causes of their low motivation.
What types of programmers do you have in your team? What do YOU do to support them? Please share below in the comments!