The “High Performer” high-wire act

Great post by Mike @Figliuolo that points out the pitfalls of hiring in high performers.

More often than not, however, we hire for all the wrong reasons and never think beyond our immediate needs for hiring that superstar. When we do so, all we’ve done is arm the timer on an employment bomb that will go off in our faces.

I’ll extend Mike’s remarks by sketching  out how that bomb works.  As he notes, we can tempt ourselves into a hire for “immediate” needs.  What this can lead to is a transactional relationship with the high performer that spirals downward quickly.

Short-term thinking leads to a star being brought in as — and treated like — a consultant.  The focus is on the fire to put out, the project to deliver, the team to reorganize. Promised rotations and exposure are repeatedly delayed for expedience.

She’s disappointed, but then adjusts her expectations.  Unfortunately, she now views the role as another notch in her resume and a stepping stone (or detour) to someplace else.  Even worse, her performance suffers as she scouts around for the next gig.

Sometimes the situation is flipped — the high performer could be mercenary from the start — but the resentments and recriminations are preordained if the cycle isn’t broken.

Which brings us full circle to the prescriptions of Mike’s post.

Why I left SAP…”macro” negatives

Second-guessing oneself is a risk when deciding to leave a leading company, so I needed to ensure that I had no regrets when I left SAP.   In particular,  I didn’t want short-term personal or “micro” stumbling blocks to obscure great “macro” opportunities in the rest of SAP.  Unfortunately, there were too many big picture concerns that nagged at me, at least from my less-than-exalted perch:

  • The “Post-Shai” Backlash:  The reaction to Shai’s departure was almost giddy in many quarters, which wasn’t a surprise.  The real surprise was the scale, scope, and snarkiness of the reaction.   A lot of non-Palo Alto folks minimized Shai’s contributions when it was convenient — see Peter Zencke on Shai’s “second tier” involvement with BYD — and blamed him when it wasn’t convenient (e.g, BYD didn’t perform because of NetWeaver). 
  • Condition of SAP’s Product Portfolio:  For those familiar with the BCG Matrix, IMO the SAP portfolio is unbalanced.  Nearly all of the SAP portfolio can be classed as either cash cows or pets.   I just don’t see enough “stars” on the solution horizon. 
  • Confronting the Reality of Business ByDesign:  Speaking of pets, there was way too much happy talk about BYD for far too long.  The funding that was poured into BYD — while SAP increased its margins — came out of the hides of other parts of the company.  

This last point highlights the fundamental doubt I had about the validity of SAP’s strategy: Was it still able to produce “stars” organically?  A “not-invented-here” mindset only works when you’re still able to invent.  It is one thing to miss on product development, it is another to deny the miss. 

 Leo is certainly aware of this issue, but this unwillingness confront reality has continued to spread IMO.   I’m not sure that SAP understands just how much damage it has done to itself by running some sides of the company with a gimlet eye, while other sides seems to be living in the best of all possible worlds.

CIO job rotation and commitment to IT value

Great interview by Linda Tucci at searchCIO.com (here) with Richard R. “Rick” Roy, CIO at CUNA Mutual Group about his experiences as a line manager and how they’ve transformed his IT leadership approach.  This passage on a shared sense of urgency struck me:

I think the other thing in operations is the sense of urgency. In your customer service centers, the phone rings and you either answer it within your service standards or not; you either resolve the question within your service standards or not, or pass it on to another level of service.

IT operations has that flavor to it, but when you get over into the application development world, it typically doesn’t. They typically are working on projects that can span months, if not quarters, even years. Trying to drive that sense of urgency is probably the other big reminder for me as I have come back into the CIO seat.

Roy also hints at something PMOs need to do better: maintaining the same pace as the business.  A PMO needs processes that are nimble enough to keep up as the business responds to the market, competition, etc. by “adjusting and going perhaps in a different direction.”

Explaining “Speed vs. Thoroughness” trade-offs

I was asked recently about how to balance quick delivery vs. complete (or enough) scope.  Unfortunately, my initial answer sounded lame even as I was explaining it… I later remembered a better example of how to aim for “quick-but-real” wins while planning and executing broader and deeper solutions to the issues at hand.

Such trade-offs are, of course, the life-blood of managing initiatives.  And, of course, one may will have to spend a bit more in resources to get speed and thoroughness (that pesky triple constraint… here and here).  But there’s also the risk management angle to consider.

In particular, the ability to deliver on both “fast” and “thorough” tracks is essential in organizational or business change projects.  Properly targeted and communicate “quick-but-real” deliverables are excellent responses to the risk of poor or no acceptance by stakeholders.  This approach is a way of buying cheap insurance (I know, I know…insurance is a different response type technically) against much bigger risk impacts down the road.

Well, approach “x” worked for me when I worked at company “y”

Well, these magic beans worked for me at AIG...

Well, these "magic beans" worked for me at AIG...

Pawel Brodzinski had a wise corollary for my original post on naysayers (here).  He puts it well…

The distance between rejecting things you don’t believe in and forcing others to do things you believe in is pretty short.

It is great to bring a successful practice to a new situation, but one had better be ready to answer some basic questions:

  1. Why will “approach x” work for this problem or opportunity?
  2. What about our situation may make “approach x” difficult or not applicable?
  3. How will we resolve, mitigate, etc. the issues and risks implied the “What” question above?

I’ve never seen “solution y” successfully implemented…

Go to the mirror...

Go to the mirror...

There are some assertions — or maybe I should say incantations — about process or solution failures that never cease to puzzle me. One of my favorites is:

In my “x” years of experience, I’ve never seen “solution y” successfully implemented…

I’ve heard this about TQM, activity-based costing, Six Sigma, SAP, Oracle, Java, etc., and ad nauseum. No matter how successful or tested the approach, the person who invokes this formula believes that his/her “say-so” settles the matter.

Now I wonder: do those who use such rhetoric ever consider what they’re really communicating? Because I know what I’m thinking: “Hmm…solution ‘y’ doesn’t seem to work when person ‘z’ is around.”

Web 2.0 and PMO functions

We’ve just started digging into a large-scale re-architecture of our various methodologies.  As you might imagine, the consequences of our approach include changes to the processes, people, and technologies behind content production and maintenance.  

In particular, leverage social media to author, publish, and distribute much more content than we do today.  We’re pleased with our technology direction.  However, we are concerned about some of the organizational change management challenges ahead — for example, many potential contributors feel like their competitive advantage is what’s in their heads. 

Are there any social media adoption strategies that work well when engaging constituencies that aren’t inclined to share?

Follow

Get every new post delivered to your Inbox.

Join 2,659 other followers

%d bloggers like this: