Frank Willes talks about the high cost of hiring inappropriate programmers, I also feel the same way – I know that the “benefit” of hiring a completely unappropriated programmer can even be negative (one person can easily do more harm than good). Still, some of his affirmations puzzled me; he made a few clarifications in this very interesting followup on the subject , but I partially disagree – so let me explain.
First of all, he claims that in many situations companies can and should staff themselves with the vast majority being experts. I don’t agree here: first of all, it is extremely hard to staff a company with experts-only. There are simply not so many available… and for larger companies, it is simply impossible. Besides, assuming you would somehow manage to find those experts – it is extremely hard to manage them; they are often hard to please, they have strong personalities and are used to “being right” when it comes to technical solutions; but real-life problems often have more than one good solution, and I suspect that in a large team of experts, conflicts would easily spark – as it is likely that different people may choose different solutions. You may say that they are wise enough to avoid conflicts… but I’m not so sure. An expert likes to be “the first violin” – and in a large all-experts team, some of them would necessarily be (or at least seem to be) more “important” than the others. This is a sure recipe for disaster.
Let’s ignore even these practical considerations. Say you could have harmony in your team; there are more reasons to have “non-experts” in your team.First of all – the young, talented programmers do not qualify as “experts”. No matter how talented you are, and how smart – you are not an expert when you graduate the university. You still have to learn all the things you are facing when you build and operate a real product, when you work with real customers, when you work “a la longue” with the same people, in the same team – sometimes, a distributed team. You need to learn when to make compromises and when to avoid them – yes, you need some experience; everybody does. (when I graduated I used to hate my company for remunerating a lot “experienced” employees, who were very bad programmers; I understand now better why they did it – they were wrong, in that particular situation, but it was simply too hard for them to make things right; anyway, more on this in a further article).
Going back to the “rising stars” – young, resourceful graduates or even students: yes, a team of fresh graduates would probably not have the experience to put together a product. However, a young graduate has something to prove to himself and to the world: his worthiness. He does better than his peers in university – he wants to be better in the industry. Moreover, he is eager to learn – and being smart (we are talking about really smart students or graduates, right?), he understands that he can always learn and is in fact focused on “learning”. As such, he has two major advantages: first, he accepts the role of a “lesser-importance employee”; he is eager to work under the “coordination” of an expert, he will challenge the expert’s solutions but he will eventually accept them when they make sense. Secondly – he works hard. He has something to prove – he is used to being among the best, so he wants to make an impression. IMO, in an ideal team – you should definitely have at least as many “young talents” as you have experts. Say 1/3 experts. 1/3 young talents.
What about the rest of the team? Well, if your team is small – like, 5 people or so – you don’t need this third category. But if it is larger, you definitely do. A larger team means that your project is really large – so it surely has some non-interesting stuff to do. Probably, lots of non-interesting stuff. You could have your experts do that – but they will eventually be bored and will leave for another company. You could try to have the “young talents” do that – but that violates one of the primary goals of a young talent: to LEARN, to do something interesting. No matter how you look at it – you need some average programmers to do these tasks (if they are a little above average, it is even better). And they actually have a very important role in keeping a “healthy team”: not only they can do the tasks your experts don’t like, but they are expendable and they serve as a healthy “reference”. See – your experts don’t like to be the last wheel of the wagon. If all your team is full of experts – one of them will inevitably be the weakest programmer, he/she will be (or seem to be) less critical for the team. If you have “young talents” – things improve a bit – but not very much. The young talents, as I described them, will be every bit as smart as your experts – sometimes, even smarter.Yes – they lack experience; but they will more than make up for this, with their increased determination and motivation. No, your experts will have a hard time if they try to feel “technically superior” to a young talent.They won’t get that feeling of importance, that feeling of being “better and more important than most of the team”. Even your young talents, who are probably ambitious, will need to feel that they are gaining a lot of importance; the “average programmers” will provide the initial “easy victories” – a young talent will feel that his work has attracted the attention of the leadership, that he is viewed as being better than some of the team members – but he still has work to do, to become one of the ‘experts’. This can only work towards motivating him more.
I realize that this theory is not really “politically correct”, and it may sound evil to bring some “expendable” programmers in the team just because you need a negative reference. Ideally, people should be judged by their merits only, and not relative to the others. Unfortunately, in the real life – not only we judge other people relative to the others, but we judge ourselves relative to the people around us. ” In the country of the blind the one-eyed man is king“; unfortunately, this works the other way around too – “in the country of x-ray vision, the normal man is blind”. There is even an old Romanian saying along these lines: “decat codas la oras, mai bine-n satul tau fruntas”.
To summarize – I do believe you need three categories of employees, in an ideal team:
A. Experts – they know how to get your product out, in time, and with smooth functionality. They know when to accept and when to avoid compromises. They know the market and can properly interpret the customer input – they can take a poorly-formulated customer request and understand what is the thing he actually needs.
B. Young talents. They are smart, they are up-to-date with new technologies, they have good general knowledge (experts may often be a bit “focused” on a particular field, and miss up on news from other fields). But most importantly: they are highly motivated, and they work hard. They are willing and able to do most of the actual coding in your product – and they are even more efficient at this than your experts.
C. Average programmers. They are typically cheaper to hire, they can do the less challenging tasks (where it would be an overkill to assign an expert), they are replaceable and as such they serve as a reference so that the others can easily see how critical they are for the company.
There is still one thing missing from this picture: it’s not enough to hire experts and young talents. You have to retain them, otherwise you accomplished nothing – all your work will seem like a Sisyphean task.
Frank is puzzled by the fact that companies typically pay only a 10-20% premium for an expert over the average programmer. While this may seem stupid at first sight, there is a very good explanation for that: Maslow’s hierarchy of needs. Programmers typically earn good money – once you have a home, a car, you can afford food, entertainment, vacations – how much value do the extra money ad? I mean, really, how much happier is one to own an Audi instead a Skoda, for instance? Sure, it means something – I’m not saying it doesn’t. But once our basic needs are satisfied, most important (from a salary p.o.v.) is to feel that you are paid fairly. If you’re not paid fairly (e.g. someone with an inferior contribution gets payed more, or your friends working for other companies are payed better) – then yes, it is a problem; but otherwise, being paid 20% or 100% better than “an average programmer” makes almost no difference – other things are far more important. I already detailed the “esteem” part (all your expert programmers should have a feeling of achievement and the respect of others) – you need to work towards creating an environment of “friendship” (team members should really be friends), providing challenging and creative work for them, and at making them feel important and “personally involved” (this is why it is easier for startups to get experts – having a good share of the business gets you quite involved; share options in large companies do not accomplish this goal, since one persons’ influence in a 50000-persons company can seldom be significant).
Which actually means that you should have a “manager” which is an excellent “people manager” – never forget you are working with persons, not machines, and each person is unique. There can be guidelines, but there can be no sure “recipe for success”. Actually, if I am to pinpoint a single most important person for the success of the product – and eventually, the company – it is the team manager. Ideally, he should be very skilled at working with people, understanding their needs, their wishes and – why not – their dreams. At the same time – he should be a technical expert himself – this will not only help him understand & evaluate the team members better, but will also help him hire great staff as well as get their respect and recognition as a manager.
Unfortunately, such people are extremely rare; if I hadn’t met one myself, I would think they don’t even exist. The practical solution is in diversity: you should have people in your team who are very good at tracking progress, documenting work and keeping everybody on track; people who are very good at “smoothing” the relationships, and “fixing” conflicts; people who are good at socializing and creating a team spirit; people who are very good designers; people who are experts, in various technologies – preferably, not a single one; and so on. Of course, these roles may “overlap” – and it is good if you can find someone who can do all these tasks; the problem is, you are lucky if you find one who can accomplish 2 or 3 of these roles – so really, be on the lookout for diversity in your team, and always try to find out what exactly is missing. This may not always be obvious – but hey, life is complex 🙂
[update]: I have left out of the discussion, on purpose, the “definition” of an expert. Yes, I give a few guidelines of “stuff you may expect from an expert” – to hint the reader about what I understand from the term “expert”. However, a company may define it’s own expectations from an “expert” – to put it very shortly, my point is
- If “expert” is someone “experienced” – then no, you don’t want to have an all-experts team, it can actually be better to have novices too in your team
- If “expert” is some very creative, or very knowledgeable guy – then again, you don’t want an all-experts team; not all tasks require creativity, not all tasks require extensive knowledge, and so on
- Even among the “experts”, there are many domains of “expertise”: technical knowledge of some specific technology, target-market knowledge, attention to detail, creativity, human interaction and dealing with people…. it is highly unlikely that any single “expert” would excel in all these areas. What you need is diversity.