Skillz is my current project, where I have been involved for over 6 months now. The core part of Skillz is to do a Talent Management while additionally it supports performance management.

This is a breed of very interesting project for me with lot of grilling, learning and testing one’s self Talent Quotient. We faced lots of challenges and kept working our ways through to achieve what we initially set out to achieve. With time the product evolved as we developed a stronger understanding of the requirements across industries and formed our own opinions on how these should be addressed. It has been a real interesting journey, delving into unknowns, digging out answers and putting it into implementations. I feel like sharing some of my experiences with Skillz here for benefit of all developers and architects, trying to decipher the same unknowns.

The Challenges

The First Challenge

On this project the biggest challenge was the need to correctly understand what Talent Management is and what is really expected of a Talent Management application. While researching, I found many articles and blogs explaining Talent management.

The problem with the information and articles out there is that it creates a fair amount of confusion between talent management and performance management. Both are fairly inter linked. So much so that at times it becomes hard to differentiate between the two. It is like you have been asked to differentiate between the words [opinion, attitude, belief and faith]. We compared few products currently available. Some of them were far from catering the actual need of talent management, while others offered a wide range of tools most of which, would be of no use to most organizations.

Only some were quite near to what was expected. There are quiet good articles out there on the web, worth mentioning here. Tony DiRomualdo in one of his article defines seven management practices that matters. He is in a view that for becoming a well rounded talent requires continuous learning and development of knowledge and skills. One of the articles published by Nasscom and written by Prof. Peter Cappelli, Center for Human Resources, University of Pennsylvania, explains the more subtle difference between Performance and Talent Management titled Talent Management is a business problem.

The Second Challenge

Another, challenge was about architecting Skillz, such that, it fits into the requirement posed by different industries. A skill itself varies hugely from industry to industry. To explain this, try comparing some common skills for a Doctor, Bank Manager and a Software Developer. Specializations for a doctor (like MD, MBBS etc), matters much more, than it does for a Bank Manager or a Software Developer. Similarly, Global Client Exposures for a Software Developer is more important than it is for a bank manager or for that matter, a doctor. Accounting exposures stands more important for a bank manager. Thus a common skill like education or experience needs different design for different industry/practices. This is because individual professions and verticals vary hugely from each other. This leads to a fresh challenge; the very fundamental nomenclatures used in the application, changes completely depending on which vertical the system is deployed in.  A classic example for this is the entity ‘user’. For every vertical where skillz is implemented, the very meaning and attributes for a ‘user’ changes drastically. Attributes like medical registration number and Medical Specializations make more sense for doctors than they do for developer or a bank manager. Rank/Grade does not imply to a doctor or a software developer.

Further, aspects like Security, Reporting, Usability together with the nature of Talent Management, additively, pushed the design of Skillz to a level of challenge.

Solving the challenges

Solving First Challenge

The first challenge took the major portion of our time; which was spent in   discovering the true nature and taste of Talent Management vis-a-vis differentiating it with performance. Talent Management is all about getting the right people with right skills into the right job by measuring the following quotients:

1. Learning Quotient (LQ): Measures how an individual learns and improves
2. Conceptual Quotient (CQ): Measures the ability of thought process in solving a problem.
3. Relationship Quotient (RQ): Measures how an individual behaves in a group
4. Action Quotient (AQ): Measures the individual as a team member by his actions.

For an individual the Talent Quotient (TQ) = (LQ+CQ+RQ+AQ) * Values.

Well, how do we measure it? I am sure our HR would be highly interested and can add another hundred paragraphs here about these quotients, process of measuring it, appraisal, questionnaires and many more.

Different companies have adopted different techniques to measure the TQ. The most common techniques  used are appraisals, interviews, trainings and feedbacks. But, seldom people understand the continuous nature and difference between the talent management and performance.

Now the most interesting part, Talent Management is not only about measuring TQ. It is about Identifying TQ, Acquiring TQ, measuring TQ, mentoring TQ and Retention of TQ. So where does Performance comes in? The answer is:  

TALENT MANAGEMENT + PERFORMANCE MANAGEMENT = PERFORMANCE

Put simply, tracking ‘performance’ is much more than most people think of it. It doesn’t start and end with performance management. Talent management which involves acquiring, goal setting, training, mentoring and retaining individuals also forms a huge part of tracking their performance.

Building a system which allows administrators and implementers to capture talent management and beyond was our initial design goal for skillz and after months of hard work, eating our own dog food and months of testing with a couple of beta customers, we believe we’ve come decently close to achieving it.

This solves the first challenge!

Solving Second Challenge

The second challenge was to design a system which fits into various industries catering to their unique needs. We decided to have a core system and extend it according to the organizational need. User, Skills, Activities, Trainings are entities within the system which are simple, flexible and easy to extend.

Security within individual organizations can be easily configured and tweaked by individual organizational administrators. Skillz is designed to be offered as a service (SaaS). For us this means easier deployments for all our customers and for our customers it means easy updates to newer versions as we continue to work on newer versions and add new functionality.

Skillz is a result of months of hard work, countless brainstorming sessions and a lot of thought that has gone into areas like security, reporting and usability. We’ve given special attention to extendibility so that customers can tweak skillz to fit their requirements.
 
The following diagram defines some interesting prepositions that are uniquely available in Skillz.

Even though we’ve been using it within small teams @ eFORCE and with some of our beta customers, the official launch date for a public beta will be announced soon.

The entire team is very excited about its acceptance, performance and criticism in the world of PERFORMANCE. This release for me is the starting of the race which we struggled to qualify and it took us almost one full year.

I hope this article is helpful for those working in similar areas. I would keep posting more about Skillz as and when time permits.

Thanks,
Manish

Monday, January 19, 2009 2:14:29 PM (GMT Standard Time, UTC+00:00)    Comments [5] Trackback

I have seen many programmers and senior programmers showing their prowess in implementing and justifying a design pattern implementation. Before doing so one should ask a very simple and honest question to self, “Do I fully understand it?” I am sure many of you, would say off course, what’s the big deal. Now look at your decision once more by answering the following questions:

1. Does your team, working with you also understand the pattern correctly? Are they comfortable with its implementation?
2. Would you be there till the project reaches its logical end or do you have at least one successor who would be there and understands the pattern correctly?
3. Does it require other members to follow a set of rules while coding?
4. Do you understand “What it solves” OR “How it solves”?
5. Are you thinking about scalability or maintainability?

Thoughts on Question 1

Most of the serious projects require a team of developers working together on different modules. If they do not understand the pattern, it is more likely, that you would encounter chaotic and unorganized codes. The common evils are repetition of codes which explains the lack of understanding the design pattern, code tweaking to override design pattern, hard coded lines, code spaghetti and more. Wow these codes could kill.

Thoughts on Question 2

Something that remains constant in software development is “Change”. It is inevitable and the requirement itself keeps changing. No doubt the design patterns are there to help, but when it requires any change, who’s going to do it? In case it falls in a wrong hand, it would shit all over your effort and logic.

Thoughts on Question 3

If your answer to this question is YES, then you must ensure you understand question one, and keep a constant vigil or do a knowledge sharing for your team to bring them on the same page, else the errors and problem can pretty quickly escalate making your module a piece of shit. If your answer is NO, then you need to worry about question two only.

Thoughts on Question 4

A big question! It is really easy to say what it solves, but knowing how it solves is entirely a different ball game. You need to think on what is the price you need to pay for implementing it, what are the other alternatives, is there a mix and match of patterns to suit your need, does it increases the complexity of the module or simplifies it, what is the cost of maintaining it, how frequently it is expected to change, what are the impact points etc. etc. I am sure it would make you crazy, at first it seemed to me as a simple question but later wow!

Thoughts on Question 5

You must read what other people think about scalablability. Damien Katz, in his post, writes about crappy programmers, boasting about concepts like enterprise, scalability and patterns without actually understanding it. Another hilarious and a bit “PG” post by Ted Dziuba, where he is really pissed off and frustrated with people talking about scalability without having a good knowledge of it. In sync, there is another post by Rajiv Popat where he talks about the best practices and people who seriously talk about such concepts but are not able to answer the simplest questions he asked.

Design patterns are not meant for scalability. It is about extension and maintenance. It should reduce the impact of change, help in decoupling the elements of module interacting with each other, reduce maintenance cost, provide extra room for extension.

Tuesday, January 13, 2009 5:17:12 AM (GMT Standard Time, UTC+00:00)    Comments [0] Trackback