By Laura Haight
Originally published as The Digital Maven, Upstate Business Journal, Greenville, SC on Feb. 8, 2013
The only way I ever learned anything was by messing up.
Unfortunately, that is the case with most of us. Still we would be abrogating our responsibilities if we didn't pass on some cautionary wisdom gained from our experiences.
1. Get out of the data center, unlock your door, and start walking around your building. See how people really use technology. Find out from the least skilled user how things are going and watch what they do. Those are your areas of opportunity to make a difference.
When employees ask us to write a program or set up an account here or install this application, we should not go blindly into the task just so we can add it to complete jobs stat at the end of the month. The question that should be asked is: "What are you trying to accomplish?" IT has programs, software and capabilities that we cannot expect users to know about. And will know how to provide best technology path to the result you are looking for.
It's the fault of IT professionals who they are often happy to stay in the mysterious data center, behind locked doors, pounding away on keyboards at programs with indecipherable names (what is Ruby on Rails, anyway?) The combination of insular IT staff and business executives who are content for them to stay that way has cost companies untold millions in wasted effort, unnecessary expense and underused capabilities.
2. Standing at the crossroads of “nimble” and “reckless”, remember that things become cliches because they are true. Like: If something can go wrong it will.
Last week, I got an email via LinkedIn from a former employee. He had actually been on my mind recently for no particular reason and I remembered the time he wiped out our entire email database by installing a piece of software we were considering. He said he just thought it would be no big deal. Until it was.
Up until then, we had not had policies and procedures for testing and deploying new software. We were a small newspaper and we ran a (very) tight budget. That disaster spurred us to develop policies, testing procedures and implementation checklists and timelines that allowed for proper testing. I took quite a beating for the problem, but became a lot smarter, a lot more quickly as a result.
In today’s “can-do” environment, IT is so often seen as throwing up barriers to success. But those procedures come from years of losing your email, overwriting the database and struggling through bad implementations.
3. Think operationally, not technically when things do go wrong. IT guys want to know why something happened so they can fix it forever; operational staff want to get the darn thing going so we can fix it for now!
That can put you at odds with each other, but a lot of very smart IT guys just don’t think like business people. In part, it goes back to how involved they are in the business - understanding not just the technology, but how it is used.
Crashes, hacks, and other disasters require a two-pronged attack: Get us functional first, then find out what happened, fix it and make sure it won’t happen again.
4. During a walkthrough at a new job several years ago, I was struck by this room full of dust-covered equipment. It looked new (other than the dust) and I knew it was costly. So why wasn’t it on the floor? “Oh, it never worked right,” was the response.
There was a lot of that at this location and there may be at yours as well. Expensive technology that got sidelined rather than properly implemented. Employees generally resist change and will revert back to the old, comfortable ways pretty quickly unless someone is championing the new and making sure it’s implemented properly. That also means asking the question: how is it going? And quickly correcting problems so employees have no reason NOT to adapt.
5. Letters after your name and on your resume don’t mean everything. I was always a bit of an oddball in IT. I readily admitted that I was the least technical person on the IT staff. But I was a gizmo, a very talented user, a smart business person who understood my industry inside and out, and a forward thinker. I could not write programs, but I understood what technology could and couldn’t do. So I could articulate business needs to programmers and technical leads - and translate the tech talk to business people.
You need someone like that in your world - whether it is on staff or a consultant or a member of your advisory group. Certifications aren’t the only valuable skill a technologist can bring to your business.
Oh yeah, the former employee I mentioned is now the vice president of global messaging for one of the nation’s largest multinational companies. I congratulated him on making a great career. He replied: “Hard work, opportunity and the chance to learn from my mistakes.”