Midwest IT Survival

How do you build a strong team?

Some find having to go to work every day … day in and day out … to be a drag, but if you have ever worked on a strong team, you know that that drag isn’t so bad because you have peers around you with a sense of team work that has everyone pitching in to do quality work with a strong sense of pride.  In the previous article I elaborated on elements of a strong team.  This article picks up where that article left off … how does one go about creating a strong team?

How do you know if you are on a strong team?

Simple, you can cite current and frequent examples from your day to day work that align with the elements shared in the previous article.

How does one go about creating a strong team?

A bit harder … up front, a strong team culture, as so often quoted, starts at the top.  The team manager must take steps to foster such a culture.  Micromanaging the team is a sure way to block any sprouting of a sense of strong team.  The manager needs to set the tone that cooperation and teamwork is favored and rewarded with shameless self promotion frowned upon.  Empowerment or more simply, allowing people to do their jobs with low supervision and coaching rather than pointing out failures or frequent “is it done yet?” status queries goes a long way to encourage teamwork.

A team lead or manager also needs to show an outward passion towards the work the team is doing; including taking an interest in what each team member is doing such as listening to what they are getting excited about.  Is it that new development component that enables all kinds of rich UI features?  Is it that next platform upgrade that includes an ability to take a virtual snapshot of a box nightly to aide in troubleshooting those “happens once in awhile, but when it does …” problems?  Is it that emerging architectural standard that will make a great cup of coffee while curing cancer at the same time?  Technical people get excited about aspects of technology that align with their interests.  In leading a team, being aware of professional interests and looking for opportunities to steer those interests toward current and future service demands will help to create a sense of a strong team.  Team members seeing their interests align with work requests will instill a true sense of importance with each individual.  This creates a real notion of “my ideas are being heard and acted upon” and further supports the concept of a strong team described in these articles.

Another opportunity to build a strong sense of team is to try and emphasize a narrow focus for the team’s services.  “We do this, and we do this … of, and we also do this other thing once in awhile” will tend to water down the team’s focus.  In watering down, the team members will see very little overlap in what they are working on with other team members.  With little overlap comes little drive to cross communicate, share items, help solve each others problems, etc.  Sure, a team most likely provides multiple services, but by bringing those disparate services into a more singular and common theme, team members will begin to see how their work overlaps other team member’s work.  With more overlap, team members will be more inclined to share ideas and communicate.  Individuals with technical problems will feel more apt to share since others may have worked on similar issues rather than assume they are a one person silo and will continue to plod along trying to solve the issue on their own.  Also, to reinforce this sharing, as a team manager or lead, try to mix up who is working on what group of tasks.  If Bob is the printer expert, try to avoid routing all printing problems to just Bob.  Not only will Bob grow tired of being the printer guy, he will have no one else to chat with and generate new ideas and approaches to printer problem solving.  Plus, as an added bonus, mixing up the task handling will increase your team’s ability to handing spikes in requests, increasing work throughput, and reducing single points of service failure.

What other external factors develop a strong team?

As a leader, one can try all of the above techniques and achieve some degree of a strong team, but external forces help to bump up the sense of team even further if handled positively.  One external factor that a team led or manager has no real control over but he or she can leverage to their advantage in creating a strong team is having a small team being charged with providing services within a larger organization.  The theme of being the under dog that is struggling to succeed against some difficult odds helps to galvanize a team together with a sense of survival that ultimately builds team work.  This is also colloquially referred to as going up against the 800 pound gorilla.  It is the tried and true notion that working together against the larger “foe” will result in more success than going it alone.  One point of caution, carrying this “us against them” theme too far into a negative tone will work to undermine morale by making people uncomfortable to be pushed to be combative.  Thus, make sure to have a sense of competitive pressure in working within the larger organization but be careful not to proceed into negative territory:

Not OK: “We hate that other team!  They are terrible.  They make our lives miserable.  They can’t plan worth beans and thus everything is a last minute crisis.  They don’t know what they are doing.  We could do their jobs twice as good in half the time …”

Better: “Man that other team is demanding.  They are our most challenging customer.  Since it doesn’t look like they are going to change, what can we do to reduce the last minute crisis requests on our side?”

Another external factor that strengthens a team is going through a demanding work activity involving everyone pulling together to get the job done successfully.  The immediate example that comes to mind is having everyone pitch in together to complete a bunch of tasks for a project that has an aggressive deadline.  By pitching in and completing the work together, everyone shares in completion glory.  Under the tight time pressure, applying the approaches listed prior and acting as a coach or mentor rather than a task or slave driver can give everyone that sense of working together equaled the final success.

Anyone have any other examples of techniques one can use to strengthen a team that one has control over?  How about example of other external situations that, if handled a certain way, can strengthen a team?

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

• Role of the Sales Rep

The Vendor Sales Cheese can keep you off the phone and on your keyboard

In the previous article [], we explored this role more deeply and how, as an IT manager or IT engineer in a MidWestern company, you need to partner with this role to be successful in delivering you and your team’s services to the company.  We established the notion that as either an IT manager or IT engineer, instead of bolting for the nearest keyboard, there is benefit to spending five minutes introducing yourself to the Vendor Sales Cheese and giving him or her a clear understanding of your role within the company and how you are linked to the product or service the Vendor Sales Cheese is representing.  We left off suggesting that this brief exchange will pay off in tactical dividends.  So, enough with the preview, what are these so called dividends?

IT Engineer Dividends

In short, someone to suck into your troubleshooting effort to get you the technical expertise you need without having to sit on the phone on endless hold finding it yourself.  Someone you can say: “Hey, I did everything I was supposed to do to get help and I am stuck.  Get someone who can speak at my level that knows your product and can help me get this working ASAP.”  Take this typical scenario:

A technical problem makes its way through your business call center through the IT technical support helpdesk to your inbox.  Based on the brief explanation of the problem and the levels of “reboot your PC and try again” and “close your browser, clear your cache and try again” that have been tried with no success, this hypothetical situation suggests you are going to have to roll up your sleeves and figure this out because likely, no one else can in the company.  So, after much wailing and grinding of teeth, you are able to reproduce the problem in a test environment and have ruled out everything except the FlimFlam product.  From everything you can tell, you can now get the problem to occur at will, but all the FlimFlam system does is throw an “Error Code 57: Process died unexpectedly”.  The almighty Google is no help with error code 57.  The vendor’s tech support web site or “knowledge base” (which you have now dismissed as an oxymoron) completely mocks you with no reference whatsoever to error code 57.  So, no instant problem resolution gratification today, you have to log in to the vendor’s support web site with your company’s magic trouble ticket account to open a support issue.  You have been down this road plenty of times before, so you succinctly enter the exact end user steps to reproduce the problem and generate an error code 57.  You cut and paste in a copy of the system log that says “yep, I’m definitely throwing an error code 57 … and unexpectedly as well!”  You provide your platform and vendor product version, revision, and patch level down and dump the configuration out to the final detail.  You get back a trouble ticket number which you write down in the false hope your next email from the vendor’s support site will have the magic cure.

Off to lunch at the default route … err, food court at the mall

When you get back to your desk, you see an email from the vendor’s support site indicating your ticket has been closed.  You log back into the vendor’s site to see the last ticket status entry read:

“Upgrade to the latest version by applying patch 59837”

You switch over to the download tab and punch in “patch 59837”.  You quickly skim the release notes only to find absolutely no reference to error code 57 or anything that even resembles the problem you reported.  You’ve played this game many times before.  But you know, you have to play it or you get stuck at this level in the game, forever unable to advance.  So, you download patch 59837.  You install it in the test environment.  No install errors.  You re-test the system and low and behold, on the first attempt, you generate error code 57 with the same “unexpected-ness”.  So, you go back to the vendor support site.  You re-open your ticket; indicate you did exactly as told with no success.  Again, you’ve been down this road, so you re-state the platform and product versions showing the new patch applied.  You re-attach the log files and a dump of your configuration settings.  You re-attach the steps to create the error.  You raise the ticket to highest priority level you can.  You submit it back to the vendor.

Time goes by.

People in the company, including your boss, start asking: “Hey, when is that problem going to get fixed, people are complaining.” or “customers are getting irritated” or “we are starting to experience high call center call volume related to this problem.” Or whatever constitutes the inter-company fervor building to where you will soon be joining conference calls to explain what is going on and where things are at … rather than being allowed to actually fix the problem.

In anticipation of that first “please join the problem resolution conference line” alter, you re-check your ticket status online and see:

“Ticket Status = Pending”

… and nothing else.

Your world is about to get even more unpleasant as you see you’re frustrated and exhausted boss heading to your cube.

Wouldn’t it be great to have some human at the vendor to reach out to who is motivated to keep your company happily paying the monthly maintenance fees to help cut through the bureaucracy and get your technical peer at the vendor working on a fix for this problem?  Someone who can find that singular vendor engineer, that upon seeing your configuration can immediately go:

“Geez, they are running on OS 34 in 61-bit mode?  They need to add the ‘no cache during day light savings time=yes’ setting to their config file or else they will throw error 57 every time someone presses the ‘Q’ then ‘k’ keys.”

Here is where having the contact info for the Vendor Sales Cheese handy and having had that five minute conversation not too long ago with the Vendor Sales Cheese pays big tactical dividends.

Bob the Engineer: “Hey Vendor Sales Cheese, it is Bob at ABC Company.  Hey, I am getting the run around on support ticket <blah>.  I did everyone as instructed but we are still getting errors from FlimFlam.  A whole bunch of managers are going to get together and start talking about this problem with FlimFlam which means they are probably going to call you at some point if this problem doesn’t get resolved.  What do you need from me to get a senior tech guy to call me ASAP to avoid this pending mess?”  (Note the clever use of language to make your problem the Vendor Sales Cheese’s problem as well.)

The Vendor Sales Cheese doesn’t want to spend time putting out a fire at a customer’s site due to his product or service.  He or she wants to out selling their product or service to a new customer.  Plus, the Vendor Sales Cheese knows you from that fire minute conversation at which they “Check!” linked you to the top tech guy who knows his stuff and only needs help when something is going horribly, horribly wrong at ABC Compnay.  The Vendor Sales Cheese starts lighting fires within his company for get their FlimFlam tech expert on your phone ASAP.

That five minute awkward conversation with the Vendor Sales Cheese pays off big time when that FlimFlam senior tech guy or gal calls you with the magic config file setting that makes the whole problem go away.  And equally important, stops you from having to join the company trouble call and spend countless hours trying to explain to a conference call full of managers.

IT Manager Dividends

Ok, I see the value to the IT engineer, but what about the IT manager?   I’ll dive into this value proposition in the next article with more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.

Ever work on a strong team?

Do you or have you ever had the opportunity to work on a strong team at any point in your professional career?  A team where everyone has a collective sense of being part of something bigger than themselves?  Everyone had a role on the team that wasn’t defined by a Human Resources job description, but rather, a combination of skill set strengths and work task preferences aligned ultimately with what needed to get accomplished?  A team where, as work came in, everyone volunteered to own tasks and everyone else lined up to provide support and assistance?  A team where everyone knew the strengths and weaknesses of each team member plus everyone could count on each other to get the job done?  If you have, your mind is probably getting flooded with random memories of events and situations of that team environment.  Do affirmative answers to these questions actually define what a strong team means to you?

Strong Team = A team where everyone has a collective sense of being part of something bigger than themselves?

According to research by Amy Wrzesniewski, as reported in 12: The Elements of Great Managing (Wagner and Harter, Gallup Press, 2006), people want to work for an organization with a higher purpose or a mission that means something to them.  I believe the same holds true for a team within an organization.  If a team has each team member working on separate tasks that don’t come back to a common thematic service offering, it is difficult for each team member to get a sense they work for a team with a higher purpose.  Without an opportunity to share related successes and failures and generally kvetch or vent about stressful situations that each team member can identify with, the people on the team won’t have a strong sense of team.  If common exchanges like below aren’t occurring, there doesn’t exist that sense everyone is working for a higher purpose:

Bob: “Hey, working with Larry in Accounting is really a challenge.”

Sally: “Yah, I know.  I dread getting requests from him.”

Bob: “What is his deal anyway?”

Sue: “You guys talking about Larry in Account?”

Bob and Sally: “Yes”

Sue: “Oh, he is easy to work with.”

Bob: “How so?”

Sue: “He just gets very nervous when his PC doesn’t work exactly the same each time.  If you move his icons around or patches or updates cause his PC to work just slightly differently, look out, he is going to freak.  Just let him know nothing is going to change and fix whatever he needs and you will be fine.”

Bob: “Great, I’ll give that a try!”

Strong Team = Everyone had a role on the team that wasn’t defined by a Human Resources job description, but rather, a combination of skill set strengths, work task preferences aligned ultimately with what needs to get accomplished?

Bob might be interested in how the system works together as a whole, and thus engages on tasks that are architecture in nature or involve major system upgrades.  Sally might be a bit intimidated or uncomfortable interacting directly with people outside the team but favors highly detailed technical tasks and thus gravitates towards tasks that fit this description.  Joe might be losing his zeal for highly technical tasks and would rather interact with people to establish the more detailed requirements on what needs to be accomplished and thus provide specifications to Sally.  Sue might be a bit junior and thus gravitates towards the more mundane, repetitive tasks that increases her confidence in her abilities but everyone else see as low challenge work.  Yet, on the HR side, everyone is either a “Systems Engineer I” or “Systems Engineer II”.

Strong Team = A team where, as work came in, everyone volunteered to own tasks and everyone else lined up to provide support and assistance?

Building on that sense of everyone working for something bigger than themselves comes the way incoming work is divvied up amongst the team members.  A sure sign of a weak team is when the team lead or manager has to monitor all in coming work requests, specifically assign out tasks with exhaustive granular detail and follow-up with status meetings and the always dreaded status reports.  At the opposite end of the spectrum is the strong team were as work comes in, everyone assimilates the work without having to wait for their assignments.  Instead of the manager or team leader acting as a task master, instead, they provide guidance as to how to handle competing priorities as well as context behind requests.  This team dynamic involves each team member being aware of their implicit role within the team as well as the strengths, weaknesses and interests of all other team members rather than:

Systems Engineer II: “This work should be assigned to a ‘Systems Engineer I’ and I’ll go back to my desk and surf the web till something fitting my job description comes in.”

Junior resources know the typical IT technical hierarchy where “senior” resources became senior resources by having tenure defined by having rolled up sleeves and made things work to the state the system or service is in at present.  Junior resources know they have to respect this effort and accept more junior tasks until one can grow into a senior resource.  Senior resources know they were once junior at some point and thus are open to assisting fellow teammates.  Junior resources know they need senior resource to help them get their work done; yet, they respect senior resources time and workload and thus only engage after trying all avenues on their own first.  All these combine into a natural divvying up of in coming work requests favoring each person’s unique skill set and interest yet with everyone mindful all the work has to get done on schedule.

How do you know if you are on a strong team?

Simple … you can cite current and frequent examples from your day to day work that align with the elements above.

How does one go about creating a strong team?

Look for part 2 to share some thoughts on how to go about creating a strong team.

Some find having to go to work every day … day in and day out … to be a drag, but if you have ever worked on a strong team, you know that that drag isn’t so bad because you have peers around you with a sense of team work that has everyone pitching in to do quality work with a strong sense of pride.

Anyone have any other examples they can share that captures the elements of working on a strong team?

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

• Role of the Sales Rep

You want to get to know the shinny suit

In the previous article, I concluded thoughts on vendor service integration challenges.  I made a cavalier reference to the “Vendor Sales Cheese” role.  This article will explore this role more deeply and how, as an IT manager in a MidWestern company, you need to partner with this role to be successful in delivering you and your team’s services to the company.

I don’t think there are more diametrically opposed roles in business than the IT engineer and the IT vendor sales representative.  One of the best descriptions of the complex persona that is the IT engineer is The Nerd Handbook.    IT engineers look at the world as an ever unfolding flow chart of logical constructs built on top of more logical constructs.  They are constantly learning and building.  They prioritize human interactions based on a peer level of technical appreciation and comprehension.  If someone isn’t at their level of knowledge on the subject at hand, the value of the exchange diminishes rapidly in their mind.  On the other hand, the Vendor Sales Representative or as I’ve affectionately relabeled as “Vendor Sales Cheese”, as viewed through the IT engineer lens, couldn’t be worth even a nod in the conversation spectrum.  If you align yourself more with the IT engineering mindset, I bet you are getting ready to HTTP 302 yourself off this article and on to something more technical.  I beg you to continue reading in the hopes I can influence you to consider a logical argument for the value of the Vendor Sales Cheese in your technical and/or management function.

So, as a typical IT engineer or engineering manager, your initial interactions with the Vendor Sales Cheese have you thinking: “This person is way too positive and friendly.  That sure is a slick and way too shinny suit.  I need to get outta this conversation and back to my keyboard ASAP.”  Yes, the Vendor Sales Cheese meets new people every fifteen minutes of every day.  Those people could be the tier one HelpDesk technician or the president of the company.  Hence, they error on the side of potentially meeting the president and bust out the shinny suit.  In meeting people, they need to quickly determine your role in the customer vendor relationship ASAP since there is going to be someone new to meet in another fifteen minutes.  Thoughts going through the Vendor Sales Cheese’s mind:

• How do you align in the organization against the product or service the Vendor Sales Cheese represents?
• Are you an end user that is going to be a source of complaints?
• Are you a decision influencer that won’t make the final purchase decision but could influence the decision maker and possibly tank the deal?
• Or are you’re the golden role, the decision maker that is the person between the Vendor Sales Cheese and closing the deal to get the big compensation bonus?

The Vendor Sales Cheese is trying to determine this as quickly as possible in the limited interaction time they are given.

Sure, you can return to the safety of your keyboard and the logical and controlled in order to avoid the seemingly unpleasant and awkward conversation.  But is another five minutes of conversation really going to kill you?  My recommendation is make this five minutes tactically productive by immediately describing your role within the organization and how it aligns with the product or service the Vendor Sales Cheese represents:

IT Engineer: “Hi, I’m Bob and I am the lead engineer in ABC Company that has the job of taking your FlimFlam software product and cramming it into our enterprise IT environment.  I can’t sign a PO and can’t buy anything.  But, when there is a tough problem with the FlimFlam software here, I get the call.  I’ve been working with it for X years.  So when I need tech support, I don’t need the 1-800 number level 1 tech.  I need access to the guy who, like me, knows how FlimFlam works inside and out.  How do I get that tech access so I don’t waste your company’s time?”  (Note the clever use of language to suck the “vsc” into the need to solve a problem for his company and help a customer at the same time.  How can the “vsc” resist this?)

IT Manager: “Hi, I’m Sally and I am the manager over the team that integrates your FlimFlam software with the rest of the technology here at ABC Company.  Let me start with the fact that I am not the guy that signs the PO, but I have the Director’s ear does.  We’ve had great success with FlimFlam but we know there is plenty of competition in this product space.  My biggest challenge with your company is X.  What is the best way to improve the X situation?”  (Again, sucking the “vsc” in by creating a scenario he/she can’t possibly walk away from since they are ever so relationship positive focused)

For the IT engineer, you have given the Vendor Sales Cheese exactly what they need to know:

• Bob = tech guy at ABC Company that can sing the praises of FlimFlam or make a lot of noise when we drop the ball failing to supporting his priority support needs.  Check.

For the IT manager, the Vendor Sales Cheese knows:

• Sally = manager at ABC Company that shouldn’t get the loge tickets to Sunday’s game at the stadium, but he needs some above average attention because she could tank the current/next deal by pitching to the VP/Director/Other that another company with a competing product could be integrated quicker/faster/cheaper is giving her more respect and support.  Check.

Ok, you are scratching your head … “ok, I see how the stage has been set for some tactical value from this Vendor Sales Cheese exchange, but what does this really do for me?  Doesn’t this just lead to more annoying conversation?”  I’ll dive into this value proposition in the next article with more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.

Does the MidWest really need recruiting "want"?

For his first post of 2010, Rands shares his perspective on the need for ensuring the recruiting process carries the theme of making the desired candidates feel wanted, both from the company recruiter as well as the hiring manager. The article is well written as we have all come to expect from Rands in taking the example of a candidate, Jesse, who has accepted a position extended by Rands but at the final hour, declines the offer to stay with Jesse’s current employer. Rands’s conclusion is that Jesse wasn’t made to feel “wanted” enough to leave his current employer.

As I read the article, I reflected on my almost 20 years of IT experience in the MidWest and I could appreciate Rands’s supposition of “wanted-ness” driving employee employer alignment, but I could not find any parallel experiences in my past nor any stories from peers that could mirror this “wanted-ness”. So, I got to thinking:

“It seems difficult to refute “wanted-ness” as solid goal for all IT organizations regardless of geographic predilection. What might make it less of a priority for a MidWestern company to employ such talent attraction tactics as Rands supposes? ”

This first thing that comes to my mind is the labor pool. If you are working in a labor market that favors MidWestern companies as I’ve attempted to define them in this blog, your labor pool maybe heavily impacted by some/all of the following:

• Aging work force
• Younger work force moving out of the area
• The “brain drain” or local college grads leaving the area upon graduation
• Buy instead of Build IT mentality

NPR has a good article on the perspective of the “brain drain” on the MidWest labor market here if you haven’t been exposed to this concept prior.

Thus, if the labor pool is known to be composed of relatively few super starts in any given category, do MidWestern IT organizations need to go to great lengths to offer rock star recruiting techniques or put energy into creating a high degree of “wanted-ness”? I think the answer is: not really.

But wait you might say, doesn’t Economics 101 say if the supply is trending low, and demand is trending high (you need to hire someone = trending high), then MidWestern companies should be investing heavily in “wanted-ness” to attract top IT talent to meet demand?

Here is where I offer that the “Buy instead of Build IT mentality” drives the demand curve back down. If an IT organization is conducting significantly more “buy” activities than “build” activities, the labor demand is less for that rock star engineer, but rather, an engineer that can work with the vendor’s organization to integrate the vendor’s technology into the company’s existing technology. Thus, a rock star engineer, who wants to be building not integrating, who is offered a highly generous compensation package along with “want”, would be easily disappointed and look for a more pro-build opportunity in short order. So again, the economics coupled with the “Buy” emphasis drives down the demand curve so it is more inline with the labor pool supply curve.

With the demand curve inline with the supply curve and the overall “rock star engineer” need being eclipsed by the value proposition provided by the “Buy” vendor equals a strong excuse for a MidWestern company to skip going above and beyond to create a sense of “wanted-ness” for ultimately more average hires.

The second thing that comes to mind is the labor market itself. In my opinion and from the limited researched I was able to conduct, the decade of the 90s drove up the demand for IT resources in the MidWest. The dot-com bubble bursting in the 00s took the MidWest IT labor market backwards significantly without a subsequent major recovery. To put that perspective to numbers, from a report from the Center for Urban Economic Development, University of Illinois at Chicago, the below graph shows the year over year change in IT industry employment across the entire US:

Breaking this data down more regionally and comparing the major MidWest city of Chicago, IL to other non-MidWest major cities such as Dallas, Boston and San Francisco for their 1999-2005 IT industry employment shows all non-MidWest markets seeing greater net job increases for the period compared to Chicago.

Even less scientific, a recent same day search of Monster.com, Inc. for “Information Technology” jobs using the default search settings for the following cities reflected a similar perspective: major cities outside the MidWest tend to have at least four times as many job postings as MidWest cities.

Cities from CUED list above:

Chicago, IL 628
Boston, MA 831
Dallas, TX 582
Los Angeles, CA 623
San Francisco, CA 455
San Jose, CA 407
Seattle, WA 406
Washington, DC 2110

Other Cities:

Atlanta, GA 608
Cleveland, OH 127
Cincinnati, OH 132
Detroit, MI 183
Saint Louis, MO 218

With MidWest IT needs being significantly less aggressive than higher IT resource demanding areas such as from the coasts, do MidWest IT Organizations really need to invest heavily in the “want”? My opinion with this data suggests no, this isn’t a priority compared to other regions of the US.

Ok, what is the point of all this? My analysis suggests:

Although Rands makes a compelling argument for the value of ensuring the “want” is pervasive throughout the recruiting/hiring process, that value is significantly impacted by the region of the US. Specifically, that value is significantly decreased in the MidWest where the labor pool in conjunction with the labor market suggest fewer and fewer qualified resources are competing for fewer and fewer jobs. Although somewhat cavalier to title this article “Not Wanted” when indeed, a job opening by definition means “want” to some degree; the need for a MidWestern IT organization to go to great lengths to create a culture of “want” in the hiring and recruiting process seems to be unneeded.

Anyone see a glaring oversight in this analysis? Anyone have a compelling argument that suggests another perspective increases the “want” value in the MidWest IT recruiting process?

Integration going South? Time to call the Vendor Sales Cheese!

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company.  This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

1. Vendor Service Integration Challenges

In the previous article, I suggested some approaches to consider as the project is underway to integrate the vendor’s service with you and your team’s technology service.  This article will explore considerations once you are in the throws of integration.

So, you have your prototyping working to reduce the unknowns associated with how to get the two disparate technologies functionally working together.  You also have your “spaghetti infrastructure” in place to reduce the risk of negative impacts to your service’s ability to continue to perform for existing needs as well as supporting the new vendor integration.  Finally, you have your “vendor simulator” setup to conduct various permutations of performance testing scenarios between you and your team’s service and the vendor’s service.  So what else do you need?

In parallel to all of the above rather technical risk mitigation techniques, you need an additional management tool to address adverse scenarios that will inevitably pop up randomly throughout the integration project.  The tool I am referring to is a thorough understanding of the vendor’s organizational chart.  Specifically, you are looking to identify the following roles within the vendor’s organization:

• Relationship Manager assigned to your company

This is the individual whose job it is to ensure that your company is happy at all times with the service the vendor is providing to your company.  This is an individual who you can leverage any time you believe additional support from the vendor would allow for accomplishing things more efficiently and effectively.  If things are trending poorly and you have exhausted the contacts and procedures to get support from the vendor, don’t hesitate to contact this individual.  They should react immediately to your needs, especially if you can summarize your thorough attempt to use the normal channels and your coming up proverbially empty.  On word of caution, make sure you exhaust the established parameters for vendor resource and assistance engagement.  If you call on this person at every bump in the road, you may get high touch service immediately, but you will quickly be labeled as a “hyper escalator” and your high priority requests will be interpreted as low priority.  This is indeed a balance, for if you don’t leverage this individual and things come to a head down the road, the vendor has an easy out for providing poor service:

Vendor Sales Cheese <role defined later in this article>: “I understand you are frustrated.  You do know you can contact Bob for all your customer service needs.  He is your Relationship Manager dedicated to you and from what I understand; no one reached out to Bob.  If you do contact Bob, he will make sure you are getting the needed service and support from our organization …”

Regardless of your level of credible frustration, you didn’t take advantage of the escalatory options at your disposal from the vendor:

• Senior Technical Person

This is the role you need to find quickly.  The vendor will most likely try to shield this person.  Why shield?  Well, if every customer knew how to get a hold of Senior Technical Person, they would for their every need because they get the real, direct and reliable technical answer quickly.  But like every technical organization, these roles are few and far between and worth protecting so only the most critical problems get into their hands.  This being said, you need to quickly identify this person and establish a back channel communications mechanism between your senior tech person and the vendor senior tech person.  Similar to the Relationship Manager role, this is a “don’t use unless you absolutely have too” communications route.  Make sure you coach your senior tech resource to play along with only contacting their peer at the vendor when the regular channels breakdown.  On the flip side, the vendor senior technical resource will appreciate being able to speak with a technical peer within the customer’s organization.  Just like your senior tech resource, the vendor’s equivalent will be frustrated with the problems that are beneath them to solve crossing their desk.  They will find it refreshing to speak with someone who shares their priority attributed to technical excellence and will provide top notch support when engaged as such.  This back channel communication mechanism can be exceedingly valuable when milestone dates are looming and confounding technical problems block forward progress.

• Vendor Project Manager

Assuming the integration effort is of a scale that involves more than a few humans completing a few tasks to integrate technologies, there will most likely be a project manager within your organization (see other series of articles on interacting within your project management framework for IT Engineers and IT Managers ).  On the vendor side, they will most likely have a Vendor Project Manager role. This role keeps the vendor resource moving forward within the vendor’s organization in parallel with your organization’s project manager.  Don’t be quick to conclude that your company’s project manager will work effectively with their peer within the vendor’s organization.  It is best to assume your project manager will fail to grasp the nuances of the technical tasks and dependencies and thus fail to get critical information passed back and forth between the two organizations successfully.  I am not suggesting you need to absorb the project management function within yourself or your team, rather, develop a communication approach that takes this miscommunication potential into account.  For example, consider adding the Vendor Project Manager as a carbon copy to all emails that make even the slightest reference to questions, answers, tasks or dependencies that involve the vendor.  For example, pass on mentioning that Bob on your team needs to take the internal account access form to the access granters for Bob to get access to that new server he doesn’t have access to yet.  This doesn’t involve the vendor in the slightest.  But, if the vendor is expecting a copy of the contents of a configuration file on that new server, then by all means add the Vendor Project Manager to the cc line of the email to your company’s project manager.  Why this seemingly superfluous communication of ancillary internal access granting minutia?  The perception becomes more clear that the vendor is waiting on the configuration file snapshot, which your team needs to provide, yet clearly can’t until access is granted to Bob.  Without this documented clarity, the Vendor Project Manager can send a heated email to your project manager claiming your company is holding up the project due to not providing the configuration file.  Your project manager, under duress, may be quick to claim you and your team are the hold up within your company.  Without this example email, you have to get on the defensive, especially to the classic “surprised and confused” response from the under duress project manager:

Company Project Manager: “What?  You needed server access in order to send over the configuration file that has been holding everyone up?  I’m surprised that you needed this access and I’m confused that you didn’t tell me about needing it.  For had I known you needed this access, I would have worked to get you that access ASAP.  Since I didn’t know about it, I couldn’t have known that this was a barrier to progress …”

The email including letting the Vendor Project Manager know all of the dependencies in order to provide the deliverable makes it obvious the communication breakdown is outside you and your team so you survive unscathed and don’t have to invest energy in forming a tactical defense or erect proverbial blame shields.

• Vendor Sales Cheese

Similar to the Relationship Manager role, you need to identify the Vendor Sales Cheese or salesperson that stands to loose big in the compensation category if the customer gets frustrated and doesn’t close the deal for him or her to score their bonus.  Depending on the vendor, the Vendor Sales Cheese or the Relationship Manager maybe the same person.  But in the event they are different people, make sure you have a clear understanding of their roles and follow the below sequence for every vendor request, only proceeding to the next step if the prior step failed to generate expected results:

1. Normal communication route (support ticket, email to vendor support mailbox, etc.) keeping the Vendor Project Manager copied on communications
2. Vendor Project Manager directly
3. Vendor Relationship Manager
4. Vendor Sales Cheese

Lastly, knowing who within your company owns the relationship with this vendor, as described in previous articles,  is also important so when you get a sense the communications are getting more heated as you are moving from the normal communication route, past the Vendor Project Manager over to the Vendor Relationship Manager and Vendor Sales Cheese, you can bring the vendor relationship owner into the mix when their vendor is at risk of causing the integration to go off track or miss a major project milestone.  If the integration project is trending in this direction, you will want to have all of the communications documented and reflecting a logical progression through the escalation path confirming to all that you and your team took every opportunity to engage the correct resources to not be the cause of the pending failure.

Knowing the contact information for all the vendor players identified in the roles above will allow you and your team to effectively manage the communications and escalatory options between your company and the vendor’s organization.  Relying on others puts you and your team at risk for being perceived as the service provider that is holding up the integration project and diverts focus from getting the technical integration completed.  The next article will dive deeper into more MidWestern IT perspectives on the topic of the “Role of the Sales Rep” in the spectrum of vendor management.