Category Archives: Technology

The Price of Paying Attention

Time management doesn’t really work for most of us.  Sure, we can plan out our day, but then life intrudes at every turn and by the end of it the day is done and if we have check off anything on the list, we consider ourselves lucky.

So what do we do?  According to Maura Thomas, we can plan the day just fine; we are horrible about managing the distractions that crop up.  As she quotes William James, the author of a 19th century tome, The Principles of Psychology, Vol.1, he states simply; “My experience is what I agree to attend to.” In other words, if you can control the distractions, you can control your project.  Or even, your life.

When working with “Attention Management”, as Thomas calls it, you deliberately control both internal and external factors.   First, the internal.  Only one task at a time.  Yes, this flys in the face of multitasking, but I would rather do one job well, than four jobs haphazardly.  And spare me your comments about your ability to multitask.  You can’t.  Studies have proven it. Takes breaks from your technology.  Your phone and all the apps is designed to prevent you from accomplishing anything, unless you are getting paid to Instagram your food.

The other area concerns controlling your thoughts.  My mind wanders.  Boy, does it wander.  That five page paper took me 20 minutes to crank out, but three hours to get there. Yes, it is hard for many of us to focus.  But I am working at it.

The external factors are also difficult.  Remember what I just said about your phone?  Yeah, I do come from a mythical time, when a phone was tied to a wall and was used to call people. Period.  Controlling your technology is difficult for some of us, but as Miss Piggy famously once said, “If it’s important, they’ll leave a message for moi.”  That goes for texts, social media postings and the like.  If you HAD to be there to get the joke, it wasn’t that important. Important stuff is when someone has to alert the media.

Finally, controlling your environment.  I’ll say at this moment, whoever thought of the “no-cube wall” approach should be shot on sight. Not everything can be done by collaboration. We need privacy at times to take in everything and put it together for our understanding.  We need to be able to think without interruption, without having to overhear about Betty’s Yankee Pot Roast recipe. Use headphones,  or “Do not Disturb” signs.  Go to other areas of the building if you can, but focus. being alone with your thoughts is a wonderful luxury that people seem genuinely afraid of.

Not every distraction should demand your attention. being able to manage distractions allows you to be able to accomplish what you need to do and enjoy life at the same time.  It does not cost much to pay attention to the things you need to pay attention to.  But paying attention to the things you don’t need will cost you greatly in the end.


Thomas, M. (n.d.). Attention Management™ is the new path to productivity. Retrieved March 18, 2018, from


The Door Works Both Ways

“Open Door” policies should always have air quotes around them because that is what they are – full of nothing but air.  You know it, I know it.  It was a cliche when it arrived in the 1980’s and has devolved into farce ever since then.

I know, except yours.  I understand that the intent is meant to be sincere, but face it, boss, you know very few people are going to step up and walk in.  You know what would help?  If you stepped out and engaged your staff, because the door works both ways.

So, how do you grow openness and communication? You have to demonstrate transparency, accessibility, and collaboration. When you demonstrate to your staff that they can come to you at any time — they’ll start to do it.

First, share the plans

My previous CIO was constantly telling us what he saw and where we were going.  When someone pointed out rather cynically that he didn’t know how he were going to do that, he countered with “That’s why I hired the best people I could find to tell me that.  So tell me.” It made the day to day mean something to us.  It was a direction and we knew what that direction was.  It was up to us to get us there.  It had meaning.  We had meaning.

Stay curious

You have experts working for you.  Ever wonder how they came up with what they came up with?  Ask them!  You are not expected to be a genius, you are expected to be a leader.  A leader asks his people questions.  Not to point out where things are wrong, but to genuinely be interested in what they do.  Take advantage of all your communication streams.

Be honest and recognize effort

Feedback is great, but if something happening is immediate, be clear and specific in what you need to see.  I need to have A, B and C done by the end of the week, and if you run into a roadblock, you need to let me know immediately lays the groundwork clearly.  And make sure you give credit where it is due.  It’s not meant to fill someone’s ego, but to recognize the moment.  Someone just figured out a way to make an application process faster, or the tasks in a sprint were completed ahead of time?  Yes, they deserve the praise.

You work for them as well

Make sure you respond to your staff’s questions quickly.  That is why the door is supposedly open. It builds trust that if you don’t know, you can find out. Like above, if you tell someone they need to let you know if there is a roadblock, when they tell you there is a roadblock and what it is, they are expecting something more from you than “figure it out”. They are expecting some collaboration in seeing a way around it. Maybe you need to discuss the roadblock with someone higher who can help move it out of the way.

Now, do this consistently.  You soon see that people will not be afraid to enter you office, because they understand the door opens both ways.

The Health of your Fiscal Accounts = The Accounting of Your Physical Health

There are two stories this week that are totally unrelated, yet they are totally related. First, a sad tale.  Construction worker wins a million dollars in the lottery. One of the first things he does is go see a doctor, because he finally has money to do so.  The man finds out he has stage 4 cancer and dies three weeks after hitting the big time.

The second story is that this week three of the biggest names in American business: Amazon, Berkshire Hathaway and JPMorgan Chase – announced a new venture to provide better, cheaper health care for their employees. A fundamental problem with today’s system, according to the three multi-nationals is that patients lack knowledge and control. Access to data can bestow both.

Now while the second story is full of promise to “be disruptive” in the health care sector, access to data would not have solved the gentleman’s problem in the first story.  Most people have that gut feeling that something is wrong when they hit stage three on the cancer scale.  You know, weight loss, feeling of being tired all the time, things like that. Cancer is not like the flu; you live with it for a while  The problem is not knowing something is wrong, the problem is being able to do something about it once you know. Taking care of that problem most likely would have taken the gentleman’s winnings and still left him tragically in debt.  Perhaps, cynically, dying actually left his family in a better condition.

Unfortunately, that is where we stand.  We have all various types of technology that are being developed to help us understand what our bodies are doing.  There is promise, no doubt about that. But we still have yet to come to terms with how we can afford to take care of ourselves once the technology finds something.  Data is one thing.  The ability to act on that data is where we lose the game.

What Learning Does For Me

I’ve been back at school for a while now and considering that I am an older student surrounded by 20-somethings, I posed a question to my classmates about what learning does for them.  Some of the answer I received back were in the vein of  “I can make more knowledgeable choices”, “It allows me to find answers to problems faster” and “It has broadened my horizon on how to resolve issues at work and come up with new and fresh solutions.”

All these are great answers. Mine, is a little different.  Learning has slowed me down and caused me to question myself more. It has certainly allowed me to bring up information to support my case faster, but overall, it has forced me to look at how I put things together, and what that means, not only to me but to the matter that I am working on.

It has also stripped away any notion that there is one way of accomplishing something. I have found that at work, I am much more open to asking questions and opinions.  My decisions are still mine to make; however, I am more interested in other people’s stories and how they work through matters.  I am not so quick to dismiss.  I am also more confident with the decisions that I make.

It is said that knowledge is wisdom, but I would counter that understanding knowledge and how it works is wisdom.  I have met professors who know quite a bit, but are far from wise and a few of my cohorts who are wise beyond their years. I certainly have more faith in the next generation than I did going into this.  It’s not what you learn, it what you make of it.

Always Know Where the Emergency Exits Are

margarine4_thumb.jpgLet us say that something horrible has happened to every application you have.  And let us say that something horrible happened to all of your backups at the same time.

Armegeddon?  Yeah, maybe.  But what do you do?  Well, you have to rebuild from the ground up.  But how?

There is one thing, that if you have it, can mean the difference between rebuilding and sitting in the ashes of your company and cursing whatever higher being that happens to be available at the moment.  And that is a runbook.

A runbook is very simple and yet you’d be amazed at the number of places that A) don’t have one or B) never keep it up.  A runbook is basically instructions for the morons in Operations (like me) to rebuild your application from the ground up.  Simple as that. You make a change to your application, the record of the change goes in the runbook.  You move to a new server, the notation goes in the runbook.  You do anything to your application, it needs to be noted in the runbook. That way, if disaster strikes you have an ace in the whole.

So who creates and updates the runbook?  The development team.  And who houses the runbook?  Operations. Why?  Operations houses it because we are going to be the ones who need it should something happen.  Because Operations has multiple applications to watch.  We do not know the intricacies of your application like the people who created it.   So do not ask Operations if what is in the runbook everything we need.  Short answer: we don’t know. It’s your application.  You hand us the runbook with the understanding that you have put YOUR knowledge into it.  Now when a change goes into the runbook, it is operations responsibility to note the change went in and when.  But if you decide to move to a new server or make major structural changes, again, it is the development team’s responsibility to update.

And that is where the problems with runbooks lie. Everyone is pressed for time, no one ever has a technical writer when needed and all of us have a tendency to say “We’ll work on that tomorrow”.

And sometimes, tomorrow is not exactly what you expect.



Your business unit has decided that everything must go.  There’s a new logo that must be on everything.  They hate the interface; it looks dated.  Animation?  Ugh.  Nothing works right on their phones.  They need apps, for God’s sake.  Reports are not giving them the information they need.  And who the hell approved that lime green color everywhere?

To paraphrase Bowie, “I’m quite aware of what you’re going through.”

But before you start changing everything, you first need to plan this out.  You know that.  I know that.  That is what a change ticket is all about.  Once you have your business needs arranged and know what has to be where and why, then you need to fill out a change form and have change management have a look at it.  You need to do this before you drop the first keystroke of coding.  Why?  Not all change happens in a vacuum.  What you change may well affect another user or business group.  As change manager, I need to know what you are planning on doing.  I may be aware of something else that is going on that may conflict with your plans.  If you are upgrading, I need to know in advance so I can start to update information.  You may have to make some alterations dependent upon what is going on, and it is better to have that information up front, rather than the day you want to deploy.  And if I know in advance I can make sure that everything is ready for you.  Change Management is your partner, not your adversary.

Cue the sax solo…

How Do You Solve a Problem Like…

ITIL is not an abbey, but was Maria an incident, or a problem?

At what point does an incident become a problem?  That is a question that unfortunately may have multiple answers.  After all, in ITIL, an incident is something that happens.  If it continues to happen, or if multiple people have it happen to them, it can become problematic.  But a problem?  As much as I detest ‘squishy’ answers, the answer to this conundrum is, it depends upon your organization.

Some organizations take a lot of pain before assigning a problem.  Some almost immediately assign incidents a problem depending on the length of time the incident is open, or the number of people calling in who do not want to follow instructions in the knowledge base.  It really does depend. There’s the squish.

However, there is a good rule of thumb.  First, you need to know the severity of the incident. Is this almost all of your customers or just a handful?  If this is something that is happening to just some people, then is there a knowledge-based article about it?  If not, there needs to be.  If you do have a KBA out there, are people using it and what are their reactions to it? Is it perceived as an easy fix or do they need to perform a voodoo ritual in order for it to work?  Trust me, your customers will let you know.

Then you need to assess the incidents, your customers and the fix itself.  As this is still an incident, it has passed through all of the levels of support, so you will have some general idea as to what needs to happen to fix it.  And by now, you know about how many people this incident affects.  The next question is, how much pain is you organization capable of enduring?  No one like to hear the same complaint over and over.  But sometimes, the fix is more than the disease.  Sometimes, however, a fix easily can be found and there you are.  Problem it is and soon to be problem solved.

But sometimes, problems cannot be solved by marrying them off to well known Austrian war heroes.  More about that in the next post.

Show Me On the Ticket Where the Bad Thing Happened

If you picture your Help Desk like this, it can make you feel a little better.

Not to sound dramatic, but an Incident is kind of like a crime scene. In order to piece everything together the person on the help desk needs to know exactly what happened.  Everything.  Yes I know, what you need doesn’t work, but I need to reassemble the crime scene in order to see what happened.

That is why putting everything on your ticket is helpful.  This is not a blame game, but an investigation. Sometimes, (actually, more than you think) one software program is at odds with another, and yes, this can happen when the software packages are created by the same company (I’m looking at you, Microsoft).  Sometimes it is user error.  Hey, we all make mistakes.  And sometimes what is happening can actually be a symptom of something far worse.  But unless the incident team knows what is going on, the incident is nothing more than ” Damned if I know.”

So, what needs to be on the ticket?  First, besides your name and how to contact you (which should be automatically recorded on the ticket), I need to know the following:

  1. The time it happened.  This helps us if we need to check server logs.  Things happen all the time, so knowing when it happened helps us dig through the chaff.
  2. Exactly what happened.  The more detailed you can be, the better.  Just saying “It doesn’t work” means we have to call in Miss Cleo and her tarot cards to divine what happened.  And while I love her fake Jamaican accent, she’s never right.
  3. What else was running in the background.  Excel is giving me an error message and I have Word and Visio also running.  This may have something to do with it, it may not.  But we know that there are other avenues we might be able to check if our first assumption is wrong.
  4. Screenshots.  Just like a crime scene investigation, pictures record a lot more than people think.  If you have an error message, get a screen shot to add to the ticket.
  5. If your ticketing system does not capture the information concerning the computer you are on (Some do, some are stupid), then please add that to the ticket as well.  There are times when the hardware does not play nice with the software.

In other words, nothing gets ruled out at the start.  Once we can verify the alibis for various parts, then we can find the perp, solve the problem and wrap up the case a lot neater the Law and Order sometimes does.  If we find that what you are experiencing is part of a larger problem, well, we have a larger case to solve.  We’ll keep you updated.  Olivia Benson never gives up.  Neither do we.  *Chu-CHUNK!*

You Are Not The Most Interesting Developer in the World

Where I work, we deal with developers who were apparently dropped on their heads at a very young age.  Repeatedly.  Onto concrete.  Repeatedly.  I also work with project managers who apparently had the same thing happen to them.

The reason I point this out is because some people truly believe there is a cost savings in combining development, test and production in to one happy little world.  You know, because every developer does everything right the first time. Or at least combining development and test, because, really, those are one in the same.  I actually had a PM tell me this in the last week.  As my father used to say, “That boy is about as sharp as a sack of wet mice.”  I’ll simply add, “Bless his heart”.  Because thinking it can be all in one is the coding equivalent of “Hold my Beer”.

For the uninitiated, the development area is the place where the developers can make multiple horrendous mistakes, or develop, take you choice of phrasing.  The test area is a place where you actually make sure that whatever you have developed installs as it should and that everything should be working as it is designed to.  Production is that area that everyone actually uses and they don’t take kindly to things changing or not working as designed in the middle of an actual transaction.  If you think they do, then I’ll give them your number and you can be a customer service rep as well.  Have fun.  Some groups also include a fourth level – User acceptance testing, or UAT.  This is an environment that your test group of actual business users beat on to make sure everything works to their standards after QA, but before production. I personally fond of the four-tier layout, because It brings the business in on the final product, and anything found afterwards in on their heads, not the development team’s.

Now in this multilayer fiesta there are some points that as operations, I demand.  First, all environments  should resemble production in the fact that the server structure is the same, and you have the same basic software running in the background, because there are indeed differences between, say, .NET 3.5 and .NET 4.5.  Really, there are.  That’s why they are different numbers.  Someone at Microsoft didn’t just decide to change it because they were bored.  If your production server is running .NET 3.5, then why are you developing on something else? Do not talk to me about upgrading on the fly because of backward compatibility.  Sorry, it is something that may work 90 percent of the time, but that remaining ten percent always bites you in the ass.  Replication applies to your databases as well.  Table structures need to be the same.  Change one thing, it needs to go through the whole set and it needs to be tested.  Yes, it is a pain in the neck.  Yes, it takes time.  Why all these restrictions?  Because you are not a cowboy.  You are in IT.  You want freedom, move to Montana and raise dental floss.  But do not ask me to hold your beer.

And you are moving this into production, because…?

And I said “Get out of here, you Loch Ness Monster!”Let us say you are world famous fashion designer Karl Lagerfeld. You are getting ready to present your fall line to the public.  The lights go down, the models are ready to go and the show begins.

The first model hits the runway and about halfway down, Anna Wintour, editor of Vogue Magazine, suddenly jumps up and says “Darling that makeup is all wrong” and stops the model and proceeds to redo the model’s make up in front of the world’s fashion press.

What would you do?  Well, if you were Karl Lagerfeld, chances are you’d be in a Paris jail for beating Anna Wintour to death with a stiletto in front of Kanye West.  But basically this is what we in operations have to deal with on a daily basis.  Someone on the business side sees “something wrong”,  runs down to IT, grabs a developer and yells “FIX IT NOW”.  Now, there are a few thing blatantly wrong with this.  To start:

  1. Is it really wrong?  The same rules should be applying to everything, so if one data point is off for one, shouldn’t it be off for everyone?
  2. How is it wrong?  How off is the calculation? Exactly what should it be?
  3. Who are you and why are you in here yelling at a developer?  I’m  Operations.  I should be yelling at the developer, not you.  Shouldn’t you be talking to the project manager and going over what the rules are?

And of course, the one question that everyone misses.  What time is it? You see making changes in production is something that is dependent upon timing.  And timing in operations is like timing in comedy – it is everything.  There are risks involved with dropping changes into production in the middle of the day like a hot mic.  I need a reason why you are hell bent on shoving this in at lunch time.  Not because it is my lunch time (which really never matters), but because I have to answer for its possible failure.  There are reasons why changes are done during low traffic hours.  It doesn’t affect as many people if and when it blows up.  There is also the question of verification.  When this change goes in, how long do we need to wait to make sure that everything is OK?  If it is so important that your boss is two steps from an aneurism, then why does it take you three days to verify the procedure was done correctly?  Just saying.

Oh yeah, do the paperwork.  It’s not a problem if there’s not a ticket.  And straighten you tie.  Anna hates that.