MidWest IT Survival

Do I make the call solo or get consensus first?

From solving competing priorities that are affecting your resources to when to ratchet up the risk management opportunities on a high profile project that is approaching a critical deadline, as a MidWest IT manager, you are constantly forced to make decisions.  IT Engineers are also constantly making decisions, but the impact has a slightly more narrow focus where as, an IT Manager’s decisions have a much wider, more macro focus.  Plenty of the IT Manager’s job stress is directly related to having to constantly make decisions that have a macro as opposed to micro impact within the organization.  This article touches on some considerations for IT Managers to judge when one is solely empowered to make a decision compared to when it is more appropriate to solicit feedback from peers and senior management prior to making a decision in an effort to reduce that stress.  Or more simply, as the article is titled, an attempt to help you reach out to your peers, staff and management to answer the question of how much decision latitude does an IT Manager have within their organization?

[Mild disclaimer ahead]

Now I am not referring to straight forward decisions such as how often to schedule team meetings or how long before email responses would be considered tardy.  I’m referring to decisions that have a lasting or strategic impact.  Examples such as is it the right time to switch resellers or approval to kick off an expansive systems upgrade project or whether your team should provide an additional service that the organization is requesting that has new hardware, additional licensing and staff increase associated costs.  These are stress inducing examples.  Making say, a service extension decision autonomously, could land you in hot water when your boss finds out that, to be successful, you need more money and staff than the budget allows, yet the rest of the organization is moving forward assuming you are providing the new service.  Ever sit in an IT managers meeting with a cross department attendee list to sort out ownership of key services that need to come together to meet a new, high profile business need and watch a manager proverbially step right in front of a speeding bus by agreeing to provide a solution that everyone around the table knows they should have consulted their management prior to agreeing?  This sounds like the start of a series of high stress post meeting discussions.

Lastly, this article isn’t meant to be a step by step guide to stress reduction based on an all encompassing decision making strategy.  This article is more of series of considerations and possible approaches that might suggest a more structured approach to decision making rather than pure trial and error.

[End of mild disclaimer]

In my Internet wanderings, I came across this definition of decision latitude and its link to work stress:

“…the ability to make work-related decisions. When employees can make decisions related to the way they work, they are able to devise coping strategies than can mitigate the effects of stress” (Halpern, D.F., 159). *

Applying this perspective that how a MidWest IT Manager approaches the decision making process directly correlates to the amount of job stress experienced, one could simply extrapolate:

• Effective decision making, less stress
• Ineffective decision making, more stress

Note: I don’t think anyone could make the claim that effective decision making can eliminate all stress.  Rather, effective decision making can only reduce stress given some level of stress is involved in all decision making and as a manger; you are constantly put in a position to make decisions.  Ineffective decisions lead to an increase in problems or issues that force one to have to make even more decisions, thus repeating the cycle and in the process, bumping up the stress level each time.  Thus, if you find your job to be exceedingly stressful, have you stepped back and considered how effectively you are making decisions?

Consideration #1 = Boss, what can and can’t I decide?

The very first consideration is, for your role within your organization, what are you empowered to decide and what requires three committee reviews and seventeen signatures on a company form in order to decide?  Every company culture is different.  Plus, the larger the organization, the more cultural elements of the organization trickle down from division to department to group to team such that a role in one department might have a radically different tolerance for autonomous decision making compared to the same role in another department within the same company.  To make things even more challenging, with every reorganization or incremental leadership change at some higher level within the organization starts an eventual shift in the autonomous versus group decision making abilities.

So, how does one sort all this out within your organization?  Well, if anyone has a silver bullet answer for this one, I would appreciate hearing it.  In my experience, this is an ever evolving process of pro-actively seeking feedback coupled with reflection on the results of decisions made.  The most immediate source of proactive feedback is your direct manager.  If you are new to an organization or you find yourself suddenly reporting to a new manager, you may want to consider putting a high priority on this following example exchange within your first, formal one-on-one discussion:

You to your New Manager: “One topic I would like to cover is how you see this role empowered to make decisions within the purview of the team and the services it provides to the organization versus when I need your or others involvement.  As an example, in my prior role/organization/management relationship/etc., given a situation such as <insert example of recent past where you were completely empowered to make a decision without any additional peripheral involvement>, I was able to make decision X without having to involve anyone else and I knew I would have the support of my management.  In another example, < insert example of recent past where you had to involve your manager, peer managers, senior management, etc. prior to getting a decision made> I needed to directly involve my manager, peer managers and senior management in order to achieve a consensus on a decision.  Can you share your expectations on how much decision latitude you foresee my role having that you would support?  Follow up question, if a needed decision doesn’t fall within the parameters you see for this role, how best should I request your involvement in the decision making process?”

A couple nuances on this example exchange:

• Use of examples

If you asked directly what decisions you can and can’t make, you are likely to get an unhelpful response such as “I would expect you to make the decisions you feel necessary to get the job done” and then leaving your new boss with the impression you are somewhat weak since you had to ask such an open ended question.  By sighting examples on both ends of the decision spectrum and the circumstances that lead up to your autonomous or consensus based decision, you provide your new boss with context as to why you are asking the question.  The context created by the examples allows your new manager to consider your question within the realm of his or her leadership style.  Plus, you will gain valuable insight into your new manager’s priorities and approach to their role.  If your new manager suggests they need to be involved in every decision, you will get a clue they my have micromanagement tendencies or need to reach a level of trust before they are willing to allow you to function somewhat autonomously.  If your new manager suggests they don’t need to be involved at all on anything, you maybe getting clues you are reporting to an “arm chair” or “Monday morning” quarterback manager who will need to be drug into decisions that they would otherwise enjoy you make and then criticize later.

• “Decisions you would support” caveat

The value of adding this to the end of your big question is to get what you really need from your new manager.  Similar to clues you get from the context setting of your examples, what you are really looking for is your new manager to support your decisions not just allow you to make them.  Having this phrase at the end of your question emphasizes this critical component of your question.  You may want to consider the use body language and voice inflection to politely draw attention to these last few words so you ensure you have your managers focus on the words lest they are already formulating an answer based on your lead in statement to the question and examples.

• Follow up question on how best to engage your new boss

Equally critical is establishing some parameters around the best way to engage your new boss when they need to participate in making a decision.  Again, you gain value insight into your new boss’s leadership style based on the answer.  Equally important, as opposed to trial and error, you now have parameters by which you can engage your boss in decision making.  Thus, as a situation pops up that requires you to make a decision, if it in any way meets this parameter, your stress level doesn’t have to rise significantly.  Instead of stressing, start capturing the information needed and approach your boss as they outlined.  Fight the immediate reaction of making a decision on the spot.

• Potentially the greatest value = the exchange itself

Just by having this exchange, you begin the process of establishing a level of trust with your new manager.  They should begin to perceive you as one that values the reporting relationship as well as management pressures that exist at both your and your boss’s level.  They should observe that you value their reputation and role within the organization through establishing these operating parameters.  Just like you don’t appreciate having to navigate around a crazy decision made by one of your team members that puts you and your team in a bad place, your new boss does not look forward to having to respond to crazy decisions you make.

Finally, by having this exchange very early in the new reporting structure, you lay the ground work for on going dialog on the subject of management supported decision making until you reach that level of trust where the parameters and boundaries are firmly established.  Sure, you could learn these parameters and boundaries through trial and error, but why endure the stress and proverbial bruises when asking a strategic set of questions that could avoid the entire steaming pile of cow dung associated with making a call you shouldn’t have made on your own plus have the side benefit of building valuable trust.

In the second part to this topic, look for considerations around how to involve peer managers and direct reports in extending you decision latitude purview.

* Halpern, D.F. (2005). How time-flexible work policies can reduce stress, improve health, and save money. Stress and Health (21), 157-168.

Get sales to speed your support case to resolution

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 Category

• How to Leverage Tech Support

In the previous article, we looked at the importance of opening a vendor support case for technical issues and following the process to the letter to avoid process fumbling to reflect poorly on you and your team.  In this article, we look to engage the Vendor Sales Cheese when the vendor technical support case isn’t getting resolved effectively and how to turn this around to drive beneficial pricing.

Drag the Vendor Sales Cheese into the technical support problem

One thing a good Vendor Sales Cheese is effective at is getting folks within his or her organization to move quickly to close a sales deal.  Why not leverage that ability to your advantage to put more pressure on solving your technical support issue so you and your team can move on to more important work?

If you haven’t had your technical support case solve the problem, your technical support case probably looks something like this:

Day 1 = Your Team: problem reported, steps to re-create the problem shared, log files capturing the error shared.

Day 2 = Vendor: “Try changing setting <blah>.<blah>.<blah> from TRUE to FALSE and provide the log files if it doesn’t fix the problem.”

Day 2 = Your Team: Setting changed, problem still exists, support case updated, log files capturing the error shared.

Day 3 = Your Team: request status on case

Day 4 = Your Team: request status on case

Day 4 = Vendor: “Please download patch 3498345, apply and provide the log files if it doesn’t fix the problem.”

Day 4 = Your Team: Patch applied, service now crashes immediately upon starting, support case updated, log files capturing the error shared.

Day 6 = Your Team: request status on case

Day 7 = Your Team: request status on case

Day 8 = Vendor: “Please uninstall patch 3498345 and download patch 3498350, apply and provide the log files if it doesn’t fix the problem.”

Day 8 = Your Team: First patch removed, second patch installed, problem still exists, support case updated, log files capturing the error shared.

Day 9 = Your Team: request status on case

Day 10 = Your Team: request status on case

Day 11 = Vendor: “Please download patch 3498351, apply and provide the log files if it doesn’t fix the problem.”

Day 11 = Your Team: update the case with “we are not even running that version of your software on our technology platform as already indicated in the case and thus we cannot install that patch.  Now what?”

Day 12 = Your Team: request status on case

Clearly, you and your team are burning hours on this issue and not making much progress and worse, not getting quality service from the vendor without any real resolution in sight.  Time to get the Vendor Sales Cheese involved:

Boss: “Hey, Vendor Sales Cheese, it is Boss from ABC Company.  Can you take a look at support case number 596784 we just opened?  I think we are getting the run around after the case has been opened for 12 days.  Heck, the last entry from your support asks us to install a patch that doesn’t even match our technology platform which is clearly needed to open the case in the first place.”

Vendor Sales Cheese: “This doesn’t sound right.  Let me look into this right away and get back to you.”

Boss: “By the way, we need this issue fixed otherwise it is going to be brought up in our license renewal discussions next week/month.  I can’t believe it is time to talk about new licenses already.”

Vendor Sales Cheese: <with even more urgency> “Don’t worry; I’ll get to the bottom of this straight away.”

The key to this whole exchange is to link the need for this technical support case to be closed to the next sales opportunity.  Besides being in the Vendor Sales Cheese’s positive relationship interest, now, more importantly, it is a barrier to a sales interest.  You now have a highly motivated sales person to put pressure on the technical support arm of the vendor’s organization to clear through the process morass and get the problem resolved as quickly as possible.

Finally, how can consistent tracking of vendor technical support cases drive beneficial pricing?

By keeping an accurate track of each poorly handled support case and creating a plausible story that suggests a consistent struggle with the existing support arrangement can pay dividends.  Those dividends may not be in explicit price reductions, but thee could be.  Rather, you may find you have leverage to get an improved support arrangement for the same price.  The Vendor Sales Cheese may be able to add in something similar to:

• Ability to use a “priority code” to have your tickets skip the first level of support and go directly to a stronger second tier
• Ability to use an inside “customer advocate” that you can drag into cases the minute they start trending negative or as soon as you open the case and want to impress upon the vendor the urgency or severity of the issue and need for fast resolution
• Improved SLAs which actually improve your ability to get cases routed to experts rather than just artificial improvements such as “response time for a new case from 24 hours to 12 hours” which look good on paper but only provide case acknowledgement slightly sooner and no change to resolution expectations

Thus, not usually direct dollars off the top, the ability to negotiate an improved support arrangement without impacting the price ultimately benefits you, your team and your company with lower overhead involved in getting product technical issues resolved more quickly.

In addition to these perspectives on achieving beneficial pricing, can anyone share additional techniques to link poor technical support case experiences to squeeze out the best pricing scenarios for your company?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Product Versioning and the Upgrade Cycle” in the spectrum of vendor management.

How to get to the light at the end of the support case tunnel!

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 Category

• How to Leverage Tech Support

In the previous article, we looked at techniques such as “Good Cop”, “Bad Cop” to drive more beneficial pricing for your company.  In this article, we take yet another angle at the Vendor Management topic with a look at how to leverage the vendor’s technical support for results and pricing pressure.

Bob the Engineer: “Hey, we are getting the FlimFlam backend service throwing error 57’s again in production?  Anyone want to bet me the phones are going to start lighting up with everyone concerned about system stability?”

Joe the Engineer: “Can’t we just restart the service quickly?  No one would know.  We know the error will go away for awhile.  It is probably a memory leak of some kind.”

<ring, ring>

Sally the Engineer: “Too late, the panic is already starting.”

Boss: “Can I have a volunteer to capture those log files and open a case with FlimFlam tech support?”

Sure, the temptation is there to immediately restart the service and hope the problem goes away.  Sure, once you start down the path of resolving this annoying yet not life threatening problem you have to see it all the way to resolution otherwise you are even worse off.  Worse off in that you have lost the “surprised and confused” defense option (see previous article on this defensive topic).  You can’t be surprised by a system error that you already opened a ticket with the vendor’s technical support.  Thus, how can you leverage this support problem into a positive of service quality and vendor beneficial pricing?

First step, you have to open a support issue or ticket with the vendor through the vendor’s product technical support process.  Make sure you follow the process of entering a support issue into the vendor’s product technical support system to the letter.  The last thing you need when participating in a “root cause analysis” meeting is to have the vendor brought in to the fray only to cause grief with a procedural miss step such as:

Vendor Support Representative: “Why did it take us more than 24 hours to respond to your trouble ticket?  Let me see … ah, your company has an Yttrium Support Contract.  But, in order to get that fast response, you need to flag your ticket with your Yttrium Support Resource’s name ‘Bob’.  According to the ticket history, it never got assigned by your engineer to ‘Bob’ …”

As you probably can imagine, the vendor support engineers probably have all kinds of internal as well as external SLAs (service level agreements) and metrics to meet.  Thus, the vendor support representative that gets assigned your ticket is looking for the fastest way to change the status of the ticket to stop the clock on their metric and move the ticket to a status of “waiting on the customer”.  Thus, be prepared for typical responses such as “please provide current version and patch level by running the <blah> command” or “please provide a system log file and a screen shot of the error”.  You might as well coach your team to provide as much of this information up front when creating the ticket to reduce the back and forth delay between your team and the vendor in order to get the vendor working on the problem as quickly as possible.

Now, as painful as it might seem or as much of a waste of time as it might seem, if the vendor support rep wants additional log information or they want your team to try a patch or updated product or component version, you need to follow through.  Sure, your lead engineer knows that the problem doesn’t magically go away with the mythical vendor software patch, but you have to still go through the process, otherwise:

Vendor Support Representative: “You are still getting error 57?  Let me check your case … ah, I see we asked you to try applying patch number 39483 to your system because that fixes the problem.  Did you try that patch?”

Thus, in the root cause analysis process you will be at a disadvantage for not following through the technical support ticket process and battling back with “we know that patch won’t fix the problem because we know …” is a challenging argument to win against peers that have no first hand confidence in your lead engineer’s expert analysis.

By completing the vendor’s technical support process, you should be left with steps to take to eliminate “error 57” from ever interrupting your team’s work again and reducing your face time in the root cause analysis process.  But what if you are making no progress in resolving the issue?  Here is where the Vendor Sales Cheese can be exceedingly handy.

Drag the Vendor Sales Cheese into the technical support problem

In addition to these perspectives on the importance of leveraging the vendor’s technical support process, what other experiences have people had to suggest this arduous process is needed to deliver quality services back to your company?  Look for the next article to pick up where this article left off with the role the Vendor Sales Cheese can play in driving efficiency and how to turn this whole situation around to drive beneficial pricing.

Time for some Good Cop, Bad Cop to save some coin?

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 Category

• Sales Cycle and Pricing

In the previous article, we looked at some possible value of being direct and to the point with the caveats that one still needs to maintain an up to date relationship with your Vendor Sales Cheeses.  Some of that value being related to pricing which is where this article picks up the Vendor Management discussion.

There are a number of good sales cycle and pricing articles out there that help give some context as to how technology products are priced to the customer keeping the sales cycle in mind.  I recommend Joel Spolsky’s article “Camels and Rubber Duckies” or for a brief specific example, David Cummings’s article “Software Pricing Proportionate to Sales Cycle”.

How do these apply to the average MidWest company?  In my experience, the sales cycles are rather long in the average MidWest company.  The time it takes a vendor to go through the procurement process at an average MidWest company is exceedingly lengthy with all of the request for proposals and product demos upon product demos upon product demos.  Throw in some security reviews and contract language disputes and it could take months with no guarantee the company will actually buy the product.  All it takes is a re-organization of some key group or groups related to the vendor’s product during the procurement process and a whole new approach can be born that doesn’t involve the vendor’s product anymore.  Unless someone very high in the organization that is less likely to be significantly impacted by a re-organization is creating the urgency to get this vendor’s product in house and implemented, the more likely the sales cycle will be long and drawn out.

So, how does a manager of an engineering team within a large MidWest company have a positive affect on pricing for their company given this morass of process and bureaucracy?  The technique presented below suggests one can indeed have a positive impact on pricing even given the lengthy and arduous procurement process:

Traditional “Good Cop, Bad Cop”

One highly effective mechanism I’ve scene is when the manager of the engineering team comes across as the “Good Cop” and essentially the vendor advocate and their management fills the role of “Bad Cop”.  “Bad Cop” in the sense of giving every indication they don’t believe the vendor’s product is the right product for the company for some reason in addition to the product costing too much.  Maybe they give off every indication they have a preference for a competing product but you, as the engineering manager, really feel the vendor’s product is the right fit.  You and your management have concluded that the vendor’s product to be the right fit, but you agree to take this approach to motivate the vendor to provide additional incentives above and beyond the core product offering that will benefit the company and not destroy the profit margin the vendor is trying to achieve with the sale.  Maybe the vendor is willing to knock the price down even more than the “lowest possible” previously communicated price.  Maybe the vendor is willing to throw in two days of free on site training.  Maybe the vendor is willing to include additional licenses to products under the same maintenance cost structure.  Whatever the “maybe” might be, your roll in playing the “Good Cop” helps to give the vendor there is a high probability that the sale will complete, but it isn’t a done deal until something sways the “Bad Cop”.

Any side or longer term benefit to playing the “Good Cop” role?  Absolutely by being viewed by the vendor as a product advocate within the company.  This will significantly help you when you need to get timely technical support from the vendor as the Vendor Sales Cheese will link you and your role as “Good Cop” in helping him or her complete the sale and thus will work harder to get you the support from within the vendor that you will need down the road.  See this previous article [] for more details on how this need for technical support is critical and how the Vendor Sales Cheese plays an important role.

Another side benefit to appear as the vendor advocate within the company is access to early information on the vendor’s product roadmap as well as the ability to get customer feedback into that product roadmap process.  This doesn’t guarantee you will get that much needed feature into the vendor’s next release, but it sure increases your chances of getting more ear bending of the vendor’s product management that otherwise possible.

Is there anything else you can do to have a positive impact on the product pricing?

Remember the sales cycle from the last article?  Well, knowing the vendors quarter ends and most beneficial, year ends, target any budget license upgrade or renewal discussions around those important dates.  As an example: look to discuss yearly license purchases to coincide with the vendor’s year end if you represent a product that has a per user license.  The Vendor Sales Cheese will have the most leverage to come up with creative pricing prior to his or her year end compared to any other time of the year.  Couple your vendor year end license upgrade discussions with some “Good Cop” and “Bad Copy” technique and you can help drive some very beneficial pricing.

How about another take on driving beneficial pricing?

This can be a powerful one, thus use it sparingly, you may only get once chance to use this one.

Hint at pressure from somewhere in the organization that there is momentum building to replace the vendor’s product with the competition’s product.

Sales Training 101 says that it is way cheaper to keep an existing customer than it is to get a new customer to buy your product.  Thus, the Vendor Sales Cheese does not want to lose your business and can use the threat of potential loss to break the possible log jam within his or her sales organization to get rock bottom pricing.  Why is this only a one time technique?  After successfully using this technique to get super discounted pricing, coming back for a second round is likely to put you in the “our margin is now so slim, any lower and they might as well go switch to the competition … or they are out right fibbing” category and lose any credibility or priority attention points you have accumulated thus far.

By the way, this technique works even better if within your company, two competing products are being used.  It is completely plausible that a procurement group focusing on reducing the number of vendors to manage would have a business case to reduce the duplicity down to one vendor for a given service.  Thus, playing one vendor off of the other to see who is willing to really stretch their margins to keep your business can be extremely effective at maximizing the beneficial pricing.  As the perceived vendor advocate, you can even use the plausible angle of: “Hey, I need you guys to stay here otherwise why do I need to be employed anymore if the company goes with the other product” to support your claims for added plausibility.

In addition to these perspectives on achieving beneficial pricing, can anyone share additional techniques to squeeze out the best pricing scenarios for your company?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Leveraging Technical Support” in the spectrum of vendor management.

No such thing as a free lunch

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

• Sales Cycle and Pricing

In the previous article, we looked at the perspective that you are in no position/need/want to buy anything at this time yet the next sales cycle is rapidly approaching.  The following options were presented:

Option:

1. Answer the phone with: ”Go away, I’m busy.”
2. Everything goes to voicemail with no follow-up
3. Scam free lunch: “Sure, let’s go to lunch and talk about whatever and then I’ll mention I don’t/can’t buy anything.”
4. Direct and to the point: “Appreciate the call, but I’m not interested in anything at this time.”

We concluded that Option 1 and 2 hurt your ability to leverage the Vendor Sales Cheese’s assistance in the future when you might need quick access to senior, competent vendor technical resources due to the Vendor Sales Cheese placing a high value on people and relationships over logic.

Option 3 = Scam free lunch

Recommendation = avoid option 3 unless you have a high degree of confidence you will be buying something in the near future or have some useful customer information to share with the Vendor Sales Cheese

Sure, getting out of the office for a brief escape with all expenses paid by your Vendor Sales Cheese including the added sense of elevated importance as you are treated like a real customer sounds great; especially after being kicked around by the typical MidWestern IT political bureaucracy.  Part of the relationship maintenance burden that comes with being a Vendor Sales Cheese is to keep tabs on how their customers are doing.  Doing in the sense of looking for any opportunity to inject them selves into the pain reduction, “we have a solution for that problem”, drumming up another deal capacity.  Even if the Vendor Sales Cheese pitch is “hey, not looking to sell you anything.  I just want to get together and see how things are going …”, be prepared for the conversation to steer towards “the deal”.  You can’t fault the Vendor Sales Cheese; it is their job to bring in new sales.  But, you will quickly get labeled as “Bob, the free lunch guy” if you develop a pattern of getting together for the free lunch without having anything to offer the Vendor Sales Cheese in the meeting exchange.  As “Bob, the free lunch guy”, you will under mine your priority in the vendor’s mind as a strong customer resource and thus reducing the ability to reach out for extra technical help from the Vendor Sales Cheese when you critically need it.

Sure, a free lunch now and again isn’t going to solidify you as “Bob, the free lunch guy”; but make sure you have something useful for the Vendor Sales Cheese to bring with you to the lunch meeting.  What are some examples of something useful?  If you have knowledge of a current or pending re-organization plan, share the high level details that gives the Vendor Sales Cheese an up to date understanding of how the customer is positioning itself to leverage the vendor’s technology.  Note; don’t spill any specifics that you can’t share with anyone at the office or outside the office.  If you have knowledge of recently announced marketing plans that will drive up customer usage in a particular product that is leveraging the vendor’s technology, again, feel free to share the externally approved marketing details.  Get ready for the sales cycle discussion, especially if your licensing model is user count or user seat based.  Make sure you are clear to the Vendor Sales Cheese that these are marketing projections of increased sales and until the sales are real, no formal new licensing discussions can occur.  In this knowledge sharing example, you both win.  The Vendor Sales Cheese gets some positive news to take back to his sales management on potential future sales.  You legitimately have indicated the very plausible need for additional licenses in the near future if, indeed, the marketing projections turn out to be correct.  In short:

You = raise your level on the Vendor Sales Cheese’s priority list

Vendor Sales Cheese = useful information to take back to his sales management as well as a placeholder for possible future sales projection

Option 4 = Direct and to the point

Recommendation = Unless you have information that can directly translate into real, useful information for the Vendor Sales Cheese, this is your best option

I can’t count the number of times I’ve received positive feedback from Vendor Sales Cheese that  I’ve worked with over a good portion of time (multiple yearly sales cycles) that have shared with me their appreciation for the “direct and to the point” response to the “catch up” query.  The closer to the end of the sales cycle, the more pressure the Vendor Sales Cheese is under to bring in as many sales as possible.  Many have shared the frustration of thinking they have a lead and after investing a good amount of energy, get frustrated at seeing their investment disappear into a “Bob, the free lunch guy”.

So, you pass on the free lunch, you don’t waste the Vendor Sales Cheese’s time, so what else makes this a solid response?  In a word: respect.  Any strong, experienced Vendor Sales Cheese will recognize that you respect their role in the vendor management spectrum and will return the favor with equal respect.  They may offer some insight into what is driving the pricing constructs behind your next proposal or other bits of inside information for “the next deal”.  It may not be earth shatteringly helpful.  It may not be 40, 50, or 60% off the next order.  But, you will find your discussions and negotiations will be ever more direct, matter of fact and to the point rather than slick and filled with confusing sales speak.

Ok, respect the Vendor Sales Cheese role, how does this really factor into pricing in any way?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Sales Cycle and Pricing” in the spectrum of vendor management.

About time to get a call from your 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

• Sales Cycle and Pricing

In the previous article, we concluded the perspectives on the role of the sale representative closing with the IT manager dividends that get paid from the Vendor Sales Cheese’s retained earnings if you permit me to use a weak accounting balance sheet analogy.  We stopped short of how the Vendor Sales Cheese responds and reacts throughout the sales cycle and their role in pricing.  This article will dive into this aspect of Vendor Management.

Vendor Sales Cheese and the Sales Cycle

If you have had any Vendor Sales Cheese interaction, you’ve probably noticed a slight pattern to the timing of the communications.  Do you notice you get more email chatter and messages on your voicemail to “catch up” or “hey, how about we get together for lunch” around the end of the month?  How about the end of the quarter?  Ever wondered why there seems to be more artificial urgency at certain times compared to others?  This pattern of communication timing all resolves around the “sales cycle”.

When I refer to the sales cycle, what I mean is the periodic deadlines, created by the vendor, that establish when sales activities get measured.  If you are familiar with application development, it is a parallel to a code freeze.  A point in time when all the <sales> “hey, I almost have customer X signing on the dotted line to buy a 1,000 user license of product X” and <application development> “hey, I have just a few more lines of code to write and feature number 375 will be ready for testing” have to stop and be counted.  For the Vendor Sales Cheese, who is always working on “the deal”, there comes a point where if there isn’t something in writing confirming the sale will be made at a fixed date, the “the deal” doesn’t equal “a sale”.

Now, I have always been representing the customer in the vendor/customer side of “the deal”.  I would appreciate if someone who has been on the vendor side of the equation to provide more depth and support for what is going on over on the vendor side of the equation.

From what I have been able to determine from my customer perspective, these “sales freeze” occur primarily at the end of the quarter and then again at the end of the vendor company’s fiscal year.  Note, not every company has the same fiscal year end.  Year end being when a company says “my year is done as of X date, start closing the accounting books on the current year.  Now open new books for the next year”.  Thus we come for the first recommendation for this topic:

• For every vendor, establish when their “sales freezes” are as well as their fiscal year end.

Once established, you will pretty much be able to predict when you will get a phone call from the Vendor Sales Cheese from each vendor.  The calls will come in a week or so before the “sales freeze” date with some predictable push to try and determine if you are in any position to buy something the Vendor Sales Cheese is selling.  As the calls come in, and they will, you will most likely be in no position to buy something, but before you go about your daily routine, consider:

Perspective = You are in no position/need/want to buy anything at this time

You have absolutely no need or want or desire to buy anything from anyone at this time.  Thus, the Vendor Sales Cheese calls, which you know are going to start coming in from various vendors as a “sales freeze” approaches, can be handled in a variety of ways:

Option:

1. Answer the phone with: ”Go away, I’m busy.”
2. Everything goes to voicemail with no follow-up
3. Scam free lunch: “Sure, let’s go to lunch and talk about whatever and then I’ll mention I don’t/can’t buy anything.”
4. Direct and to the point: “Appreciate the call, but I’m not interested in anything at this time.”

Option 1 and 2 = “Go away, I’m busy.” + Everything goes to voicemail with no follow-up

Recommendation = don’t use option 1 or option2

Sure, this might be the first response that comes to ones mind that is full of more pressing day to day technical issues.  But, remember a few articles back where the Vendor Sales Cheese role was introduced.  Once you have purchased and integrated a vendor product or solution into you and your team’s service back to the business, you, whether you like it or not, have entered into a symbiotic relationship with the vendor to some degree.  As much as you may think: “hey, I can just toss out vendor X and get vendor Y’s solution in here tomorrow”, know it just isn’t that easy.  Swapping in vendor Y’s solution means going through the procurement process, pulling resources from in flight efforts to your replacement effort, getting people to test something that seems to be working already and ultimately implementing the new solution which just replaces what is already inexistence.  You know this pain.  The vendor knows you know this pain.  Depending on the depth of the vendor’s solution integration with your critical business functions, the higher the switching cost and the Vendor Sales Cheese knows this as well.

Potentially more important, when you run into a technical jam that your team can’t work around, you really need the vendor to provide some expertise.  You’ll need the Vendor Sales Cheese to pull the strings needed to get you quick, expert help.  Sure, you might think no matter how hard you beat up on the Vendor Sales Cheese every minute, they still have to drop everything and give you top service the next minute.  But consider that the Vendor Sales Cheese has a big custom list with varying revenue streams and technical competencies.  If you aren’t the top revenue stream with a potential for additional new sales volume within the next sales cycle, you may lose out to the customer that better fits that profile.  The Vendor Sales Cheese is going to put energy into the customer that provides them the most potential new sales opportunity.  Most likely, you are not constantly buying from this vendor, thus you won’t perpetually be within this high potential customer range continuously.  Constantly blowing off the Vendor Sales Cheese will put you far down in the list of customers worth putting any additional effort towards and could come back to bite you when you need the Vendor Sales Cheese to step up and help you out in the future.

Not convinced?  Consider how much sales is the juxtaposing of your highly technical world.  Your highly technical world is based on logic, binary systems connected to other binary systems with a guaranteed root cause to every problem if you just dig effectively.  “Sales” is completely people and relationship based.  People and relationships are the opposite of predictive and logical.  You are content with a system that handles spikes in transaction volumes across varying payloads with statistically insignificant changes in CPU utilization.  The Vendor Sales Cheese is content with a potential customer who has a strong need for a product or service the Vendor Sales Cheese is representing who has revealed his or her emotional hand that they are “sold” on the product or service to the point that they are putting pen to paper, signing a letter of intent to purchase.

So, more convinced Option 1 and 2 hurt your potential future needs from the Vendor Sales Cheese?  Which remaining option is best?  Look for the next article to pick up where this article left off with more MidWestern IT perspectives on the topic of the “Sales Cycle and Pricing” in the spectrum of vendor management.

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

Leverage your Vendor Sales Cheese to avoid the Architecture Astronauts!

In the previous article [], we explored how this role can benefit the IT engineer by cutting through the bologna that is the normal route to getting technical support from a vendor and putting one in direct contact with a peer senior technical resource that can solve tough problems quickly.  But what about the benefits to an IT manager?

IT Manager Dividends

Scenario 1 – You Don’t Have Bob the Engineer from the Previous Example

Well, let’s start with that same hypothetical problem scenario in the previous post [] with a production problem being reported in the service you and your team are responsible for, in this case the FlimFlam software.  You don’t have a Bob that has introduced himself to the Vendor Sales Cheese and established himself as the guy, that when he reports a problem with FlimFlam, there is indeed a problem with FlimFlam and Bob needs senior tech support ASAP.  It not, the Vendor Sales Cheese is going to spend his or her value time not selling but rather in fire suppression mode.

Once you notice your team is stuck in the troubleshooting process with the FlimFlam software and the trouble ticket that is open with the vendor is going no where, have your Vendor Sales Cheese contact info handy:

Sally the Manager: “Hey, Vendor Sales Cheese, it is Sally at ABC Company.  Well, no, everything isn’t quite fine.  We’ve got a problem.  FlimFlam is causing customer pain and is throwing an error 57 that no one, not even the tech folks behind your support web site are able to figure out.  You know I don’t waste your time with the trivial stuff, thus this isn’t trivial.  I am about to get on a conference call to explain to my peer management that we have our top engineers working on the problem but I don’t have a good answer when they ask what the vendor of FlimFlam is doing to aide us.  Yes, you can help, that is why I called.  Can you get a senior tech person to look at support ticket <blah> and then have that senior tech person call Joe on my team at <blah> to start resolving the issue?  I have your commitment someone is going to call Joe, right?  Good … now I have a much better story to tell everyone on the conference call.  I’ll be in touch.”

Similar to the previous example, you can leverage your relationship with the Vendor Sales Cheese to get priority service.  From a management perspective, you have just increased the technical capacity of your team without incurring any additional cost by leveraging the notion that the Vendor Sales Cheese would rather have a happy customer for which they can manage this problem more proactively since they were engaged early in the problem resolution process.  Any experienced Vendor Sales Cheese that been set on proverbial fire coming into a customer hot zone with threats of having the vendor and all provided products and services throw out because high level management had to get involved with a problem that, to them and rest of the organization, should never have occurred in the first place.  High level management sees the $$$ from their budget going to these monthly maintenance fees to their vendors as insurance that they will never have to directly deal with a problem caused by the vendor.  The Vendor Sales Cheese that can get engaged in a hot problem early, bring the right level of technical support and relationship support at the highest level and make the problem go away quick has actually earned positive face time with higher levels in the customer organization.  Their bet is the higher levels in the customer organization will see the support value in addition to product feature set from the vendor and look for that vendor to provide future solutions.

Thus, if the issue is heating up in your organization and you don’t have a Bob that has dragged the vendor into the troubleshooting mix, get on the phone to the Vendor Sales Cheese and give the Vendor Sales Cheese the opportunity to augment your team’s technical capacity as well as the opportunity to manage the customer relationship early rather then when asbestos underwear will be required later.

IT Manager Dividends

Scenario 2 – You Have Bob the Engineer

In this scenario, Bob on your team has already brought the vendor into the troubleshooting effort.  So, all you have to do is put your feet up on your desk and watch the magic happen as Bob and the senior vendor resource solve the issue before the day is over.  Well, you could, but what if it is 6PM and Bob and the vendor are stuck after hours of troubleshooting?  Once Bob has reached out to the Vendor Sales Cheese, wait a brief amount of time and then make a follow-up call yourself.  Let the Vendor Sales Cheese know that of all the problems you wrestle with every day, this one has your highest priority attention.  This further emphasizes to the Vendor Sales Cheese that this problem could become the problem that has the Vendor Sales Cheese sending $300+ an hour vendor solution architects to your company for free to appease the post resolution craziness that will surely develop if this problem isn’t given top priority and resolved in short order.

Sure, the Vendor Sales Cheese will quickly become high maintenance because they have had to work with customers in postmortems where a bunch of company architecture astronauts are swooping in after the system has been stabilized to philosophize on how a completely different solution that doesn’t even involve the vendor’s technology would be the best approach for senior management to implement to avoid this type of problem in the future.  The experienced Vendor Sales Cheese knows that once they are up against the customer’s architecture astronauts, the customer’s senior management has lost faith the vendor can save them from getting involved in distracting support issues.  Plus, senior management gets to throw out a vendor that failed and proceed to be courted by new vendors salivating at getting the opportunity to make the sale and have the “we replaced vendor X at company Y” story to enhance their sales pitches of the future.

Again, be prepared for the Vendor Sales Cheese to be high maintenance, but take comfort in the constant polling for status can easily be a positive when you need the vendor to jump higher and you already have the Vendor Sales Cheese with full issue context ready to say “how high?”

This concludes the perspectives on the role of the sale representative short of their role in the sales cycle and pricing.  I’ll dive into this aspect in the next article with more MidWestern IT perspectives on the topic of the “Sales Cycle and Pricing” in the spectrum of vendor management.

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?