jump to navigation

Shaking The Mouse July 13, 2009

Posted by Chuck Musciano in Leadership.
Tags: , ,
6 comments

Back in the mid-80s, optical mice made their first appearance.  Unlike their roller-ball brethren, optical mice used light reflected off a special mouse pad to detect mouse movement.  They were cutting-edge and fun to play with.

In my research group, our Sun workstations used these optical mice.  One day, a sales rep was in our lab demonstrating some software package, when the mouse stopped responding.  Nonplussed, she held the mouse upside down, shook it, and resumed the demo.  Our slack-jawed stares caught her attention, and she explained how the mouse “got clogged” every now and then, and shaking it “cleared the mouse” and helped it work again.

Now, it was true that the Sun optical mouse driver did hang every so often, but it was due to a small input buffer being overrun with too many mouse events.  If you waited a few seconds, the buffer would drain and the mouse would recover, no shaking necessary.  This woman, however, believed that mouse was clogged and that shaking was required to fix it.  It clearly worked: every time she shook the mouse, it started working again.

Determining the root cause of a problem and applying the right solution is a crucial skill, whether you are debugging hardware or solving personnel issues.  Our brains are so desperate to correlate cause and effect that we are easily convinced that some action, no matter how odd, really can solve a problem.  Even worse, as soon as we find what seems to be the solution, we stop looking for the real problem.

In the case of the mouse, some simple analysis of what could actually clog a device with no moving parts might lead you to conclude that something other than shaking was at the heart of the solution.  For larger problems in more complicated systems, it can take weeks and months of digging to find the true root cause.  But if we do not find the real problem, we are doomed to experience it again, compounded with the frustration that our “solution” is somehow not working.  A technical problem is not fully solved until you can connect the dots from the very first event in the failure to the very last element of the repair.

People problems are far harder to debug.  Unlike computers, people are non-deterministic and prone to sudden erratic behavior.  For many issues, we may never know why someone really made a particular mistake or acted in a certain way.  In many cases, the behavior is not repeatable, so our solution cannot be fully tested.  Nonetheless, we are duty-bound to explore as many avenues as possible to make sure we understand why people act in certain ways and how our own behavior can affect others.

Technical or personal, it can be tempting to grab onto the first potential solution and stick with it.  It’s certainly easier than digging and digging to prove that you solved the problem.  But how many times are we left implementing bad ideas or half-baked systems because we didn’t dig as hard as we should have?  Are you really getting to the heart of every issue in your world, or are you just shaking the mouse?

Where The Prices Are Insane! July 10, 2009

Posted by Chuck Musciano in Leadership, Technology.
Tags: , ,
8 comments

It happens four times a year, like clockwork.  Just before the end of March, June, September, and December, the phone calls and emails flood in, all promising the same thing: unheard-of pricing on products you absolutely cannot live without.  These once-in-a-lifetime prices are only available for a short time, if you act now!

What’s being sold at immense discounts?  ShamWow or Snuggis?  A Pocket Fisherman or a 12-CD set of the greatest hits from the 70s?

Nope.  The big sale is on software.  Big software: databases, ERPs, business intelligence platforms, and the like.  Even with the fabulous discounts, the prices still run well into six figures, plus implementation costs.

Who buys software like this?  Is there a CIO anywhere in the world who will write a check and buy software at the drop of a hat?

Done correctly, big system purchases take a long time.  Requirements analysis and market evaluation are tedious but vital to ensure a good fit for your organization.  Understanding the deployment costs and timeframe is crucial for success and can takes weeks to figure out.  Just reading and negotiating the support and licensing contracts is a major exercise all by itself.

Moreover, as CIOs work to gain the respect of their executive peers, the last thing any of us should be doing is running to the CFO’s office on June 30th, looking for a signature to close a deal before 5 PM.  Rushing a deal to save a buck is unprofessional, and any other C-level executive should question our abilities if we behave like that.

That isn’t to say that I don’t appreciate a good deal.  But the right way to approach a quarter-end discount is to start working towards it at the beginning of the quarter.  Everyone on both sides of the table knows that pricing gets tighter as the quarter and year ends.  By doing all the heavy lifting well before that time, we can focus on solid price negotiation without being pressured to short-circuit our diligence when things go down to the wire.

I really appreciate those vendors that come to me well in advance to put together a great deal with plenty of time to spare.  Not only does that let me do my job on my side, it also lets me manage the process with my management team, giving them plenty of time to learn about the proposal.  When I do go forward with the final pricing at the end of the quarter, there are no surprises to delay the process.  By helping my company reach a good decision in a timely fashion, a vendor makes themselves (and my team) look good.

Selling is about relationships and providing solid value over time.  Vendors, please leave the high-pressure tactics to late-night TV ads and used car lots, and give your customers time to evaluate and respond to good offers in a timely fashion.  We’ll all close on more deals with a lot less stress.

Let Go Of The Details July 8, 2009

Posted by Chuck Musciano in Leadership.
Tags: , , ,
5 comments

IT leaders tend to manage a detail-oriented bunch of people.  Technology only works because someone pays attention to the details, and those who ignore the details are not long for our business.  We actively seek those who can absorb and deal with vast detail on a regular basis.

As qualified individuals rise through the ranks of IT, they face a troublesome trend: more and more of their job involves letting go of the details.  This can be a terrifying proposition for many of us.  If letting go of the details has been a proven recipe for disaster in the past, how can letting go of the details be crucial to my success going forward?

Leadership involves owning responsibility for more stuff than any one person can handle.  To manage all that stuff, we build teams that can collectively address the problems at hand.  Within that team, we divide and conquer, assigning different details to different people to get the job done.  Once assigned, we need to let go of those details and trust our team to handle it.

This is agonizing, especially for new managers.  I can remember when I made the transition from being a Unix systems administrator to managing the team of Unix admins.  As I relinquished my direct responsibility for our storage systems to another admin, I could feel my fingers shaking as they were pried off the keyboard of the console.  I was like a mother advising her newly-minted teenage driver as they took the car keys for the first time, blurting out bits of advice in an effort to forestall what I was sure would be an unmitigated disaster.

It wasn’t a disaster, of course, and that team of admins did a great job managing the servers that were once mine.  But the desire to stay engaged at every level, to track every detail, was overwhelming and almost fatal.  It took a lot of effort and focus to let my team do their jobs.

Failing to let go creates disaster in several directions.  At the very least, it tells your team that you do not trust them, and that you must stay engaged in order for them to do a good job.  Your lack of faith in their abilities will become a self-fulfilling prophecy, creating a team that lives up to your expectation of inadequacy.

Your constant meddling will also drive your team crazy.  What you see as helpful interaction is really micromanaging, and nothing is more frustrating to a competent employee than a micromanager.  You’ll lose your team’s respect and with it, any ability to actually manage them when it really matters.

Finally, all the time you’ll spend doing their job will keep you from doing yours.  Your boss is not expecting you to continue in your old role; he or she expects you to take on new responsibilities and deal with issues at a more abstract level.  Given that time is finite, every moment you spend mired in detail is a moment you could have been dedicating to your new job duties.  This incremental neglect of your new role will ultimately destroy your career.  If you really want to deal with all that detail, your boss will be happy to return you to a position that provides that opportunity.

Let go of the details.  Let your team do their job, so you can get on with doing yours.

Eschew Entropy July 6, 2009

Posted by Chuck Musciano in Leadership.
Tags: ,
1 comment so far

Many of us in IT like to proclaim that we are Agents Of Change, bringing wonderful new technology to the world on a regular basis.  We spend a lot of time discussing Change Management, learning how to help people through the stress of change.  We look at change as a Good Thing, a necessary step in improving our lives, both personal and professional.

Really?  Let’s be honest: as Oliver Kamm points out, the “most common form of change is decline.”  Are we simply Agents Of Decline?

Like every other system and entity in the universe, software and hardware are subject to entropy, the inexorable collapse of everything over time.  Computers fail.  Disk drives seize. Power supplies overheat.  Cables crack. Ports fill with dust. Databases fill up. Logs grow inexorably. Software gets patched.  Left on its own, everything we own and touch on a regular basis simply gets worse.

Disciplined operations is the heart of IT.  Consistent operational discipline is our only defense against entropy.  Without it, our systems will grind to a halt.  Unfortunately, there are two problems with good operations:

  • It takes an ever-increasing amount of effort to do it well

and

  • No one cares until we stop

As we deploy new things, bringing change to the world, we increase the operational burden.  Every system deployed today must be maintained forever.  More and more of our time and resources are spent on simply keeping the lights on.  Even worse, all of these systems communicate with each other, so that the potential system conflicts grow super-exponentially.  Running IT is a lot like those plate-spinning acts you used to see on the Ed Sullivan show, except that your audience is throwing plates at you during the act.

For some strange reason, users expect us to keep all of the plates in the air all of the time.  And why shouldn’t they? Why would we deploy a new system if we didn’t intend to keep it up and running? No one deploys a new system along with a planned shutdown date. (“Here’s your new collaborative environment!  We’ll keep it up and running until December”)  No, we deploy things with the promise of maintaining and expanding them forever.

As our systems grow in number and complexity, the cost of maintaining them grows as well.  This cost can overwhelm our budgets and limit our ability to develop and deploy new systems that really are important to our business.  As our ability to develop new tools diminishes, our perceived value to our customers drops as well. That’s a dangerous vicious cycle with bad career implications.

We’ve portrayed ourselves as Agents Of Change, so our customers judge us on that.  We didn’t label ourselves the Enemies Of Entropy, so users really don’t care that we spend most of our time forestalling the inevitable.  Behind the scenes, we need to strike a balance between both roles so that our systems keep running, our users are happy, and new systems arrive on a regular basis to keep our businesses ahead of the curve.

Is it easy?  Of course not!  If it were, everyone would be in IT.  Is it challenging?  You bet!  That’s what makes it fun.  Can you hold off entropy and still deliver the right stuff for your customers?  Even more importantly, will you enjoy doing it?

The ABCs of Hiring July 1, 2009

Posted by Chuck Musciano in Leadership.
Tags: , , ,
9 comments

Few of us get to assemble our teams from scratch.  Most likely, we acquire a team as we move into a new position.  Much like a college football coach that inherits players recruited by his predecessor, we have to play the game with the team with have.

Over time, we get to reshape the team to our liking.  As folks move on to new opportunities, or as you “assist” folks in moving on to new opportunities, you’ll get the chance to bring new people to your team.  This is a big test for any leader.  People understand that you are not fully responsible for the team you inherit, but they won’t be as compassionate when someone you brought to the team drops the ball.

There’s a simple rule for hiring that should shape these decisions:

A people hire other A people.  B people hire C people.

When asked, every leader will insist that they hire only the best, brightest candidates.  But do they?

The best leaders surround themselves with people smarter than they are.  The best teams to lead are those where you are the dumbest person in the room.  If you are the smartest person in the room, your team has a serious problem. Find experts in the pertinent domains, create a culture that supports their efforts, and get out of the way.

Sadly, not every leader is the best leader.  Lesser leaders hire lesser people, intended to make themselves look good.  The result is a team of people that collectively rank just below the skills of the leader.  Given that any leader following this strategy is less than stellar, the entire team winds up being mediocre at best.

Few leaders will admit that they are intentionally hiring sub-standard candidates to make themselves look good.  Where, then, is this rule being applied? By everyone around you, that’s where.

People will closely scrutinize your every hiring decision.  Their assessment of each new candidate will reflect on you.  If you make good hiring decisions, people will notice.  If you make bad hiring decisions, people will notice and talk about it.  You may claim (and even believe) that you are hiring A players, but every C player you bring aboard knocks you further down the scale to becoming a B leader.

This ABC rule goes beyond technical ability.  It’s even more important when people consider the fit of your candidates into the current culture.  The ease with which your new team members integrate into the culture says a lot about how much you respect that culture.  If you diminish the importance of culture in your hiring decisions, you can lose the support of your existing team.  You may also make it much harder for your new people to succeed in their new role.

No one wants to be thought of as a B or C leader.  Seek out the A candidates while hiring, and you’ll go a long way to ensuring your own success as an A leader.