Midwest IT Survival

Remind you of IT?

The first question that may be coming to your mind as you embark on reading this is why identify MidWest IT engineering and management as a separate categorization from IT engineering and management in general?  Is it because you have to consider roof strength in your data center construction so that you don’t end up with a pile of snow on your server racks?  Is it because there is a constant struggle to find key resources during the summer months or hunting season?  Well, I believe that the use of information technology in a traditional MidWestern company varies enough from a Silicon Valley technology company that existing books and articles on the skills and needs associated with succeeding have gaps.

Don’t get me wrong, there are a number of great sources of insight into how to succeed in functioning as an IT engineer or IT manager in the market.  Michael Lopp’s “Managing Humans: Biting and Humorous Tales of a Software Engineering Manager” book and associated blog, “Rands in Repose” (http://www.randsinrepose.com/) is a great and humorous source for the trials and tribulations associated with working in an IT workplace.  Yet, I believe there is a distinct difference in working for a company that primarily produces technology as its core business function (aka Silicon Valley) compared to a company that primarily uses information technology to support a non-IT based core business function (aka MidWest).  The “MidWest” categorization is being used loosely to identify all companies where IT isn’t their core product or service.  And yes, for all those reading with your brains thinking “but wait, I work for a company in the MidWest that does produce software for mass retail consumption …” I am not implying your organization is somewhat minimized compared to a Silicon Valley/Bay Area firm.  Rather, I am putting forth the notion that “MidWestern” companies, by and large, tend to use IT rather than produce IT thus the demands on an IT professional are slightly askew to say, a dot-com in Mountain View, CA.  From banking to manufacturing to insurance to mining to legal services, MidWestern companies tend to be large consumers rather than producers of information technology.

Thus, as either an IT manager or an IT engineer within a typical MidWestern company that largely consumes information technology from others, the attributes associated with the successes and the challenges these roles demand from individuals vary.  As an example, the likelihood that you, as an IT engineer in a MidWestern company, will be assigned any given technical problem and within minutes of reading the problem description, you will be able to saunter over to the cube of a peer engineer that can instantly explain in exhaustive you-are-about-ready-to-pass-out detail how the entire system works and why the problem is indeed a problem because he/she wrote the system … is exceedingly unlikely.  What is more likely is any given problem involves a convoluted evaluation process akin to this:

Engineering Situation:

Engineering Boss: “Bob, can you take and run with issue number 74864”

Engineer Bob: “Sure boss” <ugh>

Engineer Bob: <thinking> Ok, Sally can’t print ARS checks.  What the heck system is ARS?  I think I’ll ping Joe in the application group, he’ll know, he always seems to be working with Finance.

Engineer Bob: “Joe, do you know what the ARS system is?”

Engineer Joe: “Bob, Joe here, nope, what is the problem?”

Engineer Bob: “Joe, something about not being able to print checks”

Engineer Joe: “Checks …. printing checks … I think I remember a check printing enhancement phase 4 ruggedization project last year.  How about pinging Alan?”

Engineer Bob: “Alan, do you know what the ARS system is?  Maybe part of some check printing project last year?”

Engineer Alan: “Geez Bob, ARS doesn’t sound like …. wait, only system I know that prints check is SuperCheckPro 2000 … you might want to hit up Gary, I think he worked on that. ARS … ARS … no, I was just the QA guy on that project for the requirements gathering phase before the RFI/RFP.  Yah, talk to Gary on the second floor”

Engineer Bob: “Gary, know anything about ARS or SuperCheckPro 2000 and problems printing checks?”

Engineer Gary: “Yes”

Engineer Bob: <thinking> Oh boy, Gary is an architect; this is going to be a challenge “Gary, do you know what could cause SuperCheckPro 2000 to stop printing?”

Engineer Gary: “Lots of things”

Engineer Bob: <ugh> “If I were to need to investigate a check printing problem, what should I look into?”

Engineer Gary: “Send me the spool dump log”

Engineer Bob: “Where would I find that?”

Engineer Gary: “Under /var/logs/cp_spool on corp_unix15”

Mary from IT Compliance walks by: “I heard you are looking into that check problem … you are going to have to run this by the SOX people, right? ya know!” Mary vanishes as quickly as she appeared.

Engineer Bob: “Thanks”  <thinking> I bet I don’t even have a login to corp_unix15 … I think I am going to have to submit an ABC4567 form for that … I need to run this by the SOX people as well … oh joy.

Engineer Gary: “Send the problem over to Infrastructure … the box can’t find the printer on the network … they are going to have to open a service request with the vendor ‘cause we don’t support that printer which requires the ARS people to do that since they manage that relationship”

Engineer Bob: <thinking> Oh joy

And most problems take way more Joe’s and Gary’s to interface with in order to have any hope of getting some sort of progress on the problem.  Plus, actually seeing the problem through to resolution, which is a whole other story!

Management Situation:

Engineering Manager: “Why did I get this automated email saying our project number 789 failed the QA8 gate?”

Project Manager: “I didn’t get that email.  Can you forward it to me?”

Engineering Manager: “Yes, here it comes … I just got out of a client milestone update meeting and it would have been nice to know this an hour ago … I just told the client we are on track for 789!  Our VP already stuck his neck out and said this project was going in and would clear the client off the corporate audit report!”

Project Manager: “Got the email … let me get into the Project Center of Excellence portal site … seems we failed an architecture review committee sign off”

Engineering Manager: “What?  We are only adding ten fields to the data table because the enterprise data architects said we had to comply with the new enterprise service bus web service update that is going to push us those ten new fields that audit and compliance claims needed to be there!  What is architecturally wrong was adding ten fields their own group told us we needed to add!”

Project Manager: “I’ll check with the requirements architect to see why we didn’t get this signoff during the design review meeting last week”

Engineering Manager: <ring> “Oh great, my phone is ringing from the change management office … they are going to give me the song and dance that I am going to miss the noon cut off window for change approval.  That is going to bring the escalation heat from the change folks.  That call is going to voice mail for now.”

Project Manager: “Seems 789 didn’t qualify for a requirements architect because it didn’t score high enough on the quality gate 2 project scorecard.”

Engineering Manager: <ring> “Oh geez, word is getting out, the product manager is calling me, she is going to remind me that marketing communications have already been sent to customers based on our go/no go meeting last week since 789 is tied to her campaign due to the release cycle.  Voicemail again to buy some time …”

Project Manager: “I know Bob on the architecture review committee, I am going to try and give him a call and see what is going on.”

Engineering Manager: <ring> “It is getting better, next call here is from that guy in compliance that is going to threaten to tell the client they are going to be on the audit list as a level red due to not having those ten fields in that table by the end of the month.  This one is totally going to voice mail.  Wait!  This is going to get a whole bunch worse … our VP is walking to my cube … he never does … I think he was having lunch with the VP of product … word spreads too quickly … stay in my cube, we are going to have to explain the situation fast when he gets here.”

This could be an IT manager’s typical day with any semblance of a planned agenda of tasks to be completed for the day now completely out the window having to sort out this project mess.

In an IT environment similar in nature to the stories outlined above, a variety of non-technical skills are required to be matched with some level of technical competence in order to survive.

This collection of articles looks at these various skills from both engineering and management points of few and with a liberal dose of humor, tries to share wisdom to navigate while retaining as much sanity as possible!