Over the last few months, we’ve been watching tremendously troubling images come out of BP’s Gulf oil spill. We often think that when things go wrong, they can usually be corrected, but sometimes something goes wrong and it’s just catastrophic.  At the time of writing, the oil spill had recently overtaken the amount of oil released into the environment, overpassing any prior oil spill.  It’s not that these oil spills are even infrequent.  We hear about the Exxon Valdeze, and of course this BP spill will be remembered for decades at least.  But smaller spills happen many times a year and other than local economies, most of the U.S. population doesn’t hear about it.  The fact is that oil spills are not rare events as the oil companies would like us to believe.

The sad thing, is this was probably predictable.  On an event by event basis, the probability of this type of outcome is very small indeed.  But as you look across time and volume, if there are 25 events that can be categrized as oil spills in the U.S. every year, every few years or decades, one of them is going to be huge.  Exxon and this BP one fall into those categories.

Perhaps when small things go wrong, we are correct in thinking that we can fix things.  Indeed, small mistakes are easy to either fix or cover up.  Impacts are limited and uually don’t spread to large populations.  But when something big happens, not only is it explosive, but it’s hard to contain.  In the example of the oil spill, sometimes events are predictable, and you can’t really stop the event from happening no matter what you do – at some point, there wil lbe another disaster of an oil spill in the future.  But you can evaluate what the cleanup process is going to be and what disaster recovery looks like.  In the case of the oil companies, it seems that hey have assumed that small events would happen periodically, but it was not worth the investment for the rare major events.  In the case of BP (at the time of writing) having committed $20B to fund cleanup and other payouts, research and development of better cleanup contingencies may have been worth it.  (IMO, $20B is not going to come close to what the final cost will be).  I suppose when you are not only killing off wildlife, but extincting species and altering the ecosystem for decades to come, that puts things in a hole new perspective.

I remember back in Hurricane Andrew when Florida was evacuated (no, not the whole state), and ADP was literally paying people when payolls had not been submitted.  Often the business was not even there anymore, but they got paid.  Same thing for 9/11.  Businesses were literally destroyed, never to come back and sadly many people were gone as well.  Payrolls were not submitted, but people got paid.

There are similar types of employee engagement issues.  Sometimes major events happen that adversely effect everyone else in the organziation – such as large layoffs or spinoffs in business.  These are quite predictable as the planning probably happened in advance, but we don’t often think about the effect on other parts of the organziation and other employees. 

HR is often a detailed, transactional business.  We don’t often think about changes and problems on a large scale – instead relying on our ability to deal with small scale problems, we have to expect and be ready for the large scale problems that happen.  I once worked with a large, global organiation that had a major project around the flu pandemic (that never happened).  They were prepared not only regarding how to get people vaccinated, but also had a map of every country and how to get in touch with people, how to replace people and over the orgnaizational requirements on a short term basis.  All this preparation was just for the contingency of half their population coming down with the flu.  Hopefully things don’t go wrong, but when major events happen in the workforce, it brings our businesses down with it.  A bit of preparation is warranted, and that does not usually mean scalability in how we treat smaller events, but a completely different approach.

There has been so much publicity around e-readers and the Apple iPad lately. In truth, I’m totally captivated by both of these technologies, but have not jumped in the market yet. The iPad seems wonderful since it is basically the next evolution of the net book, or mini-laptop. It has a great user interface, is generally lighter than a net book, but combines some of the functions from the iPhone device, letting you take emails, calendaring, video, applications, and yes – an e-reader with you. The problem with the Apple device is that the e-reader is in full color, not in what is called “e-ink.” E-ink is attractive because it allows you to read a page virtually anywhere. It’s visible in full sunlight. Unfortunately with the e-readers that use e-ink, the technology seems to “flicker” every time you turn a page. I’m not sure what the nuance is behind the technology, but a 1 second screen flicker on page turns is rather annoying. Considering that you would turn a page an average of 400 times a book, and every 30 seconds, this can be quite upsetting.

Sometimes, it’s the little things that bother us, because while they are little things, if they happen all the time, the accumulated disturbance is rather large in scale. As we go to SaaS software environments, but even in our legacy on-premise systems, almost all end users have become accustomed to waiting for screen refreshes. I actually remember back to the late 1990′s when one application hosting provider actually issued a SLA that the screen refresh would be no more than 3 seconds. Imagine the downtime accrued over the course of a year if a hands-on application user lost 3 seconds every time she changed a screen!

Even in today’s speedy technology environments, we are often subjected to screen refreshes that take a few seconds. Sometimes it’s our own internal corporate networks, sometimes it’s the internet, but sometimes it’s the servers as wel. In HR, we tend to pull large amounts of data – employees have multiple roes of data on multiple data elements. There’s a lot of data chugging gowing on in that back end.

Imagine if Amazon.com or Google acted the same way. We would probably never use those systems, and they would have died a fast death in their infancy rather than becoming the behemoths they are now. Amazon literally pulls together a page on the spot – that page does not exist before you request it, rather it’s just a set of disparate components that come together at the point of the user request. Same thing goes for google, it takes your search request and pushes it through an algorythm, then searches the entire internet to return results. On systematicHR (admittedly a slow running site, I don’t pay for a fast host), when you request a page the server responds to 88 queries and returns results in 0.57 seconds on average. And that’s slow in internet speed.

Since converting most or all of our HR applications to we based apps or services, why is it that we still accept much of our technology running on legacy speed instead of internet speed? If we were end users with a choice, we would have made other choices and abandoned anything that delayed us from doing our work. Most of us hate waiting, and certainly the best performers hate it. When it comes to employee and manager self service, employees might be more willing to wait, but they are probably also waiting for dinner to finish baking in the oven while they wait for the screen to confirm their phone number change. As an employee though, I myself have been known to abandon at the first 404 error screen. Managers on the other hand, certainly have better things to be doing than waiting for slow screens, and the accumulation of individually insignificant annoyances leads to large amounts of displeasure with HR.

Similar to the iPad or e-readers that provide great functionality and targetted types of usability, little things that go wrong (not being able to read the iPad in sunlight, or having e-ing screen flicker) can be pretty annoying. As users, we can usually manage small annoyances, but we’re not good with problems that happen all the time and don’t get fixed. Our image of HR is often through the user experience of our applications that we roll out. As we increase our footprint of HR technologies in SaaS, speeds should gradually increase, and we should also be looking at SLA’s to ensure that our end users are getting optimal experiences.

We’ve been doing a pretty good job with Talent Management in my opinion.  We have pretty much deployed our systems or are in the midst of doing so.  We have reengineered our core talent processes from talent acquisition to performance to succession to learning and compensation.  We have started to grow our talent thinking past these core processes to workforce planning and internal mobility, partly spurred by the news that our demographics are changing so significantly with soon-to-be retirees and a generation of workers coming at us that needs transitions at a much more rapid pace than ever before.

What we have not necessarily figured out is not about acquiring, developing and upgrading employees.  It’s about preparing the workforce and taking a very broad view of the workforce as an organism rather than as a large set of employees.  As we went though the last series of layoffs and reorganization in 2009, we realized that our layoffs created gaps that still remain unfilled as we continue into better economic times in 2010.

We know (ok – we probably don’t, but it’s a goal maybe) exactly how much of every competency we need to have in the organization.  In order to be able to make a particular organizational sales goal, we can probably measure the total amount of sales competency and the aggregate achievement level in each of those sales competencies – using this, we should be able to predict annual sales achievement in a variety of economic conditions.  It’s basically a type of multiplier – more sales competency * average economic times yields better sales results than a lower level of competency within the organization.

So we have done a pretty good job acquiring and developing talent – at least we’re focused on it if we are not doing it in a formulaically structured way as I have illustrated.  We’re also focused on workforce planning.  We know that we have a retirement cliff coming.  5 years ago we said it was going to be in 5 to 15 years.  Well, we’re there now, and if we didn’t already prepare – we are in the middle of it.  We were training our people so they could fill the leadership and senior contributor positions that were going to be vacated.  Along side the cliff of retirees, we didn’t necessarily see the layoffs of 2009 coming.  We ended up with an environment where we were letting go of some pretty good people, offering early retirements, and cutting competencies from the organization as a whole.  We did all of this without really measuring what the aggregate competency gap was going to be.

I’m a total believer that we should be doing individual talent management.  We should absolutely be positioning individuals to achieve success through their career and succession plans.  We should have performance processes that actually motivate people to achieve goals.  Along side this, if we are not tying these individual programs to a broader organizational talent objective, we have missed the boat.  Talent happens at 2 levels.  We need to keep people as individuals, but our workforce plans need to be actionable at the individual level – not theoretical plans that help us prepare our organizations and fill senior seats, but aggregate competency levels.

Thoughts?

A long (very long) time ago, I used to captain a cycling team.  I had a crew of about 6 people that raced every week, and we all had our objectives and our roles.  As part of our weekly training for races, we would drill the sprinter on sprinting exercises, have the guys who would chase down breakaways doing crazy intervals, the climbers climbing, etc.  At races every week, our goal was to win primes (sprints that occur in the middle of races) or place in the final sprint.  We almost always had a specific formula.   I would send one of my guys out to the front of the 50+ rider group and ride as fast as possible from about 1.2 miles out from the finish.  I would collect the group behind me (usually 1 very fast guy plus a sprinter) and I would read the pack for the inevitable final break.  It’s not really a breakaway more than just a last acceleration.  If you chose the wrong acceleration, and go too early or late, you end up 15 spots behind choosing the right acceleration.  So I got to pick the “jump” and my 2 guys would just follow me as I followed a couple guys from other teams.  My job was never to win, it was to watch as the race developed around me and make sure my guys got launched at the right place and time, and have every possible chance to succeed.  Even while managing my guys individually throughout the week, and managing each individual race, the result of the individual race was never the point.  The real point was that if we wanted to say sponsored, we needed to place enough times in the year to attract enough money to keep us racing the next year.  (thank God I was never the sponsorship guy)

I sometimes wonder when we are designing talent processes, if we are paying enough attention to corporate strategy.  Each individual activity from process mapping to talent service delivery to technology selection should be hinged upon the overall corporate strategy.  I’ll give a simple example:  Let’s say that you are in a high growth mode.  You’re expanding into new markets or products, and the C-level execs expect you to have enough talent to get this done quickly before other competitors beat you to the punch.  Compensation has outlined a pay philosophy to lead market rates which allows you to acquire and hopefully retain highly talented individuals more easily.  HR has also developed a philosophy to pay for contribution rather than performance.

As a result of all this, the Talent organization should have developed a performance process that rewarded people not on the attainment of job descriptions or even role based goals.  Instead, performance should have been measured against competency growth and other attributes that contribute to organizational growth, not organizational maintenance.  Merit and incentive payments should have been disclosed with considerable transparency to disclose how individual actions create corporate value and result in growth in the targeted sectors.  Internal mobility programs should not just be filling jobs and moving people around, but specifically looking at how to move high quality talent to areas of the business that can use them most aggressively.

I know we do a lot of things that are process or employee specific.  I also know that each of these actions has a clear positive impact at the employee and organizational level.  But I question if we are sufficiently linked to our corporate strategies and if we know exactly how those linkages play out from an action to benefit perspective.  let me know if you have any answers.

Really.

You guys know that I don’t usually pitch anything.  But I have pitched this show a few times.  It really is probably the largest gathering of HR people outside of the SHRM conference.  But you never hear people come back from the SHRM conference talking excitedly about… well, anything really.  Some people like the keynotes, but other than that, it’s just a big gathering.

The HR Technology Conference on the other hand always seems to have the blogger and twitter pages abuzz.  Analysts flock to see what is happening and what vendors are saying.  People talk about the Talent Management Panel for months, and I still remember who won every single one of the Vendor Shootouts.

But (you say) it’s just a big vendor meeting and a huge, organized sales meeting!!!  There certainly is a time and place for buyers and sellers to meet here, and that is valuable.  There are the 40 educational sessions, many lead by senior practitioners, and none of which is sold to a vendor like at so many other conferences.Even more valuable is for you to find out what direction the market is headed in.  What exactly are the vendors working on?  What is the next cool break in functionality?  What are your own incumbent vendors competing against and are they lagging, maintaining, or leading?  At the same time all of the consultants and bloggers are there, trying to figure out exactly those questions above.  Your peers are there in masses (which with the budget cuts these days is tough to find sometimes).

Head over to www.HRTechnologyConference.com and get registered.  Use the Promotion Code SYSTEMATIC10 (case sensitive) and as a reader, you will get a $500 discount off the on-site rate of $1,650.

In cycling, there is the concept of a pace line.  Just as in auto racing (if you’re a NASCAR person) if you inches are behind another cyclist, you’ll save in the neighborhood of 25 to 30% of your energy as the cyclist in front of you fights the wind for you.  That person in front has a lot of pressure.  S/he is the leader both physically and in other ways as well, and everyone behind expects her to exhibit certain skills and qualities.  It’s for good reason too.  One bad move by the person in front, and the people in back who can’t see the road ahead all go down on top of each other.  This is not a complete list, but here are some of the qualities we’re looking for in a cycling leader:

• First, they have to keep a strong pace.  If they don’t, they will get passed too early, or the line of cyclists behind them get disrupted.  When everyone’s front tire is literally 2 inches away from each other, slowing down can be catastrophic.
• Second, They have to know when to let someone else lead.  You can’t lead forever – burning 30% more effort means that there is always someone fresher than you are.
• Third, you have to be stable.  Just as mentioned above, stability is a major part of the safety equation just as consistent speed is.
• Fourth, you have to call road hazards.  This can either be done with a flick of the hand that most non-cyclists would never see, or sometimes I verbally call out hazards as well.  If you’re behind 3 guys, you literally can’t see the road in front of you.
• Lastly (probably not last really), you have to be aware of the wind and which direction it’s coming from.  A cycling pace line is not always a straight line – it is often a diagonal line echelon as riders attempt to hide from the wind more effectively.

Management programs always have things like accounting and finance, structured strategy courses, technology, etc.  MBA programs have almost been able to commoditize these courses and structure how to formulate thinking and process in their students minds.  However, management programs have found it harder to teach leadership and actually build future leaders.  As organizations hire MBA’s, they know they will come with the requisite base of skills and knowledge.  But often, the leadership capabilities are completely unknown until mid career.

Back to cycling, I can teach a guy to ride strong, and ride a straight line, and to call out road hazards. But it actually takes experience to know when to let someone else lead, and it takes awareness to know how to position yourself properly so the guys behind you that you can’t see can ride a proper echelon.  For some reason, there are leadership skills in cycling that confound many cyclists – yet they are easy and obvious to others.

We in HR realize the leadership problem.  Most of us have a good set of leadership competencies that we attribute to our leaders and HiPo’s.  The problem is actually measuring leaders.  Sales or production growth is often misinterpreted as leadership.  Similarly, financial management and sound budgeting or project management is misinterpreted as leadership.  I wonder how many of us are correlating employee engagement scores from manager teams to these other measures?  Are we looking at employee achievement and promotion ratios?  Often, it’s not the obvious and quantifiable measures that tell us if a leader if a good one, but it’s the judgment of the employees – those following behind – that give us the best picture.

It’s been a while since I was on a bike.  All for good reasons, I haven’t actually been home in about 3 weeks.  I mean, you do need to have a bike available to you and decent roads to go for a ride.  I’m not sure that 3 weeks in NYC qualify.  First, I’m afraid of the incredible dust in the city – while I’m not afraid of traffic, I am extraordinarily afraid of dust and allergies that stay with me for days.  Back to the point though.  This morning, I went on my first bike ride since May 15 when I rode a meager 52 miles.  (yes, I have a diary of all this stuff, and yes, it’s fully GPS’d)  Just 3 months ago, I was riding about 80-90 miles without really suffering too much.  But this morning, I rode an easy 48 miles, and I swear my legs were about to fall off.  In what amounts to about 3 weeks, I have gone from barely competent to completely incompetent.  What is worse, in about 3 months, I have gone from decent to my current state.  There is good news though.  With hard work and training, I can get it all back.

The problem with HR competencies is not that most of us don’t have them, it’s that we’ve consciously decided to let some of it go.  Back in the day (all of 7 years ago), during the first major wave of HR outsourcing, organizations decided to outsource functions and thought that they didn’t need to retain the competency and roles.  After all, we were giving up these activities and people to someone who was going to take care of us.  These HRO organizations were going to be more efficient, save us money AND provide better service all at the same time.

Somewhere down the road, we realized that maybe it wasn’t all true.  As HRO organizations’ matured for the second wave of HR outsourcing, they realized that mentioning a retained organization might be a good idea.  The problem is that we didn’t really understand what the retained organization was all about yet, and there really weren’t leading practices around it.  So we kept a few people around in strategic capacities, and didn’t assume that the vendor was going to be the “be all, end all” for each of the outsourced functions.

Problem is that it took us a pretty long time to figure out what we were missing.  For example, it was often when we had a major PeopleSoft or SAP upgrade that we realized nobody was looking after HRIT in quite the same way we did ourselves.  We realized that as much as a vendor’s vanilla processes for performance management were nice starting points, real process design by people who knew the organization just wasn’t available.  We realized that we had gotten rid of a few too many people and the HRO didn’t pick up the slack they way we thought they might.

Not only did it take us a while to figure out what was missing, but after 3 or 5 or 7 years, we often didn’t really know how to fill the void that we felt within our organizations.  Writing job descriptions was hit and miss.  After all, these roles may have existed prior to outsourcing, but more often than not, they existed within multiple people, and figuring out what pieces of which people was getting pretty challenging.

We’re still struggling with this problem, but I think we’re struggling in the wrong way.  We’re writing job descriptions in the traditional way.  We are writing roles, tasks, responsibilities, etc.  But these roles are really more about competencies than tasks and responsibilities.  These roles used to be filled by a few people, and so many times they are cross functional, don’t require huge depth in subject matter expertise, and break down communication barriers between vendor/client, HR/technology, or functional areas.  Retained counterparts to outsourced organizations become communicators and translators, but it will take time to create these new roles and for us to understand and mold how they fit with our organizations and our vendors.  Luckily, we are finally at the point where we probably do get what we need, and how to fill that void, but it might take some time before we get it just right.

For me, I just need to get back on the bike…

I’m sitting (almost) next to a guy who works for Yelp.  He just did a pretty interesting tutorial to the person in the middle seat¹ about some interesting features in Yelp.  I at least didn’t know about some of these, but the most interesting of which is a little click box above the Google map that displays the location of the search results.  What it does is allow you to define your own search area.  You click on the box and you can then drag an area within the Google map.  Yelp then returns only results within that box.

I have no idea how they have constructed their search engine (or results engine) to be able to narrow down searches by just a drag box in the Google map, but it’s incredibly cool.  In contrast, we in HR think it’s the sexiest thing that we can click on a slice of the pie chart and drill down into more detail for that slice.  All I have to say is that our current BI tools are nowhere close to Yelp’s results capabilities.

Think about it this way, let’s say I had a competency map (or some form of a tag cloud, reinvented for HR purposes), and could do simple selections and queries off of that.  How could we engineer searches and results for managers and people trying to manage internal mobility.

Right now, if we want new data, we have to ask for it, and someone creates a query.  Even then, the data is static and while we can drill through, we only get to drill through on established parameters.  We don’t get to create, redefine and reconstruct on the fly.

How is it possible that I can define my search results with a simple drag box when I’m looking for a place to eat, but even after spending a few $MM to implement BI, I can’t?

Now go and check it out on Yelp…

1. great seat buddies for once – how often does that happen? [back]

Just a few short years ago, it really seemed like the vendor space was leading the market with all sorts of great new functionality and new ways to think about the world.  After all, what would we have done if SoftScape had not coined the term “Talent Management”?  (I’m pretty sure it was them, but I’m not 100% sure, so if I’m wrong, don’t crucify me please)  Talent Management gave HR a completely new lease on life, helped us get the attention of executives, and got many of us the proverbial “seat at the table”.”  TM provided us a way manage our Human Resources, whereas before we were just another resource.

The SaaS vendor space provided us with dashboards while the rest of the organization was implementing them, but HR didn’t have the budgets or the technical capability.  We got analytics for cheap from vendors when our organizations didn’t seem to see the value of a $MM implementation for HR.

But lately, it feels like we’ve taken hold of all the new technologies and the opportunities it brought us and we are not trying to push our vendors faster and further rather than being tugged along.  While vendors consolidate and focus on platform integration, we’ve all moved on to thinking about long term talent management that goes beyond the processes of today and looks at the planning for 2 and 3 years from now.  We’re wanting to understand workforce planning and implement technologies to help us with it.  We want to understand internal mobility and get a handle on how increasing mobility engages, develops and retains our employee base.

But it’s not really all the vendor’s fault.  Sure, the vendors (some of them anyway) tell us they have some functionality, or that it’s on the way, but we in HR are certainly now pushing rather than pulling.  The problem for the vendors is that most of the new work is pure analytics and decision support.  To do workforce planning, we need to be able to project out where our businesses are growing and what skill-sets we will need a few years down the road.  Often, HR does not yet have this level of visibility in the organization.  Sometimes, the business as a while does not have the ability to know what the future brings in highly project and contract based businesses.  Others of us have more stable sales and business cycles that can be predictable.

I think we’ve gone forward with our thinking, but both the HR and Vendor capabilities are lagging, and we have come to count on the vendor space to provide us a solution for our problems.  Unlike with Talent Management where many of us didn’t even know we needed it, now we know we have an itch to scratch – and we are eagerly awaiting a stick to scratch it with.  I’m sure it will be great…  (just hurry up already)

So you’re going to implement new job codes, or department codes, or whatever.  Someone in the organization has a great idea:  “let’s make the codes smart!”  I mean, what better idea to manage the information within the code than to implant attributes within the code itself.  So you go down the road:  Job category will be digit 1, job family will be digit 2, EEO code will be digit 3, grade will be digit 4.  If you’re on PeopleSoft, I think you only have 6 digits to work with, so 4 is probably a sensible place to stop.

Wait… Perhaps digit 1 was actually the sensible place to stop.

You see, a long time ago, when we were running off of mainframe computers, and we didn’t have a robust job table to work with, it was important to capture all the attributes of the job in the code.  I mean, if you didn’t capture all that information in the code, how were you ever going to get a report on all people performing a finance function?  The only place to store a job attribute would have been the job code.  Think Dewey Decimal System.  Brilliant at the time, but would we really catalog a library that way if we could reconstruct every library in the world simultaneously?  Lucky for us, we don’t have mainframe computers anymore.

You see, today we have what are called relational databases.  They have actually been around for a very long time.  Relational databases allow us to store attributes in tables which have many fields on them.  This lets us actually use these additional fields to select and report on, rather than trying to force a report to sort on Digit 3.

Does it even make sense to include attributes in the code from a definition perspective?  Do all those attributes end up helping us manage the information?  I’m going to argue almost not at all.  There is some benefit to being able to visually recognize that a code is an HR job, but I’m not sure there is much use outside of that.  We need to utilize the table structure for what it was meant to do.