Archive for January, 2012

Avoid the Slacker, Find the Mentor

The whole idea of creating this blog actually started last week when I read an article on Infoworld written by Dan Tynan. The title of the article was:

12 Effective Habits of Indispensable IT Pros – Ditch the slackers, take on dirty work, do it with data — here’s how to get the inside track on a highly rewarding career in IT

The article listed 12 tips on how to be a better IT professional. After reading the article, I decided I wanted to share the list with my team of 50+ IT professionals. It was a fairly long article so I decided to break it up into a series of 12 daily messages. Each day I sent the team via email (old school baby) one of the 12 Habits along with the insight of Mr. Tynan. I also added my own commentary about my take on the habit and how it could be applied to our business. Each day my commentary section grew longer and longer and I started to realize that many of these tips reached beyond just the IT realm and applied to all facets of business. That is what made me finally decide it was time to enter the world of blogging.

While I probably will not share all 12 of the habits presented in the article, I do think several of the next blog entries will use that article as a basis. For if no other reason than the fact that I love the word “slacker” I think this is my favorite one:

Effective IT habit No. 6: Ditch the slackers, find a mentor
Hanging with a crew that likes to take long lunches and knock off at five (or earlier)? You’re not doing your career any good, says David Maxfield, author of “Change Anything: The New Science of Personal Success,” a book about alter your career-limiting habits.

“The habits that hold you back are likely enabled, tolerated, or encouraged by others,” he says. “Use positive peer pressure by surrounding yourself with hardworking friends who share your career goals. Distance yourself from the office slackers.”

Instead, Maxfield advises you seek someone with more experience to steer your career in a positive direction. “Find a trusted mentor,” he says. “That will help you navigate the career development opportunities that exist within the organization.”

My Commentary: I love the title of this one – mainly because the early 90’s Richard Linklater movie “Slacker” was filmed in Austin. So every time I see the word “slacker” I think of Austin as it was back in my college days. Back when Austin was better known as a college town full of highly educated slackers. If you have never seen the movie, find it on Netflix, Hulu or whatever video service you prefer and check it out.

So last week, I encouraged everyone in the IT organization to go out and interact with people. And now here I am sharing something that says “watch out who you hang with.” While I could ramble on about slackers and the pros and cons of hanging out with them, I instead want to focus on the last piece of this installment – the mentor.

Having a mentor is a great thing for anyone looking to grow professionally. That mentor may be someone within the company or someone you have worked with in the past or just a person within your community that has been successful. I found my mentor about 15 years ago. He was the lead partner in the Austin office of the consulting firm I was working for at the time. His name was Bob Glickert (yeah I know – funny because I don’t like being called Bob.) As time went by, I just called him Bobby G.

Although I was just an entry-level consultant, I engaged him in regular conversations about the inner workings of the firm, how projects were priced out, how profitability of jobs was measured – all things that had nothing directly to do with my day-to-day tasks as an entry-level guy. But I learned a ton about business from those conversations. With him as my mentor and my willingness to travel 6 days a week and work 100+ hours a week , including one week where I charged 142 hours, I quickly went up the ranks from Consultant to Sr. Consultant to Manager in about 2 1/2 years.

I worked on some good projects and some really bad ones, but I learned from each one of them. Having that close relationship with him also gave me insight into a transition of the firm from a partnership to a public company. And while going public didn’t go that well ( I learned first hand what having “underwater stock options” was all about) that transition alone taught me tons about the world of big business. I look back on that 5 years as the time when I transformed from being an accountant to being a technology consultant to becoming a businessman. Having Bob as my mentor made that change possible.

When I left that firm 10+ years ago to come to Harte-Hanks, I continued to keep in touch with him. We would talk on the phone once a month and would meet for lunch every couple of months. I would use him as a sounding board for ideas and get advice on how he would handle certain issues that I was facing. It is 10 years later, and while he is now retired and spends most of his time in the mountains of New Mexico, we still keep in contact and I still consider him an influence in my career. I look back at my development and growth in the past 15 years and I know I owe much of it to his guidance.

So my advice to you: 1) if you don’t have a mentor, find one and 2) if you do have a mentor make sure you continue to leverage that relationship for as long as you can.

Slam Dunks: No Such Thing in IT

There are No Slam Dunks in IT.

That’s a saying I have thrown around for close to 10 years now. But one that I think too many people in technology fail to remember on a daily basis. They get caught up in the urgency of the moment, short cut change management procedures, fail to think about the downstream impact of what they see as a minor, isolated change. All too often the mindset of “the easy change,” “the lay-up,” or “the routine lazy fly ball” ends up as an unexpected outage. That break away slam dunk clanks off the rim and bounces out of bounds. That easy two points turns into a turnover.

As we kicked off 2012, a relatively new to the company network engineer noticed that a top of rack server switch had two fiber uplinks but only one was active. Anxious to make a good impression, he wanted to resolve that issue. It was an admiral thing to do. He was taking initiative to make things better. So one night during the first week of the fresh new year, he executed a change to bring up the second uplink. Things did not go well as the change, and I will not go into the gory technical details, brought down the entire data center network. It was after standard business hours – whatever that means in today’s 24×7 business world – but the impact of that 10 minutes outage was significant. A classic case of a self-inflicted wound from not following good change management procedures.

It was actually a frustrating incident for me, because as we put together the 2012 Business Plan for Corporate Technology Services, we were asked to list the keys to success for our operations and the actions we needed to take achieve success.

THE #1 key for success listed was: Avoid self-inflicted outages and issues that take away cycles from the planned efforts and cause unplanned unavailability of our client facing solutions.

So 30 days prior I had told our CEO, CFO and the rest of the executive management team that our #1 key to success in IT was to avoid such things, yet here I was four days into the new year staring at the carnage of a self-inflicted outage.

Outages are close to a given in the world of technology. Servers will crash, switches will randomly reboot, hard drives will fail, application will act weird, redundancy will fail, and there will be maintenance efforts that we know will cause outages. Given that, every IT organization must take steps to not be the cause of even more outages. Business leaders know that there will be some level of downtime with technology – have you ever seen a 100% SLA? Rarely. It usually some 99.xx% number. But outages that are caused by the very people charged with keeping things running drives them nuts, and rightfully so.

The morning after that self-inflicted wound, I communicated out the following to every member of the IT organization:

We need to strive to make sure that we are not the cause of any unexpected outages. We must exercise good change management process and follow the five actions listed above. As our solutions and the underlying infrastructure become increasingly intertwined, we must make an extra effort to assess the potential unintended downstream (or upstream) impact as we plan the change.

When making a change we must always follow these steps:

Plan – make sure each change action/project we undertake is well thought out, steps are documented, risks are assessed. If disruption in service is expected, plan for when we make this change to limit the impact of the disruption.

Communicate – communicate each change action/project to the parties potentially impacted prior to executing the change

Execute – flawlessly execute according the plan developed

Test – test to make sure that the change executed resulted in the expected results and there are no unintended consequences from the change

Communicate – communicate to the potentially impacted parties that the change has been completed and tested

To keep this goal of avoiding self-inflicted outages top of mind, we implemented a ‘It’s Been X Days Since our Last Self-Inflicted Outage” counter. Basically taking a page out of the factory accident prevention playbook.

We had to reset it once after we implemented it, but we are now at 19 days and counting. Let’s hope that the next reset is no time soon.

What’s In a Name

My middle name is Daniel. For the first 18 years of my life I was known by all simply as Dan. I had a first name, but no one used it. I was just a shortened version of my middle name – at least it was not Danny. I was “Dan the Man”, “Dan, Dan if he can’t do it no one can.” Three short letters. Short and sweet.

When I hit college at THE University of Texas, the professors that first semester called on me by my first name and being a timid young kid from a small town, I just went with it. Before long, most people in Austin knew me as Robert, so I just went with it. More importantly I liked it. I was “Robert” – my real first name. Not Bob, Bobby, Rob, Robbie, or Bert – just Robert.

Over the past 20+ years, I have almost completely lost all references to Dan – except for the rare times I venture back to my hometown. Even my parents usually call me Robert now. Only my sister insist on calling me Dan, mainly just because she knows I don’t like it.

So that gets me to the name of my blog – RobertnotBob. I have become very protective of my moniker. I am Robert. When unsuspecting sales guys cold call me and address me as Bob or Rob, I promptly let them know that if they ever call me that again, then I guarantee they will never make a sale. A little harsh, I know; but I just think it is just a little presumptuous to shorten someone’s name right off the bat.

Now don’t get me wrong, some guys are better off with a shortened version. Bob Marley: who would want to party with Robert Marley? Same with Bob Dylan and Bob Segar. Bob Dole: saved a few dollars on those campaign signs over the years by avoiding the extra letters. Do you think Sponge Robert would have been a big hit – I doubt it.

So if you ever run into me in the real world or the virtual one, do me a favor and call me Robert.