I think the “People Problem” relates more to productivity than to technical problem solving/coding. If you have people problems, most likely this will lead to slow downs, increased aggravation, and stress levels with in your team.
But, I also believe that problem solving and technical challenges play a huge role in programming and “engineering” in general. At this time, I don’t think we can consider programming to be an “engineering” disipline. Consider the problem of creating a circular charge around a core of an A-bomb. A very technical problem which requires smart people. People personalities only go so far to solve the problem. Programming is like that as well.
For programming, these traits are essential for good team:
Problem Solving - Get Things Done
Technical Ability - Smart
Understanding your limits - Help I’m stuck on a problem!
Honesty
Proficiency, Skill Set
Do we like this person?
Any company hiring a programmer should give a quiz on the language that is being used for code. A good quiz is to have the person sit down in front of a computer and solve a problem. Use the internet, visual studio help, whatever. If you interview with a companies with no technical interview, then you probably be working with some under qualified personel.
Many people call process problems people problems. For example, if your reviewing doesn’t work, maybe its not about wrong people. Maybe your processes are flawed. Alright, if you have bad processes, its ultimately somebody’s fault. But then again, who is this somebody? A person? No, somebody is just a concept. Somebody is not a real person.
So you need to get your processes right. In the end, the process might be automated. Then it has no people in it. People are the problem. When you automate, you don’t need any people - no right no wrong people.
Still plenty of problems are related to peoples, when they are behaving badly or something. But its not always about being a good team mate and a real good pal. If you don’t get the processes right, you are in trouble.
Jeff, have you had the chance to put that suggestion (have prospective candidates give a 20-minute presentation on one of their areas of expertise to a few of your key team members) into practice yourself? If so, how did it go? (Maybe a topic for a future blog post?)
Process doesn’t write code. (Unless its automated process.)
But its better to get the process right before you start writing so bad code that it is not maintainable. Happy people that enjoy working together, do lots of neat stuff, and share ideas willingly: If the process is bad, those people are not very sustainable.
Usually people who are considered productive and good working fellows are more like extroverts. But at the same time they like to do more experimenting, share ideas, have good time solving tricky problems, entertain the customer and so on. But who thinks about the process? Process is not someone who you would consider to be entertained or cared for. But everything you do, is actually part of a process, written or unwritten. People change jobs and company, but the process stays.
With the right people process can be fixed, yes. The question is, are they fixing the process?
Just had some Lean manufacturing and 5S training. The trainer’s main points were not the processes and techniques, even though he spent most of his time on them. His main points, which he kept repeating were, to get the people on side and create the culture that lets Lean and 5S happen.