bill mccreary image from nhl.com

some nights in hockey — especially if your team has a reputation — referees will blow the whistle a little more than usual. it just happens that other games are merely called tight with little room to interpret the rules. whatever the cause, you never want to have your players cutting ruts to the penalty box.

on the bench during those kinds of games, there’s a common saying that gets passed around among coaches and players: “don’t give them an excuse to put you in the box.” it’s a simple message. even if what would normally not be called an infraction earns you a 2 minute trip to the sin bin, as a player you have to be smarter than that and adapt. you can’t give the referees any excuse to call you for it. keep the sticks down, keep both hands on your stick, and watch the play along the boards.

business can be much the same with clients instead of referees. some might love everything you develop for them or the kinds of services you provide, but others may be insatiable still and find flaws with anything you bring to bear. if you know you’re dealing with the latter, follow the same simple rule: don’t give them an excuse.

don’t give your clients a reason to question the validity of your statements; be sure to practice each and every one of your presentations and always perform the proper amount of due diligence in defining answers to their questions.

don’t give your clients a reason to believe that your products are broken; test, retest, and test some more until you’re absolutely certain that your products or services are programmed properly, or mathematically sound, or have multiple research studies to support them.

don’t give your clients a reason to feel like they can go elsewhere and get the same service; go out of your way to prove your organization’s commitment to them by answering their phone calls promptly, replying to their emails the same day, and generally making them feel like you give a damn about them as customers.

if you’re dealing with a difficult client, don’t complain if they’re bitchy or a hard-ass or they’re calling bad penalties. just don’t give them an excuse to call one in the first place.

image by eqqman, flickr artist

it’s pretty easy when you’re working hard on a project to become engrossed in it.  all your energy becomes focused on one thing, and one thing only: delivering results.

be careful, though, because you might be delivering the wrong results.

when we get that kind of laser focus sometimes it’s hard to break free from it.  ”i have a deadline, i have to get this done, and i have to get it done right now.”  so, being the good workers we are, we start to work towards accomplishing that goal.  unfortunately, we sometimes go down the wrong path in getting to the finish line.  instead of looking at our available options, we pick the one we know will work even if it has consequences.  we’re not as efficient anymore.  our processes can be improved.  our tasks are disjointed.  our products don’t provide value.

these things happen, and they happen often.  it might start with priorities that all become worthless because every task now has ‘critical’ or ‘high’ importance.  it might start with a demanding client who asks you to turn a demo into a fully functional work product within a week.  but at the end of the day, it’s just something that happens.  that’s why i think — especially for those of us who work as consultants — that it’s so important we don’t forget to turn a consulting eye on ourselves.

what meetings are we having?  do they provide value?  has the mission of our project team changed?  do we still have the same goals in mind as we had 3 months before?  6 months before?  12 months before?  does our leadership structure still serve the client well?  does it serve the project team members well?

these questions and more are questions that need to be answered, but — perhaps more importantly — they need to drive tangible change.  it’s really simple to ask the question (i just did!); it’s a bit more difficult to implement changes based on the answers you get in return.

sometimes you just have to look in the mirror.

not bad, right?  wrong.

the new house has popcorn ceilings with … sparkles? in it.  and both the downstairs as well as the back room upstairs have floor to ceiling mirrors which one can only assume is to ‘make the room look larger’.  to me, it all makes the room look ‘horrible’.  but such was the style back in the day (…i suppose).

there’s a slight problem, however: namely the fact that it’s now the future and such designs are way outdated, look bad, and worse yet are hard to change.  painting the ceilings was not fun.  first, the popcorn soaks up all the paint so you end up using far more than you would have used on a normal, flat surface.  second, it falls apart on you.  i know this too well.  my brother and myself both had paint covered pieces of the ceiling fall off and into our mouths.  (yes, it would have made sense to have a mask on, but we didn’t exactly have an OSHA approved setup.)  the mirrors?  they’re still up there.  it would have cost too much money to have them removed, and then you have to worry about what’s behind those mirrors once you do take them down.  beyond the cost to remove them, you may incur even more costs in fixing whatever is behind the mirrors.  it’s not an agile design for the interior of a house.

much like designing a house, you may want to be careful when you are making design choices for your organization.  you will be tempted to put a lot of processes in place and begin to adopt “industry best practices” from competitors in your marketplace.  i say to exercise caution because the more processes you have, by definition, the less agile your organization is.  processes reduce your ability to make changes, and therefore your ability to innovate.

don’t get me wrong – some processes are important.  you do still need a ceiling, and you certainly need walls.  before you go making choices, however, think about the future.  are you making the same choices based on what everyone else sees as the newest fad, or trend?  are you making decisions that are restricting your organization’s ability to adapt to changes?  are you going to be stuck with popcorn on the ceiling that’s hard to change and mirrors on the walls that are expensive to get rid of?

don’t let “this old house” turn into “this old organization.”  always plan for the future.

image by elvez40, flickr artist

… they say you have to know where you’ve been.

i say, to get where you’re going — you have to know where you’re going.

stupid, right?  or is it?

whenever you start some sort of new venture, you have to know what the end state is. you have to set some sort of goal. otherwise, when do you know that you’ve gotten to where you want to be? when do you call it quits and move on to the next challenge?

i think one of the worst feelings in the world is when you’re churning away at something, tirelessly working, staying up night after night obsessing about how to perfect your work, and then one day asking yourself the question, where am i going with this?

some colleagues and i were talking about version control recently. in development terms, a product is usually given a dot-notation, integer-based version number.  v1.0 is generally identified as the first time you ‘go live’. this of course is not 100% solid; take, for instance, public betas and other test releases (you’ll also find RC — release candidate — versions in the wild). but what’s the difference between going from v1.0 to v1.1 — or — from v1.0 to v2.0? again speaking in generalities, a major change in functionality is usually denoted as a new version (i.e. v2.0) whereas enhancements to existing functionality or bug fixes are some form of dot-notation (i.e. v1.1 or v1.0.1).

but where does it end?

what’s the end state of your software, or your document, or your ms excel data model? do you stop at 3.0? at 4.0? at 4.0.23? beyond that? this is my point. when you talk about versions of something, it’s nice to say, “well we rolled out version 2.6 and we’ve started development on 2.7.”  it’s good for team morale. it certainly keeps the client happy (at least for a while) — but that doesn’t mean that you shouldn’t have an exit strategy. you ought to be building towards something; towards some kind of goal.

this is especially dangerous in agile or “spiral” development where requirements are made up on the go. “we’re done when we get everything into the system” is a horrible way to approach things. no one wants to be told that they could potentially be paying for something until the cows come home. there should be something that your system, document, etc. resembles in its finished state.  take that vision, make it your goal, and turn it into your mission.

what about your career?  what does sarah 2.0 look like?  for that matter, what does sarah 3.0 look like? when do you reach a new plateau and change direction to work on the next mountain?

to get where you’re going, you have to know where you’re going — otherwise, you’re just spinning your wheels.