In one of my earlier posts I claimed that project management had a lot to do with understanding the human mind. In the same post I also went ahead and admitted that I'm no expert at it. Having admitted that, the amount of time and effort I have been dedicating and still dedicate to understanding the human mind and people issues is as much as the time and effort I dedicate to understanding code.
As a matter of fact, the time I spend to understand human beings in teams is sometimes even more than the time I spend trying to read and understand code. Studying programmers and how they function in a team fascinate me; as much as programming does. After all, I love everything about software development and team dynamics form a huge part of it.
I've seen countless college interns, fresher's and even regular employees being recruited by companies based on their 'analytical skills', 'mathematical skills', 'academic qualifications', 'educational background' and 'grades'.
I've also seen a huge number of those decisions turn out to be complete disasters. I've seen a few top notch graduates from top grade colleges who have toped three rounds of technical interview turn out to be complete pricks and in-compatible when it comes to working in a team. I've also seen programmers with humble starts out perform, get the team together and drive projects through the doors of success.
Some of these experiences have made me to think that maybe, just maybe, organizations that evaluate candidates simply by using these black-and-white-approaches of judging them simply based on their 'academic background', analytical skills' or even 'technical skills', might be missing out big time on opportunities of recruiting a completely different breed of employees with qualities which are just as, and sometimes even more important for successful implementations, rather than just having 'technically-kick-ass programmers' on the projects.
'Catalysts' form a part of these different breed of employees. DeMarco and Lister, in their book, Peopleware: Productive Projects and Teams (Second Edition), describes Catalysts and their contribution towards making a project successful:
|
I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project she's not a great developer or tester or much of anything." With a little investigation, I turned up this intriguing fact: During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn't obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn't recognize the role of catalyst as essential to a project. |
I've worked with a couple of really awesome catalysts myself in my professional career. After having realized the importance of having catalysts in each team, I've also learnt that there is no one-step-formula for finding and hiring this breed.
These are candidates who will show up in your interview, will perform very averagely in them at the same time send you a very good vibe by connecting to you, their enthusiasm, passion for learning and connecting to other individuals resonating very strongly, leaving you completely confused on whether you should hire them for their potential and attitude or let them go because of their average scores in the technical rounds.
Just like hiring any awesome individual, in order to hire a good catalyst, you have to go with the facts, your experience, gut-feeling and then finally get lucky.
These are candidates who may not be able to solve those puzzles your organization wants you to ask them or answer all of those interview questions that good .NET developer aught to know but one of the biggest blunder managers and organizations can do is undermine their contributions.
I've personally witnessed countless occasions of failing projects starting to become successful over a period of time after a catalyst is introduced in the team. I've also seen successful projects starting to stumble when a catalyst leaves or is removed from those projects; and in all these cases the catalysts weren't contributing anything that can be described as majorly critical when it came to code or tasks in.
If you're building a team, leading a team, or working for a team, remember that the role of a catalyst in a team is as important as the role of the best programmer who is shipping the most complex and critical modules. Go ahead, look around you; or think of the people you work with. Is there a catalyst holding your team together? If yes, are you giving him due credit and appreciation for his contributions?
Comments are closed.