Hunch On IT

Careful what you ask for…

Posted in Behavior, Business, Human Behavior, Information Technology, IT, Organizational Behavior by carlkessler on January 20, 2010

Setting goals for a large corporate IT department is an activity where the pitfalls have pitfalls. The two scenarios that I repeatedly experienced were:

  • Confusing the “what” with the “how”
  • The “No child left behind” Syndrome

The “What” and the “How”

There’s a big difference between strategy and goals.  A strategy describes how one will achieve one or more goals.  Strategy is how and the goals are what.  Allow me to use a low level technical example here.  Part of our “strategy” might be to “Implement an Oracle database”.  This is a “how” statement, so we need to backtrack to why we decided to implement Oracle.  There is likely a goal that describes “what” our application needs to do that will require a relational database and there may be an enterprise goal that we want to leverage our investment in Oracle.  Now the “but”, but our enterprise goal for leveraging Oracle may be for “mission critical” systems.  That strategic goal may have become divorced from its context and now all systems are leveraging Oracle with a potential multi-million dollar licensing implication.  Now we’re squarely in the nightmare that is “goal setting” for the CIO/CTO.

The good news is that the solution to ensuring that goals are properly interpreted is not a mystery.  This can be accomplished with a combination of three things (you pick based on your needs):

  1. Establish linkage from high-level goals to lower-level goals to actions.
  2. Provide context in the form of rationale and implications
  3. Establish an IT governance mechanism

In order to establish linkages, get on a white board and begin building a hierarchy from your top level goals on down.  This will help your teams to understand your intent as they create the appropriate action plans in their areas.  Be careful not to force your goals and activities into a single-threaded model.  What I mean is this, a lower-level goal or action may easily support multiple high-level goals.  Certain graphical tools like PowerPoint may not permit you to create linkages up to multiple goals from a single lower-level goal.  For example, adopting a standard database product may help you reduce support costs, increase service up-time and streamline FTE skill sets.  Make sure you draw those linkages.

Context is similar, but more explicit.  Linkages imply a relationship.  Context makes it clear.  For each goal, state a rationale (a “why”) and then state an implication (what it means in a relevant context).  This is very, very effective in communicating intent.

Finally, establish a governance process to review progress toward goals at a regular interval.  Lots of fodder here for the blog-o-sphere, but I will hold that off for now.

No child left behind

Egad!  Where could this possibly be going?  If you got the education reference, you get a cookie.  We always have folks that can take an order and get it done.  In fact, this is an admirable trait for project leads and soldiers.  It’s my opinion, though, as generations exit their formal education having been groomed on the notion that if they can regurgitate facts on tests they are successful, we are entering a perilous time.  Students are being taught “what” to think, not “how” to think (that darn what and how stuff again).  The corollary in the workplace is “give me my goals (aka ‘the test’), tell me what to do and I’m good to go”.

The reality is that any goal, no matter how well written, can have unintended implications.  Example time!  Let’s set a goal to reduce the average hourly rate for our development and support costs, that’s a common IT goal.  Some folks, when given such a goal, will hamstring the organization by eliminating their current knowledgeable “high-priced” talent and replace them with “low-cost” contractors.  The only slightly hidden cost here is the impact to service levels.    And, yes, this misinterpretation can be fixed by following the three suggestions above, but that’s not the point.

The point is, do you think that the average person today is likely to think critically about that goal and raise concerns OR are they likely to simply take the obvious actions to “make it so” (as Picard would say)?  My experience is that the latter scenario plays out much more than I care for.  Finding and promoting the “horizontal” and “long-term” thinkers should be a key strategy in trying to remedy this.  This may also be an offshoot of short-term thinking, like delivering quarterly profits versus stable, long-term returns.  I guess we’ll leave it to the sociologists to determine the why.

One can address this issue in several ways.  Certainly providing context for your goals will help.  Knowing your staff and their personality and behavior patterns (how they’ve implemented goals in the past) is critical.  There is also training available for how to effectively set and interpret goals.  The number one thing to do though is to screen for leadership traits during hiring that show an openness to question management, the ability to assimilate new ideas and the ability to accurately assess impacts across diverse teams.  Look into “behavioral interviewing” techniques to buoy your interviewing skills.

Setting solid goals is essential to steering the ship, but there’s more to it than 3-5 PowerPoint bullets.  What’s your experience?


People do what they know…

Posted in Human Behavior, Information Technology, IT by carlkessler on December 12, 2009

This is obvious right?  We do hire people for their experience and we expect them to leverage that knowledge to do a better job.  This works 90 percent of the time.  The issue is that when it counts the most, our experience can really backfire.

The two key scenarios are (a) when the world has fundamentally changed and (b) when we are overwhelmed.  In these situations, experience may not help at best and be counterproductive at worst.

When the world has changed, what we did in the past may not work.  Consider a real world example, remember the images of soldiers standing in rows in brightly colored uniforms firing volleys of musket fire at each other.  Muskets were fairly inaccurate.  Those rows of soldiers acted as kind of human machine gun increasing the probability of a hit (among other things).  When we invented rifles which were much more accurate over longer distances and added tactics like guerrilla warfare, the military units that failed to adapt suffered higher causalities.  The old way which had been very effective, was now a liability.  The same is true for IT.

The trick is really recognizing when the world has changed.  Sometimes a major change arrives as the result of a “disruptive” technology.  In IT we do a pretty good job of identifying and even driving this type of change.  The major changes that can really blindside us, where our experience may actually have a negative outcome, are changes that aren’t reported in the technology rags.  They are major changes in how our company does business or in the scale it does business on.  Examples might be:

  • Moving from a product to a customer focus
  • A rapid increase in size
  • Certain regulatory changes
  • The addition of substantially different product lines

In these type of situations, it’s important to step back, ask some tough questions and seek 3rd party help.  In my experience, my gut is usually the first to raise a red flag.  Be wary if there is substantial horizontal impact across the corporation or major changes in capacity requirements.

The second scenario is when we are overwhelmed.  This may be due to the volume of work or the complexity of effort.  I am personally a victim of this.  When I have a lot of work to do, I have two choices.  Do I take out the chunk I can do most easily because I know how or do I tackle the more complex tasks which require a lot more thought?  The temptation is to whittle down the stack by taking out the “easy” stuff.  The easy stuff may not be the most important, in fact, it’s more likely not what is important.  The individual can deal with this by being aware of the affect, setting priorities and sticking to them.  Management can help by being aware of when your team is overloaded and effectively setting priorities.

The axiom here is “Have the experience to know when you don’t.”

Tagged with: ,