"The future is here. It’s just not widely distributed yet." William Gibson
Gregory Ronczewski is the Director of Product Design at TeamFit - view his Skill Profile
Successful interaction is based on dialogue between—on one side, the user and the information that is entered into the system, and—on the other side, the information the system provides before and after the interaction. We know the information is needed for decision making. This information should be correct and presented in a suitable fashion. It should be provided at the right moment depending on the place in the customer journey. The system assumes that the user has some information, the question is when this assumption is correct? In Ibbaka’s case, when we present the Competency Model Module, what do we know about the user? How knowledgeable are they when it comes to building a model? Have they designed many such models or is this their first attempt? We need to capture what information user enters into the system, at what time, what moment in their journey, but we also need to anticipate what information the system is capable of presenting which in return, which will lead to more interactions.
We came up with a few different scenarios to support the many different ways one could start building a Competency Model. Exploring these options helped us to refine and understand critical drivers for each type of user.
What are some of the ways a competency model is applied?
The use of the Competency Model Module is a service and as such, detecting trends, signals and goals has implications for how the system reacts and supports the user and also for how it evolves. This is the key difference between our approach and existing competency models - our model is not static. It is continuously changing providing insights into the future of work, mapping and analyzing local and global trends. We are using a Service Design approach to achieve this.
Let's look at some of the scenarios we have been using during our design process. To begin, we've decided to divide users into two general groups: the group with editing/administrative rights and people who can observe and learn from the model. Apart from this distinction, a set of design principles helped us to stay on course. Among many, here are a few that I think shed some light into what kind of environment we are proposing:
- Less is more. Show just one element at a time, do not clutter the view.
- Context is everything. Make sure to show the relationships.
- Respect the user. Accept their decisions, support - not obstruct.
- Be smart. Offer help when it's needed. A smart assistant approach.
- Do not limit how the module should be used. There are many ways the user may want to use their model. Support each idea. Learn from it.
For instance, let's imagine I am creating a brand new Competency Model. Where do I start? Well, skills are the building blocks, like Lego bricks. There come in different types, sizes and colours. I can start by collecting all the skills that I think are critical for my model. To do this, I can search for skills, and after a few names have been entered into the system, our AI kicks in and starts providing suggestions. Having said that, one click and the smart assistant is turned off. I am making a collection of skills. So far so good.
What if I don't want to start with skills? That's fine too. Each model can be customized to support the structure the user wants to implement. I can have "disciplines" at the top and inside each discipline add "jobs" and inside "jobs" add "roles." Or, perhaps I want a more fluid organization where people float from role to role without formal job titles (as happens in many professional services firms). Not a problem, just delete "jobs" from the model. Customization allows me to prepare a hierarchy for my model. The Settings page offers me a chance to use Ibbaka’s skill categorization (social skills, business skills, domain skills, etc.) or create a unique categorization system for my company. When a Ibbaka Talent user self-assess skill competency, we use five levels to capture this. But, if I prefer to use just three, that is fine as well. I could even use ten levels if I so chose. Basically, we want to be as open as possible accepting every approach to building a competency model.
Let's go back to my initial collection of skills. Now what? As with with any collection, it is best to organize it.
Skills can be moved to any place in the model's hierarchy
One by one or as a group they can be added to multiple locations. For instance, I can prepare a set of Social Skills and add them to every role inside two jobs. On the other hand, I may want to take a very different approach. I may start by uploading documents, job descriptions, memos describing processes and all sorts of other documents. Ibbaka Talent will extract skills and roles and populate your model for you. Once this is done, the model designer can go in and fine-tune the results.
We are also planning to have a set of well defined, common roles with a set of core skills that comes with them
For instance, Project Manager, or Data Analyst or Design Thinker. When I am building a model, I will have access to all of these roles. Adding a pre-packaged role will bring all the skills associated with it.
Now I have my structure. I have added jobs and roles as well as a few pre-packaged roles into my model. What else can be done? Each stand-alone skill has relationships with other skills - those are complementary and associative skills. Once you place a skill into your model structure, many new characteristics will emerge.
Level of expertise
Does this role require this skill to be at a certain level? If it does, it immediately leads to a whole array of insights. Knowing who is in this role in my organization and what assessment of the skill looks like, I can see how it compares to the model. Is there a skill gap or not?
Finally there is learning resources
Our model allows one to add learning resources to any of the elements. I can add learning resources to jobs, roles, behaviours, skills. This is probably the most important aspect of the whole project. Knowing the gap in the current model, or the gap between the current model and the same model set into the future is one thing, but once you identify learning resources, you can prepare a learning path for individual users as well as for larger teams. It helps to identify the problem and to show the solution. Knowing a problem is only half of the equation - knowing the solution closes the gap.
Well, that's the plan. We are now reviewing prototype number five. We may need a couple more. Send us a note if you have any thoughts on this. I will write another post, probably in a month with an update.
