Contributed by Fulcrum Group President, Steve Meek
Maybe the stereotype is true to some degree, but I have found that many people think of IT people as either having no personality, or else that we are driven by the motor of perfectionism.
OK, in some cases, we bring that reputation upon ourselves…but overall, I have found most technical folks also genuinely enjoy solving problems and have a great desire to help others. We are all painfully aware that technology sometimes doesn’t perform as it should, or unpredicted results occur, despite our best planning and knowledge. Having been in the tech industry my entire adult life with skills well-shaped over time by successes and risks, screw ups and shortfalls – I’d like to share with you a few valuable lessons I’ve learned since my early days in technology:
- Communication – As a young man in the silicon era of America, the memory of my first PC ranks up there, alongside my first car. On a cool, college morning in West Texas, I asked a buddy of mine who built computers what it would cost to purchase an XT system. He rattled off a litany of computer terms and I, as a lowly business major, could only focus on timing my nods after pauses that sounded like the sentence was done. Absolutely nothing he said made sense but the number at the end sounded agreeable. So, we shook hands and soon the glorious day of my new personal computer arrived. I accepted the challenge of assembling it myself (no instructions on the Internet back then) and when I powered up my new beast nothing really happened like I expected. When I work on cars, there are always parts leftover but alas here, I used them all! In the end, I finally broke down and called my friend and admitted I screwed something up and needed his help. I explained what I did and he finally asked “what operating system did you install?” I replied, “Well, what did you sell me?” He didn’t include an operating system and I didn’t know to ask.
Lesson Learned – Ask good questions up front (including what’s included). From my friend and his profuse techspeak, I also learned how important it is to break things down into language everybody understands. I enjoy tremendously when non-IT people ask me technical questions because it feels great to help them understand what I love – technology.
- Not Knowing It All Is Ok – After college, I still didn’t know what I wanted to do with a business degree and a love of computers. I found a fun opportunity in the early days of the PC, working with a young computer retail store that had recently changed its name to CompUSA. While working the retail floor one day, a customer approached me for help with an Uninterruptible Power Supply (UPS). At the time, the only UPS I knew delivered packages but I hoped “helping him” might mean carrying the big box to the car. He stumped me when he asked, “how do I know what size UPS to get?” Hesitating, I responded, “I really don’t know but could try to help…” He smiled at me kindly and asked if I’d like to know – then proceeded with a 15-minute discourse on volt amp ratings and run times that made my head hurt. Painful then; helpful now.
Lesson learned – It’s OK to say you don’t know something. I have become empowered by the fact that no one can know everything about everything. To me, great technologists aren’t just folks who have a lot of knowledge – or all the answers. To me, great IT people know what they know – and what they don’t know. One reason they are great is because how they deal with situations that challenge others. Think of technologists you admire. I’d be willing to bet they have a very structured, disciplined approach to solving problems. And that goes a long way toward making it seem like they know a lot.
- Surround Yourself With Good People – By the mid-1990s, I was selling IT solutions to businesses. One of my clients asked me to come by and discuss some software they wanted to purchase. Software is a pretty straightforward discussion, but that day, I just happened to grab an engineer to go on the call with me. We met at their site, they quickly explained the software they needed and then asked if we could help with another need. We were escorted to the doorway of a 10×20 room lit up by a ton of blinky lights. They said their Kalpana switches were getting old and were thinking of replacing them, then waved my engineer and me into the space. I looked for a minute and realized I had no idea which blinky lights were switches so all I could do was turn to my engineer and ask him “what do you think”.
Lesson Learned- If you are not the expert, find the expert to help out. Adam Smith’s macro-economic theory from business school comes to mind, which explains that with job specialization, both parties can benefit more. Having an engineer with me definitely helped me in the blinky switches scenario and functioned as a prototype of sorts for our current outsourcing services. Now, not only have we refined our IT outsourcing services, but have tended to outsource some of our internal needs as a business as well, to stay focused on our core skills.
- Preparation is Key – Still in the 90s, I was working with a Municipality that wanted to consolidate their Netware 2.x, 3.x and 4.x servers into a single environment based on the newest version. During a meeting with the admin-oriented CIO, he started asking me questions about design. So, as a salesperson, I suggested we provide some light training. Our best engineers loved Novell but weren’t presenters, so I read the Design and Implementation Guide over a couple of days and put together a presentation that the CIO really responded to, feeling it would improve our project success.
Lesson Learned- Preparation always increases success and quality. The prep work behind that presentation content really boosted our project management success. I’ve come across many IT people who claim to be self-made and hands-on, no certifications needed. While certification doesn’t always equal “expert”, I have learned, likewise, that no certification doesn’t necessarily mean you’ll do a great job. We push our guys for hands-on skills and also encourage certification as part of preparation.
- Pay attention to the details – My consulting path has taken me from operations management, to technical sales, to technical project management. Earlier on, I remember working on a client’s server doing maintenance and had to reboot one of the servers in their server room. I switched the monitor to the server I needed to reboot and exited the room. Ten steps away to the front desk, I asked the contact if I could reboot a specific server. She responded to only reboot that server, as they were in the middle of transferring some data on another server. Unbeknownst to me, the person doing the transfer walked into the server room and switched the monitor and keyboard over to his server. So, when I walked back and kicked off the reboot…well, you know what happened.
Lesson Learned – Verify details along the way. Projects change, needs evolve. The more parties involved, the more “unknowns.” It is our normal procedure to document and create snapshots in time of client sites. We have monitoring that grabs details. But a great engineer still verifies the details along the way. Automation can really help with repetitive tasks but great IT still needs a person driving the activity, with quality in mind.
In the end, whether you’re in IT or depending on your IT, mistakes are going to get made, and they might hurt. IT people, end users, vendors, manufacturers, CIOs – no one’s perfect. But when mistakes are made, we have to be able to count on the people we depend on to be open to learning lessons.
Here's a little bonus piece for you on a few well-known Americans and some of their snafus. Enjoy!