Thinking of competency modeling and related efforts exclusively as an “HR project” – and not as a Customer/Client-centric business process. Competencies, by definition, in some way touch every dimension of and department within an organization. Well conceived competency models are customer/client-centric. They start with the very basic question: “what is it that we are in the business of providing that customers/clients are willing to pay for?” That in turn determines who we hire, develop, promote, reward, etc. We do those things because those people possess the competencies we need in order to fulfill our customer/client needs and demands.
There are of course a multitude of “Talent/HR reasons” to get competencies right - and we should for those compelling reasons too as we'll explore. For example, they can serve as a tremendous strategic retention and development tool as I hope you’ll read further about in my “Missing the opportunities to….” section below. However, the at least equally direct core connection competencies should make to the business via a focus upon customers/clients (i.e. the very reason for being in business) is often overlooked.
Competencies that are defined and deployed utilizing concepts and language that tightly align with customer/client-facing initiatives and materials really do have IMPACT – they really do influence how employees behave, prioritize, and communicate. I also believe that most individuals in fact crave and are more likely to feel fulfilled in their roles by making a stronger connection between what they do and what their organizations do. This, by the way, is one of the very best opportunities I can recommend to HR/OD professionals who are seeking another meaningful way to work even more closely and strategically with their internal clients.
Overload – developing competency dictionaries “by the pound” that have little hope of seeing the light of day from effective implementation and utilization perspectives. Sometimes competency models are cobbled together as a repository for skills referenced in job descriptions, interview guides, training, and other materials. This can result in redundancy and inconsistency (e.g. regarding level of detail and nomenclature) as well as imply a false sense of security and satisfaction that deliberate strategic integration has occurred – the less desirable “accident” I referenced in my introduction. By contrast, a thoughtful and focused approach consistently guided by “what do we really need and expect our employees to be able to do to achieve our current objectives?” results in more effective and efficient outcomes. Organizing principles in the forms of appropriate competency frameworks and architectures can be employed to further “stop the madness.”
While there is no universally agreed upon number of which I am aware, it is unlikely than an individual in a given position will be all that productive or effective attempting to focus upon more than say up to twenty competencies. Many would say fewer; fewer would say more. I’ve observed employees struggling with up to sixty – it just won’t happen. It’s symptomatic of a poorly defined job resulting in diffusion of focus. It may also reflect the confusion upon which I elaborate below regarding traits, policies/procedures, job requirements, and goals. Most of us are indeed expected to worry about more than twenty things during the course of a year (if not a day) – it’s just that not all of those things are appropriately deemed competencies. The nature of the job, organizational structure, industry, regulatory environment, and the particular competency architecture engaged are of course all variables – and why competency work is truly both an art and a science.
Underload – purchasing/downloading lists of generic competency statements and calling it a day - without taking the time to customize their deployment and application to meet our unique and dynamic business needs. While the wheel wasn’t necessarily meant to be reinvented, it can often be improved and may need to be resurfaced or resized to best travel the roads ahead. For example and generally speaking, the more technical a competency is, the more industry-specific it likely is. Of course there are exceptions and some skills may be readily transferable with some training. However, even leadership competencies can be made more relevant by considering such things as industry, company size, and a host of other organizational attributes and parameters (e.g. centralized vs. decentralized management, private vs. public ownership, corporation vs. partnership structure, international vs. domestic, maturation, and culture).
Sometimes we choose to believe that competencies are relevant only to a subset of an organization’s population - for example, that competencies are needed only for leadership groups or, conversely, for only more junior staff positions. Well defined competencies are relevant to each and every employee.
Not fully integrating and operationalizing. The power of well executed competency model work really comes to life when it is strategically deployed and integrated throughout a “cradle to grave” employee life cycle. This starts with the hiring process where behavioral interviewing techniques meet competencies. Further integration with job descriptions, learning curricula, career planning, goal setting, assignment processes, performance assessment, promotion criteria, and succession planning rounds out the cycle.
Other opportunities to strategically integrate include with:
- Strategic and business planning – to ensure the right competencies will be there and in the right places at the right times to meet the needs of the business.
- Ethics – to describe and reinforce expected behaviors and codes of professional conduct in the performance of day-to-day work.
- Marketing and Communications – to make a direct and visible connection between what an organization does and what its people do.
- Knowledge-sharing/management – to take full advantage of an organization’s intellectual capital and to harness the full force power of knowing “who knows how to do what.” Competency models can be an effective vehicle for cross-pollinating awareness of the full breadth and depth of an organization’s capabilities. We often hear one department admit or complain that they don’t really know what another department does.
- Initiatives – examples might include Diversity/Inclusion, mentoring, coaching, customer/client satisfaction, etc.
To points made previously regarding overload, burying the competencies that truly add value and have IMPACT somewhere in a competency dictionary the size of a large metro area phone book can and likely will stifle any real chances of meaningful integration and full operationalization. I alluded to “accidental” versus strategic and deliberate competency integration in my introduction and above in “Overload.” There is value in aspiring to create and foster a “culture of competencies” – where employees are drawn to their respective competency models and may use them in creative, productive ways not previously institutionalized or “hardwired.” This more organic integration/operationalization may also prove fertile ground for “best practices.” It turns out accidents can sometimes be good things – you may “catch” someone doing something innovative.
Not anticipating the future. Both hiring for and developing new competencies require lead time. Forward-looking and dynamic competency models can serve as a catalyst to ensure that we in fact are hiring the right new people and developing all of our people with an eye to the future. The answers to the following two questions should directly inform our competency model efforts:
What will our employees need to be able to do tomorrow?
Are we hiring, developing, and promoting with that in mind?
Not keeping competency models current - thinking of competency model development as a one-time, one-off, ad hoc special project versus as an important ongoing business process. In reality, the work is never done. In today’s ever increasingly dynamic and complex business environment, competency models can become stale quickly. Mergers/acquisitions/reorganizations occur, we re-engineer, we downsize/upsize, jobs blend and morph, new service lines are born, business operating environments change, and of course technology continues to transform the way we work. Gone are the days when the same person stays in the same job working for the same supervisor doing the same thing for the same clients using the same tools in the same regulatory environment for all that long.
Confusing competencies with traits, policies/procedures, job requirements, and goals. Traits may impact how and perhaps why an individual either does or does not demonstrate evidence of a particular competency. But in and of themselves, traits are not competencies. Think skills and capabilities – knowing how and being able to do something. In many organizations, prompt filing of time reports may be a condition of employment (aka getting paid) – a job requirement, not a competency. Using the phrases in parentheses below in the following examples may help to differentiate.
- Competency: Developing comprehensive and actionable workplans. (You are capable of… You are skilled in… You are able to…)
- Traits: Industrious, resourceful, motivated, committed. (You are… You tend to be…)
- Policy/Procedure: Review workplans with immediate supervisors in a timely manner. (You should…)
- Job Requirement: Submit a complete and accurate time report every 2 weeks. (You must… You are required to…)
- Goal: Achieve an 80% utilization rate. (Your goal this year is to… Your target is… You are expected to…) Note: goals and targets can be linked to specific competencies via performance standards and an individual may have a goal to develop a new or improve an existing competency.
Not thoroughly validating. Validation is the process of reviewing competencies with those who are charged with actually performing and supervising the work associated with a particular position to ensure they are truly descriptive of what really needs to get done. Sometimes competency models are created by teams of HR/OD professionals with the best of intentions but perhaps even collectively lacking the complete context, experience, and expertise necessary to develop relevant, accurate, and comprehensive competency materials. If the competency definitions developed don’t resonate effectively with the people actually doing the work, they have little chance of making a real difference. The more line involvement, the more likely competency models will be “owned,” embraced, and truly operationalized. Yes, this is something of an investment and sometimes external resources with expertise specific to a particular job or job family are engaged.
Not properly assessing. Some competencies lend themselves readily to quantifiable measurement and assessment – others do not. Performance standards may be used as a way to link specific targets or goals to competencies. Other competencies may be subject to more qualitative or subjective assessment in which case behavioral anchors or descriptors can provide a foundation for differentiating performance. In either instance, evidence of proficiency on a continuum is an effective way of assessing presence (or lack thereof) of a specific competency.
The continuum and associated assessment descriptors we choose will impact how evaluative versus developmental the assessment “feels” – as will what we do with the assessment results. Will we use them to determine performance ratings and compensation? Will we use them to inform training and development plans? Will we use them in promotion and succession planning processes? Or all of the above? Employees can become disenfranchised if we don’t tell them of our intentions straight up and in advance.
Assessment feedback can be gathered from a variety of sources including supervisors, project managers, team members, colleagues, subordinates, and even customers/clients. Many a spirited debate occur over such things as solicited vs. unsolicited feedback, anonymity, the value of self-assessment, quantitative versus qualitative feedback, and the magically optimal number of assessment/rating descriptor options. (Editorial comment: too many options imply a false sense of precision. 3- to 5-point scales appear to be most common in practice. A 3-point scale quickly becomes a 9-point scale if plus’s and minus’s are allowed.)
I’ve always believed we owe all employees as much clarity as we can possibly muster and have found it helpful to group assessment feedback into three categories:
- Strengths (most people have at least a few; some have many)
- Performance issues – weaknesses or deficiencies that need to be addressed in order to continue in a role; they tend to be non-negotiable (not everyone has these; hopefully, a relatively small percentage). These are never fun to discuss; however, it is critical to differentiate them from development opportunities as described below. “Sugarcoating” does no one any favors.
- Development opportunities – observations and ideas for strengthening performance, taking it to the next level, and progressing in the organization (everyone – even the highest performing – has these). They represent the interest we take in employees to further invest in their achievement and success. A development opportunity may become a performance issue if it is or becomes critical to job performance and an employee has not made acceptable progress in developing it.
Overlooking cross-cultural differences. Multi-national entities with employees scattered throughout the world are familiar with the need to be sensitive to differences in language and lingo. But many other companies with ever increasingly diverse domestic workforces don’t fully appreciate some of those potentially subtle differences. I recall teaching a behavioral interviewing class overseas where “problem-solving” was a competency we utilized in a mock interview exercise. It took awhile, but I came to realize that “problem-solving” had something of a negative connotation for some of my colleagues and students. They associated what is typically a highly regarded and valued competency in the U.S. with an inclination to make mistakes that needed to be fixed. Well developed behavioral descriptors supporting individual competency definitions are one way to mitigate the potential for misunderstanding.
Not consulting and collaborating - on an ongoing basis. For example with:
Learning/training departments. Learning and training budgets are beyond tight these days. Every dollar spent should be carefully aligned with the competencies that truly add value to the business. Competency gaps captured and analyzed via performance assessment processes can and should inform investments in learning accordingly. Self-directed learning strategies have continued to grow in popularity and lend themselves particularly well to competency-based approaches.
Legal departments. Litigation can be a costly and painful experience. In particular, discrimination lawsuits sometimes involve competency models that may unintentionally imply discriminatory practices. By now, we all know that gender-neutral language is appropriate and expected; however, there is sometimes a difference between what is considered politically correct and what could be construed as discriminatory. Particularly vulnerable are those models which have not been thoroughly validated, thus potentially not reflecting what is really required to perform a specific job.
Sudden changes in regulatory and operating environment may also be relevant. Previously innocuous terms and phrases may suddenly become lighting rod targets. On the other hand, don’t become paralyzed with fear such that your competency definitions read like contract terms. They need to be easy to understand – even engaging!
For example, in a post-Enron environment, the phrase “cross-selling services” very suddenly became dirty words in audit/consulting practices – implying that auditor/consultant relationships and arrangements were too cozy. Previously, “cross-selling services” had, in some carefully managed contexts, been developed and incented as a competency. In the heat of the BP gulf oil disaster, “maximizing profit” became a lightning rod phrase for the oil industry particularly when in the context of balancing safety concerns and considerations. Performance standards which specify targets versus concepts may be more appropriate and may mitigate exposure in some of these circumstances.
An additional point of legal consultation specific to appraisal ratings is noteworthy. Some companies have found themselves in trouble for using (or having been perceived as using) forced ranking concepts because they can tend to inspire “excitement” and can be difficult to defend with complete objectivity and convincing science. “Expected rating distribution” may be a better and less emotional way to think, act, and talk about what likely achieves a similar objective – attempting to mitigate rating/grade inflation. While most employees may favor greater differentiation in appraisal ratings, most of them also believe they are in the top quartile - the arithmetic doesn’t always quite work.
Not anticipating, appreciating, and resourcing all of the IT issues and dynamics that may impact our objectives. In most organizations, technology now supports and touches many if not all important business processes. Because, as discussed, competency work by definition also reaches many corners of the organization; special and more in depth exploration is warranted when competencies meet technology. More interested parties and stakeholders are likely to appear on the scene than may be the case with other projects.
I further explain in advance the length of this particular section by sharing a favorite quote because it illustrates a tendency to under-appreciate, underestimate, and otherwise dismiss IT implications: “Don’t worry so much about the technology – it’s all about the conversation. So-n-So used to manage his company’s competencies on the back of a cocktail napkin and he did ok.” I can and want to always appreciate the spirit of the quote. There is after all an appealing “if only…” simplicity to it. Plus I’m all for meaningful and robust competency conversations – when they really happen.
However, the reality in today’s world is that in order to actually and successfully implement almost anything of significance and scale, technology will need to be our friend. Well conceived and executed IT projects can produce incredible results – truly revolutionizing what we are able to accomplish and how we do it. They can also be deadly when they go awry. To be balanced, they are also capable of delivering mediocre results. While not necessarily unique to IT projects involving competencies, following are some ”fascinating” things that can and do occur:
Tails wagging dogs – IT professionals sometimes attempt to define and determine that which they are not skilled to define and determine. Similarly, competency experts sometimes overshoot the boundaries of our technology expertise. At the risk of stating the obvious: competency “gurus” in particular should know better since one of our core competencies is presumably matching the right competencies to the right efforts. Of course teamwork and mutual respect for the capabilities each party brings to the table are the right answers. It is very important to consult and collaborate with IT from the very beginning – they need to be at that table.
Hot potatoes – It’s actually great fun to talk about what might be. But when it’s time to make “scary” decisions and actually do something, the tide can turn from great fun to lob-but-not-catch the hot potato. Suddenly, decision-making authority becomes fuzzy, previously disinterested parties and sacred cows come out of the woodwork, and barriers can’t seem to pop up fast enough. Stamina, inclusive planning, effective leadership, political savvy, and strong unambiguous sponsorship are critical.
Musical chairs – Sometimes competencies have a tough time finding the right home. I’ve seen them “sit” in (versus interface with) and bounce among each of performance management, learning management, knowledge management, and other systems (not payroll thus far, though I suppose a case could be made....) – and sometimes all of the above simultaneously in siloed, unintegrated fashion without any clear sense of definitive ownership. Competency management systems appear to continue to come more and more into their own and are definitely worth exploring. To the points made previously regarding competency overload, there is a compelling case to be made for a single “master copy” repository for all competencies that interfaces with other relevant systems and processes as strategic. Beware the silver platter solution that may not meet all of your needs and particularly with respect to integration.
Flying high; flying by – Also beware interested parties who fly by at high altitudes suggesting “this” and demanding “that.” The devil really is in the detail when it comes to technology projects. While it is easy to get bogged down and mired in detail, there is a big difference between unproductive detail and make-or-break detail. Differentiating between the two is key. There is a time to be strategic avoiding the weeds and there is a time to roll up sleeves and get a little dirty. Some people just “don’t do windows” and of course some people shouldn’t be “doing windows” based upon the scope of their roles as defined. Be politically astute and consider respective stakeholder positions, but don’t necessarily count on heavy lifting from everyone with an opinion. Do appreciate input as well as the value some may be capable of adding by way of marshaling resources or influencing decision-making.
Connecting-the-dots - The more we endeavor to integrate competencies throughout organizational processes, the more complex technology issues may become – and thus, the more constraints or even limitations we may ultimately face. It’s about consultation and tradeoffs, and yes - good old-fashioned collaboration every step of the way.
Some organizations are blessed with very capable IT departments with well defined project protocols and a culture of healthy, efficient business partner relationships – others are not. Getting the technology really, really right is a critical and unique effort – one that requires very specific skills that are likely different from those possessed by individuals leading the competency development charge from a content perspective. In addition to adequate and appropriate project resourcing; crystal clear lines of responsibility/ownership, understanding of decision-making authority, and issue escalation protocols are essential. Don’t “agree” to a project otherwise - really.
This work can also be particularly challenging because requirements definition processes can readily take on lives of their own. Input flying in from a wide variety of sources (many with differing agendas) needs to be carefully rationalized in the context of a North Star. What is your endgame? What do you really seek to accomplish? What have you been chartered/approved to accomplish? Beware scope creep. Be realistic about what you hope and commit to achieve. An 8-headed-hydra-monster system that can’t be properly implemented, supported, or maintained will probably not be deemed success. Rendering the complex simple will be – despite what can be very strong gravitational pull to the contrary.
In sum, a well designed, developed, implemented, supported, and maintained system can provide a real opportunity – to integrate and to operationalize. A clunker can be a real albatross for a very long time. Still not sure I can in good faith fully endorse the cocktail napkin alternative.
|