Midwest IT Survival

Respond ASAP!

Anyone that works in the Information Technology field knows that production technology systems, from time to time, will have problems.  From a functional defect that has everyone scratching their heads as to how it wasn’t discovered by seemingly endless rounds of QA* to full blown hardware failures that take down entire suites of applications, no matter how much is invested in “highly available” and “redundant” technologies, failures are bound to occur.  For IT Managers and IT Engineers, how one handles these failures from inception through service restoration and finally root cause analysis is critical.  Sure, the priority is to restore full service availability as soon as possible.  But, if you neglect some key technical support quality attributes in the process, which I’ll highlight in this series of articles, you may find you both succeeded and failed in restoring service at the same time.  Succeeded and failed at the same time you wonder?  Please read on and I will attempt to shed some light on this success with failure construct and considerations on how to avoid the failure “pitfalls”.

The First Pitfall = Responsiveness

The very first pitfall in providing any level of technical support to a production system is to fail to be responsive.  Imagine for a minute that you are a home owner and you don’t know the first thing about plumbing (and maybe you don’t know much about plumbing).  You turn on the facet expecting to feel some soothing hot water spray over your hands and yet, the water remains freezing cold.  You wait the typical number of seconds by when you would expect to at least sense the water turning from freezing cold to mildly tolerable; yet it isn’t happening.  You turn off the facet in disgust and trudge down to the basement to confront the source of pleasant, warm water: the hot water heater.  To your surprise, the hot water heater is where you expected it to be physically, but what you didn’t expect to discover is a steady stream of water pouring from underneath the unit and running a short length to your basement floor drain.  Since you don’t know the first thing about plumbing, your immediate and only thought is to call a plumber to come over as soon as possible.

Assume you have contact information for three plumbers in the area that you either have had satisfactory work completed prior or had reliable information from friends and neighbors that indicated they were prompt and reliable.  You hastily dial each plumber only to be greeted by pleasant yet unhelpful answering machines:

“… your call is very important to us.  Please leave a message and someone will be with you shortly <beep>”

You leave a hasty yet detailed message about the unnatural spring that has sprung forth from your hot water heater in the basement.  You provide a home phone, cell phone and your spouse/roommate/significant other’s contact information to ensure there are multiple ways your urgently needed plumber can contact you.

Minutes go by.

Hours go by.

Hours turn into days …

Okay, you get the picture.  What you and your lack of hot water disaster need is some initial response from a plumber.  Without any response of any kind, one can only plunge deeper and deeper into panic that you will forever by taking cold showers and personally draining the local fresh water lake via your leaking hot water heater.

I believe this analogy translates well to the notion of being responsive to production support issues.  Replace the panicked home owner with the leaking hot water heater and no response from any plumbers with an IT manager that is responsible for a technology service that is aware the technology is broke, but has no clue if/when it will be attended too by an engineer and you can image the panic the IT manager is feeling.

Thus, to not respond to a production support call or page promptly when the technology you are responsible for could be broken is liken to a previously reliable plumber never even returning your call about your broken hot water heater.

To Avoid the First Pitfall = Responsiveness = Respond in a Timely Fashion

Yes, this may seem ever so simple, but by responding to a call or page related to a production support issue in the expected manner will go an exceedingly long way to avoid the first pitfall and put the IT manager’s mind at ease.  Respond in the “expected manner”?  Yes, if the expectation is that you verbally answer a call or dial into a conference line or bridge to announce your availability or log into an automated support management system and perform some simple acknowledgement that you are aware your services are needed, and then do just that.  Nothing will be gained by sending an email to your manager when the clear expectation is you join a conference bridge line to be informed of the situation.  It may seem painful, irritating, not worth your energy, etc.  Allowing your immediate distaste for the production support situation that you are about to be drug into block you from “doing the right thing” well create the perception that you are not reliable and thus not a leader.  You don’t want those negative perceptions to be linked to your professional image, especially around raise and bonus time.  Plus, once you have been linked to those perceptions, it is going to take above and beyond effort for some time to reverse them.

Know the response expectations

As mentioned above, make sure you know what the response expectations are.  Make sure you have a clear understanding what the SLAs** are for the services for which you will be contacted.  If you have 30 minutes to respond, then make sure you make every effort to respond within that 30 minutes; sooner the better.  Are you supposed to respond via phone, email or join a conference line?  Make sure you are clear on what you are supposed to do.  Are you supposed to login to a problem management system and update the status on a support ticket?  Make sure you have confirmed you can do this remotely as well as in the office (assuming you are providing off hours support).  Know the customer SLAs for the service you are supporting.  If the service is available to customers 24/7 but the real customer service agreement is from 7am to 7pm, know that so if a call comes in before 7pm, be of the mindset that the system needs urgent attention until someone of authority indicates the problem can be handled the next day, not the other way around.  Are there priority levels assigned to the problems that get communicated out?  If so, make sure you know so that you are confident you can ignore a priority twelve problem till the next day, and so on.

Additionally, even though there are SLAs with different response times by priority, make every effort to understand what really constitutes a priority for the service rather than just arbitrary numbers.  Is there a particular “high value” customer or customer group that requires high touch service?  Is there a particular business function that is mission critical or if not completed successfully in a timely fashion, will create a rippling effect of additional problems within the support organization?  Develop a firm grasp of these unique support situations.  Even through they technically might not match the “priority 1 – entire system is down” criteria, they still are viewed by senior stakeholders as important to the business.  Hence, treating them as such will go along way to create the perception you care about your role, the company and have leadership potential.  Alternatively, think positive perception for raise and bonus time can’t be a bad thing.

Lastly, consider that response is just that: response.  Compare these two examples of responsiveness to the same problem:

Example A

Bob on his cell phone calling into the production situation conference line: “Hey, this Bob from FlimFlam support, I just got a text that there is a problem and to join this line.  How can I help?”

Voice on conference line: <Briefly explains that the production system is throwing error codes left and right and the system is essentially unusable>

Bob: “Hmm, I don’t know what could be causing that situation off the top of my head.  I am in the car and about 30 minutes away from being online to begin troubleshooting.  Is that problem?”

Example B

Bob, checking his cell phone for a text message to join a production situation conference line, thinks to himself: “I bet FlimFlam is throwing errors again.  I’ll get home, get online, see what might be going on and then join the conference line.”

In both examples, the time to resolve the production situation is probably the same.  I would actually argue that the time to restore service is probably quicker in option B than in A due to less communication and interaction time compared to hands on technical troubleshooting time.  But if it takes 60 minutes to restore service in example A compared to only 45 minutes in example B, the perception of the quality of technical support provided in example A is much higher than example B due to the higher level of communication and responsiveness involved in example A.  Back up to the leaking hot water heater example from the beginning of this article, that 30+ minute driving commute from receiving the text message to join the call to get engaged is similar to leaving a message for a plumber and not hearing back.  The perceived lack of responsiveness will work against any heroic technical feats of system restoration because those that don’t fully appreciate that you pulled off a systems miracle behind the scenes are only aware of the stress you caused them by not responding promptly to their communication needs first, technical second.

Look for additional articles to identify more technical support pitfalls and steps to take to avoid them.

* QA, Quality Assurance, the process or set of processes used to measure and assure the quality of a product.

*SLA, Service Level Agreement is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance.

Did you actually dance at your first school dance?

Jurgen Appelo recently posted his slides from the Scrum Gathering in Orlando entitled “The Dolt’s Guide To Self-Organization”.  I didn’t attend the conference, but in flipping through the slide deck, I was impressed by how much the concept of “self organizing teams” is a much better way to view the creation of a “Strong Team” as I tried to outline in a previous blog post .

I tried to capture in that previous post of mine a “hands off-ish” management style that fosters team members to step up and gravitate towards work they are interested in with the manager or team lead ensuring all the prioritized tasks needed are being handled by someone versus a more structured or top down task assignment approach.  Jurgen takes a different slant on a similar management style.  He starts with making the case that nature itself is self organizing rather than marching forward under the direction of a leader.  To further highlight this perspective, consider your first school dance or formal social gathering you attended.  Without activities directed by the school leadership, children tended to naturally separate into gender aligned groups.  Boys would be on one side of the gymnasium with girls on the other.  Then, within the gender groups, sub groups would form to further self organize along the common interests of sports, video games, comic books or other like enthusiasts.

In his presentation, Appelo suggests that “management” is not a direct natural extension of self organization, but exists none the less as a necessity.  Continuing the analogy above, the school dance needs chaperones.  How the chaperones interact or “manage” the students directly relates to how much fun the students have at the dance.  Mapping to managing an IT team or organization, how much micro versus macro management occurs relates to how much engagement and over all “value” is produced by the team or organization.  A high degree of micromanagement results in a low level of empowerment and thus a lower “value” produced by the team as a whole.  Flipping back to the School dance, if the chaperones are directing each student on what to do when on a seemingly constant basis, the kids in attendance are going to derive less fun or “value” from attending the dance.  Where as, if the chaperones are engaged in the dance event but allow the attendees the ability to interact on their own terms and only stepping in when a situation is trending negative (kids harassing or taunting others, kids on the verge of breaking out into a fight, etc.), the kids are in a better position to enjoy the dance.  The manger that is trying to constantly direct the team on a granular basis is going to reflect the over controlling chaperones at a school dance.  To sum up this notion of self-organization and how it fosters the empowerment to value equation, I discovered this quote from Majlinda Priku:

“People who actively participate in the workplace see greater skill development, and gain a greater understanding of which techniques are effective and which ones are not. They also have a greater opportunity to come up with creative solutions to problems, and novel ways to improve performance. The power to utilize their creativity and knowledge leads to expertise. People who are able to independently evaluate and implement projects have a sense of ownership that makes them committed to the project’s success.”  – Majlinda Priku, June 1, 2009,  http://www.articlesbase.com/leadership-articles/employee-empowerment-947535.html

Okay, so empowering employees through delegation to have more latitude to implement solutions to assignments sounds great, so how do you measure the level of empowerment and delegation currently in place within your team today to see where you stand?

Appelo has come up with an interesting way to represent this measurement as a sliding scale on slide 58:

Manager with authority in empowerment

Tell: make decision as the manager

Sell: convince people about decision

Consult: get input from team before decision

Join: make decision together with team

Advise: influence decision made by the team

Confirm: ask feedback after decision by team

Delegate: no influence, let team work it out

Employees with authority in empowerment

With “Tell” being the manager having the authority with little employee empowerment and “Delegate” being the employees having more authority and considerable empowerment.

I find this scalar approach to be extremely helpful as a way to reflect on recent decisions to measure the level of empowerment in place.  As an example, when I reflect on a high level of selling involved in getting a decision implemented, I wonder how I could have provided more information or context to the situation in order to move up the scale towards more employee “no brainer” decision acceptance.  I also find myself throughout the day moving up and down the scale for each unique situation that occurs.  By setting the goal of trying to be more closely aligned with the employees with authority in empowerment side of the scale in most situations, one can begin to determine where, on average, your team’s level of empowerment and delegation is at.  If you find yourself frequently telling or selling decisions, take a step back and try to determine what are the barriers to moving up the scale and take steps to change your approach to see if you can indeed move up the scale.  Take note of the techniques you employ that move towards employee empowerment.  You may find a pattern that the trend is positive for your team or a particular individual that you can continue to leverage going forward.

In summary, I find Appelo’s self organizing teams to indeed be a more natural way to capture how IT professionals work.  Keeping with that model, employee empowerment and delegation are a great way to look at how to build a strong team.  The authority in empowerment scale is a good tool to help measure the level of effective employee delegation that is taking place within your team.  By using the scale, one can identify where one finds oneself telling or selling.  This further enables one to try different approaches in future similar situations to see if one can move from telling and selling to advising, confirming and true delegation.

Get consensus or get lollipopped**?

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?

In the previous article, once you got past the mild disclaimer, the article dove into the first consideration of engaging your manager what will most likely be a series of discussions surrounding the autonomous decision making abilities extended to you and how much your manager is willing to support.  In this article, adding the considerations of engaging your peer managers and your direct reports in extending you decision latitude purview.

Consideration #2 = Peers, what decisions can and can’t you make?

Along the similar thought process of strategically asking your boss for decision latitude parameters, leverage you new job or role assignment to engage with peer managers for their feedback.  Consider the example decision latitude conversation starting questions below:

“Hey Bob, I’m new to Company X as the manager of the FlimFlam engineering team.  I heard you are the manager of the enterprise integration team.  At my last place, I had to get five signatures on a form and a stamp of approval from a review committee in order to get a decision on the name of a software component.  How does decision making for stuff like that happen here from your perspective?”

“Hey Sally, I think we met before.  You are in the customer service department as the shared services manager, right?  I used to be the support manager in the IT employee services department.  Due to the re-org, I am now the manager of the FlimFlam engineering team in the customer delivery department.  Where I came from, I had to get five signatures on a form and a stamp of approval from a review committee in order to get a decision on the name of a server.  How does decision making for stuff like that happen here from your perspective?”

By and large, people enjoy sharing their opinions.  Also, people generally respect and appreciate a well articulated question that appeals to their superior knowledge in their area of expertise.  Thus, another by product is a peer manager you may need to work with heavily in your new role will have a positive initial impression of you.  Additionally, you gain valuable insight into their personality, professional capability and leadership style that could be handy when the future need arises to interact with this individual in a potentially challenging situation.

Can they form a well thought out, intelligent response to your question?  Yes, they maybe worth spending more time with gaining knowledge about your new surroundings.  No, they maybe a low priority time investment going forward.  Do they immediately reveal they have an ego that indicates their cube might not be big enough for both you and their ego to fit comfortably?  Yes, and then file this away for a future encounter where an ego stroking communication style would benefit the next exchange.  Do they appear overwhelmed and oozing stress from every pore in their being?  Yes, then whatever feedback they provide might not be particularly valuable since they could very well be stressed due to ineffective decision making.

The topic of decision latitude is a great excuse to get some valuable interaction and intelligence from your peer managers.  One note, the above question and answer examples are just some thoughts to get your head thinking and not a direct mapping to a finite decision latitude specific determination.  Many other factors could be motivating an individual to respond to your initial queries a certain way such as an out side of work challenging situation.  Thus, the above suggestions are a means to get you thinking about starting dialogs with your peer managers to start to build a decision latitude framework that is ever evolving.

Consideration #3 = Ask your direct reports how decisions were made previously?

In the same thematic vein as interacting with your peer mangers, asking your new direct reports on how decisions were made prior to your arrival is another wealth of decision latitude information with a similar by product: ability to start building trust with team.

A fault of some IT engineers that get promoted into management or sometimes managers in general get a sense that because they are managers, they must make decisions because they are managers.  Be it ego or the power trip that comes with having influence over others, some managers tend to assume they know everything and thus must make all decisions without consulting anyone let alone their direct reports.  Nothing reduces engineering employee engagement and morale more than an engineering team that has a manager that is off making all kinds of crazy decisions without consulting his or her staff.  Time after time I’ve seen these individuals consistently get reorganized from team to team until they eventually get lolipopped** on the organization chart.  Does anyone want to take a guess on who disappears in the next round of staff reductions?

Using this situation to your advantage, a great way to start to establish a rap pour with your new team is to solicit their feedback on how their previous management made critical decisions.  They probably have a laundry list of past examples of good and bad scenarios.  What is the old adage?  Those that don’t learn from the past are doomed to repeat it from the Spanish philosopher George Santayana.  Your new team probably has some great stories where their previous management went off and made a crazy decision to do something and the corporate drama that ensued.  Take this opportunity to allow them to share the details of decisions gone haywire.  Plus, listen to how each contributes to the discussion.  Who is talking the most?  Who has the most passion in their description of past events?  Who zones out during the discussion and has nothing useful to contribute?  The conversation will give you clues to how your new position fits into the organization’s decision making process.  Additionally, you will be able to gather valuable insight into your new team and what makes up and novitiates each individual.

Wrap up

Finding yourself in a new leadership position within a different department within your current company or starting a brand new job, how an IT manager participates in the decision making process can easily map to a how stressful the job turns out to be.  Running around feeling compelled to make quick, off the cuff decisions in an organization that possesses a culture of methodically researched decisions is one way find your job stress going up.  On the contrary, a culture where an engineering team doesn’t use the restroom without consulting with management is going to take a different approach to go from day one decision making to day X where you ultimately desire the decision latitude to exist within your sphere of influence.  Using the newness of your role presents a great opportunity to consult with your manager, peer managers and you new team members to get some decision making parameters.  Additionally, you’ll have the side benefits of starting a valuable dialog with your new manager around how they expect your role to be successful.  You will also have the ability to get a feel for how your role was or is expected to function within your department’s peer management pool.  Finally, by tapping the past experiences around good and bad decisions that impacted your new direct reports, you will gain valuable insight into what worked and what didn’t work in the past.  You will also begin to establish a rap pour with your new as a manager willing to listen and understand rather than command and control out of the gate.  This process of understanding the decisions latitude at your prevue is on going.  You can expect the minute you get a sense of comfort that you have a good grasp of when you can just decide on the spot rather than form a committee to launch a research team, there will be a re-organization or an acquisition or some other corporate event that will throw the balance out of whack.  Keep expecting the variability to be the normal state and try a more scientific rather than trial and error approach to having a good sense of your decision latitude.

** “Lollipopped” slang for a senior position on an organizational chart that doesn’t have any direct reports when peers at the same level have staff and potentially additional management layers below them.

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.