Category: Building High Performance Teams

Key Steps to Building High Performance Teams

    Jim D

Today I have returned to a topic that is at the core of Recipes for IT: High Performance IT Teams. While tax day did take a bit of time and I am slightly delayed in posting this, I have actually laid out three accompanying posts or pages for today’s post. I think it is a good start on the complex topic of how to build or energize your team and create a high performing team. I look forward to your comments! Best, Jim

Building High Performance Teams: The essence of being a leader is defining a vision and compelling others to pursue and achieve that vision. Recently a good colleague relayed an article in Harvard Business Review describing how it is more difficult today to be a outstanding leader due to a number of factors including the wider availability of knowledge and easier access to each other as well as a reduced perception of glory of institutions that leaders represent.

And while I would agree these factors may make things more difficult to be a great leader, I tend to believe that we have just as many, if not more, good and decent men and women who are effective and even outstanding leaders today as ever in history. But because the circumstances are less dire (e.g., there is not a world war to require a Churchill) and because the competence has risen (yes, management is a far more analyzed and practiced field than ever before), there are not the towering gaps between the best and the average that might have previously been. So with a positive outlook on the competence of today’s managers and leaders, I have assembled a set of practices that I have leveraged or I have seen peers or other senior IT leaders use to build high performance IT teams.

For the emerging senior IT leader with his or her senior management team, can use these practices to build a high performing team, in the following steps:

Today’s post covers how to set such a vision, then define and cascade the goals to match your vision, align the incentives, and set the proper expectations and behaviors. And I have constructed pages with links above on the next three steps.  Subsequent posts will cover the remaining steps.

I think the aspiration of building a high performing team is a lofty, worthwhile, and achievable vision. If you have ever participated in a high performance team at the top of their game, in other words: a championship team, then you know the level of professional reward and sense of accomplishment that accompanies such membership. And for most companies that rely significantly on IT, if their IT team is a high performing team, it can make a very large difference in their products, their customer experience, and their bottom line. But if you are to set out to build such a team it must be for a vision that is more than just the team, it must be to enable your company to achieve achieve outsized goals of appropriate scale and aspiration. You will not attract or retain top talent and inspire others if you and your company have only modest goals.

So, first, consider your company’s goals and then outline what IT must become and must accomplish to enable corporate success of major significance. And the draw out the IT vision and goals that will enable that success. Do not get trapped by cloaking your vision in uninspired definitions (e.g., don’t state your vision as ‘ Save $40M in costs’ instead ‘ Become top quartile in efficiency in IT for our industry and company size by 201x’). You can only state your vision in this manner, of course, if you mean it. So, I will assume you have true aspirations for your team to become a world class IT organization and you will meld those goals with your company’s goals for a compelling vision. Further, consider IT goals to match both your company’s service and operations goals as well as product and innovation. Make sure the vision you define for IT drives both areas as well looking to a two to three year horizon for the target. (Rebuilding or energizing a team usually takes such a time period to truly reach high performance and you must lift the sight line to the horizon to ensure your team does not get trapped in just extending the every day steps.)

Once you have defined a compelling vision, the next step is to set the right goals to achieve the vision. The right goals will logically cascade as mileposts on the journey to high performance as well as be inevitable products of achieving corporate excellence. I recommend framing such goals as the primary measures by year that you will determine if you are to achieve the required progress to reach your vision. For the upcoming year, it is often worthwhile to set quarterly milestones as well. These measures should be relevant, well-defined, as quantifiable as possible and they should be set at stretch but achievable levels. If, for example, your vision is for your company to become an industry leader in service quality then you would want to set cascaded goals where the IT team dramatically improves its quality (so the systems now enable much better customer service for the company) as well as delivers key workflow improvements or feature enhancements to enable the company to lift its service directly (e.g., such as the package tracking capability that Federal Express uses to ensure extremely high quality service). Ensure that your measures are not uni-dimensional, that is, they only cover one aspect of what your company and thus your team must achieve. There should be clear focus in one area (e.g. quality and operational excellence, or product feature, or speed, or innovation) but it should not be a the full neglect of the other areas. Further, you should set at least modest goals for both cost and risk, otherwise these could become risk areas as your team pursues only one facet.

Once you have defined the right, cascading goals you will need to reinforce the goals with a set of behaviors and expectations as well as aligned incentives. And the approach to achieving the goals should reflect the strengths of the teamFor example, if one of your goals is to achieve outstanding quality then measures for the goals may include process definition work and metrics implementation if your team has low maturity or jump right to leveraging already reported metrics and driving improved feedback cycles if of high maturity. Further though, if your team has an engineering bias you may approach the solution through robust root cause and better design processes whereas if the team has a strong collaboration approach you may reach the same quality goal through better peer reviews and additional coordination and validation of changes.

More importantly though is to reinforce your goals through aligned behaviors and expectations and most importantly, incentives. For example, if you are looking to drive more predictable project delivery for the business than having incentives that reward firefighting for some of your staff when they contributed to the potential issues in the first place will tremendously undermine how much the rest of the staff support your goals. Similarly, if you reward those who while delivering a particular set of results cause significant damage to other team members or ignore other standards or principles, than you will minimize the likelihood that such principles or standards will be followed in the future. It is important, as a leader to reward not just factor in the results but more critically how the effort was achieved. Often in organizations, those who quietly and effectively carry out significant projects with excellent team behaviors are neglected by management when good leaders would call out the very same individuals for exemplary performance. Quite simply, your smartest team members, will observe what you reward, and if you do not reinforce the values you are looking to achieve (productivity, quality, initiative, etc), you will not get the changes desired.

Most importantly though, your behaviors as leaders must reflect the very same expectations you have outlined for your team. And you must demonstrate a tenacious focus on the goals and vision you have defined. Your behaviors must reinforce your expectations. Every day there are conflicts and setbacks that strong leaders would turn these into episodes that strengthen rather than weaken your team. Understand, that when you lead by example, you will make a daily difference and demonstrate to your team what should be done. Your focus, discipline, thoughtfulness, and sacrifice for the team and goals will not be lost and will result in better effort all around.

In sum, it is important to define a compelling vision and establish the right goals and incentives, but at each stage of the journey, there will be key moments where you as a leader will reinforce the vision, goals and principles you have set or you will undermine them. As a leader, perhaps we can easily step into the role of setting a direction, sponsoring a program or making  a major decision, but for all the visibility and importance of these actions, the time we spend interacting and communicating and coaching your team will determine the effectiveness and reach of our goals.

Now with the steps above you will have the foundation to build a high performance team and deliver sustainable and outstanding results.

What steps or approaches have you used to successfully define a vision and goals for a team? What would you change to this approach?

Best, Jim Ditmore

Evolving Metrics to Match Your Team’s Maturity

    Jim D

We have covered quite a bit of ground with previous posts on IT metrics but we have some important additions to the topic. The first, that we will cover today, is how to evolve your metrics to match your team’s maturity. (Next week, we will cover unit costs and allocations).

To ground our discussion, let’s first cover quickly the maturity levels of the team. Basing them heavily on the CMM, there are 5 levels:

  1. Ad hoc: A chaotic state with no established processes. Few measures are in place or accurate.
  2. Repeatable: The process is documented sufficiently and frequently used. Some measures are in place.
  3. Defined: Processes are defined and standard and highly adhered. Measures are routinely collected and analyzed.
  4. Managed: Processes are effectively controlled through the use of process metrics with some continuous process improvement (CPI).
  5. Optimized: Processes are optimized with statistical and CPI prevalent across all work.

It is important to match your IT metrics to the maturity of your team for several reasons:

  • capturing metrics which are beyond the team’s maturity level will be difficult to gather and likely lack accuracy
  • once gathered, there is potential for unreliable analysis and conclusions
  • and it will be unlikely that actions taken can result in sustained changes by the team
  • the difficulty and likely lack of progress and results can cause the team to negatively view any metrics or process improvement approach

Thus, before you start your team or organization on a metrics journey, ensure you understand their maturity so you can start the journey at the right place. If we take the primary activities of IT (production, projects, and routine services), you can map out the evolution of metrics by maturity as follows:

Production metrics – In moving from a low maturity environment to a high maturity, production metrics should evolve from typical inward-facing, component view measures of individual instances to customer view, service-oriented measures with both trend and pattern view as well and incident detail. Here is a detailed view:

Production Metrics Evolution

 

Project metrics – Measures in low maturity environments are project-centric usually focus on date and milestone with poor linkage to real work or quality. As the environment matures, more effective measures can be implemented that map actual work and quality as the work is being completed and provide accurate forecasts of project results. further, portfolio and program views and trends are available and leveraged.

Project Metrics Evolution

 

Routine Services – Low maturity measures are typically component or product-oriented at best within a strict SLA definition and lack a service view and customer satisfaction perspective. Higher maturity environments address these gaps and leverage unit costs, productivity, and unit quality within a context of business impact.

Routine Services Metrics Evolution

The general pattern is that as you move from low to medium and then to high maturity: you introduce process and service definition and accompanying metrics; you move from task or single project views to portfolio views; quality and value metrics are introduced and then exploited; and a customer or business value perspective becomes the prominent measure as to delivery success. Note that you cannot just jump to a high maturity approach as the level of discipline and understanding must be built over time with accumulating experience for the organization. To a degree, it is just like getting fit, you must go to the gym regularly and work hard – there is nothing in a bottle that will do it for you instead.

By matching the right level of metrics and proper next steps to your organization’s maturity, you will be rewarded with better delivery and higher quality, and your team will be able to progress and learn and leverage the next set of metrics. You will avoid a ‘bridge too far’ issue that often occurs when new leaders come into an organization that is less mature than their previous one, yet they impose the exact same regimen as they were familiar with previously. And then they fail to see why there are resultant problems and the blame either falls on the metrics framework imposed or the organization, when it is neither… it is the mismatch between the two.

And you will know your team has successfully completed their journey when they go from:

  • Production incidents to customer impact to ability to accurately forecast service quality
  • Production incidents to test defects to forecasted test defects to forecasted defects introduced to production
  • Unit counts of devices to package offerings to customer satisfaction
  • Unit counts or tasks to unit cost and performance measures to unit cost trajectories and performance trajectories

What has been your experience applying a metrics framework to a new organization? How have you adjusted it to ensure success with the new team?

Best, Jim Ditmore

Why you want an Australian Pilot: Lessons for Outstanding IT Leadership

    Jim D

Perhaps you are wondering what nationality or culture has to do with piloting an airplane? And how could piloting an airplane be similar to making decisions in an IT organization?

For those of you who have read Outliers, which I heartily recommend, you would be familiar with the well-supported conclusions that Malcolm Gladwell makes:

  • that incredible success often has strong parallels and patterns among those high achievers, often factors you would not expect or easily discern
  • and no one ever makes it alone

A very interesting chapter in Outliers is based on the NTSB analysis of what occurred in the cockpit during several crashes as well as the research work done by Dutch psychologist Geert Hofstede. What Hofstede found in his studies for IBM HR department in the 70s and 80s is that people from different countries or cultures behave differently in their work relationships. Not surprising of course, and Hofstede did not place countries as right or wrong but used the data as a way to measure differences in cultures. A very interesting measure of culture is the Power Distance Index (PDI). Countries with a high PDI have cultures where those in authority are treated with great respect and deference. For countries with a low PDI, those in authority go to great lengths to downplay their stature and members feel comfortable challenging authority.

Now back to having an Australian pilot your plane: commercial aircraft, while highly automated and extremely reliable, are complex machines that when in difficult circumstances, require all of the crew to do their job well and in concert. But for multiple crashes in the 1990s and early 2000s, the NTSB found that crew communication and coordination were significant factors. And those airlines with crews from countries with high PDI scores, had the worst records. Why? As Malcolm Gladwell lays out so well, it is because of the repeated deference of lower status crew members to a captain who is piloting the plane. And when the captain makes repeated mistakes, these crew members defer and do not call vigorously call out the issues when it is their responsibility to do so even to fatal effect. So, if you were flying a plane in the 1990s, you would want your pilot to be from Australia, New Zealand, Ireland, South Africa, or the US, as they have the lowest PDI cultural score. Since that time, it is worth noting that most airlines with high PDI ratings have incorporated crew responsibility training to overcome these effects and all airlines have added further crew training on communications and interaction resulting in the continued improvement in safety we witnessed this past decade.

But this experience yields insight into how teams operate effectively in complex environments. Simply put, the highest performance teams are those with a low PDI that enables team members to provide appropriate input into a decision. Further, once the leader decides, with this input, the team rotates quickly and with confidence to take on the new tack. Elite teams in our armed forces operate on very similar principles.

I would suggest that high performance IT teams operate in a low PDI manner as well. Delivering an IT system in today’s large corporations requires integrating a dozen or more technologies to deliver features that require multiple experts to fully comprehend. In contrast, if you have the project or organization driven by a leader whose authoritative style imposes high deference by all team members and alternative views cannot be expressed, than it is simply a matter of time before poor performance will set in. Strong team members and experts will look elsewhere for employment as their voices are not heard, and at some point, one person cannot be an expert in everything required to succeed and delivery failure will occur. High PDI leaders will not result in sustainable high performance teams.

Now a low PDI culture does not suggest there is not structure and authority. Nor is the team a democracy. Instead, each team member knows their area of responsibility and understands that in difficult and complex situations, all must work together with flexibility to come up with ideas and options for the group to consider for the solution. Each member views their area as a critical responsibility and strives to be the best at their competency in a disciplined approach. Leaders solicit data, recommended courses and ideas from team members, and consider them fully. Discussion and constructive debate, if possible given the time and the urgency, are encouraged. Leaders then make clear decisions, and once decided, everyone falls in line and provides full support and commitment.

In many respects, this is a similar profile to the Level 5 leader that Jim Collins wrote about that mixes ‘a paradoxical blend of personal humility and professional will. They feature a lack of pretense (low PDI) but fierce resolve to get things done for the benefit of their company. Their modesty allows them to be approachable and ensures that the facts and expert opinions are heard. Their focus and resolve enables them to make clear decisions. And their dedication to the company and the organizations ensure the company goals are foremost. (Of course, they also have all the other personal and management strengths and qualities (intelligence, integrity, work ethic, etc.).)

Low PDI or Level 5 leaders set in place three key approaches for their organizations:

  • they set in place a clear vision and build momentum with sustained focus and energy, motivating and leveraging the entire team
  • they do not lurch from initiative to initiative or jump on the latest technology bandwagon, instead they judiciously invest in key technologies and capabilities that are core to their company’s competence and value and provide sustainable advantage
  • because they drive a fact-based, disciplined approach to decisioning as leaders, excessive hierarchy and bureaucracy are not required. Further, quality and forethought are built in to processes freeing the organization of excessive controls and verification.

To achieve a high performance IT organization, these are the same leadership qualities required. Someone who storms around and makes all the key decisions without input from the team will not achieve a high performance organization nor will someone who focuses only on technology baubles and not on the underlying capabilities and disciplines. And someone who shrinks from key decisions and turf battles and does not sponsor his team will fail as well. We have all worked for bosses that reflected these qualities so we understand what happens and  why there is a lack of enthusiasm in those organizations.

So, instead, resolve to be a level 5 leader, and look to lower your PDI. Set a compelling vision, and every day seek out the facts, press your team to know their area of expertise as top in the industry, and sponsor the dialogue that enables the best decisions, and then make them.

Best, Jim

A Scientific Approach to IT Metrics

    Jim D

In order to achieve a world class or first quartile performance, it is critical to take a ‘scientific’ approach to IT metrics. Many shops remain rooted in ‘craft’ approaches to IT where techniques and processes are applied in an ad hoc manner to the work at hand and little is measured. Or, a smattering of process improvement methodologies (such as Six Sigma or Lean) or development approaches (e.g., Agile) are applied indiscriminately across the organization. Frequently then, due to a lack of success, the process methods or metrics focus are then tarred as being ineffective by managers.

Most organizations that I have seen that were mediocre performers typically have such craft or ad hoc approaches to their metrics and processes. And this includes not just the approach at the senior management level but at each of the 20 to 35 distinct functions that make up an IT shop (e.g., Networking, mainframes, servers, desktops, service desk, middleware , etc, and each business-focused area of development and integration). In fact, you must address the process and metrics at each distinct function level in order to then build a strong CIO level process, governance and metrics. And if you want to achieve 1st quartile or world-class performance, a scientific approach to metrics will make a major contribution. So let’s map out how to get to such an approach.

1) Evaluate your current metrics: You can pick several of the current functions you are responsible for and evaluate them to see where you are in your metrics approach and how to adjust to apply best practices. Take the following steps:

  • For each distinct function, identify the current metrics that are routinely used by the team to execute their work or make decisions.
  • Categorize these metrics as either operational metrics or reporting numbers. If they are not used by the team to do their daily work or they are not used routinely to make decisions on the work being done by the team, then these are reporting numbers. For example, they may be summary numbers reported to middle management or reported for audit or risk requirements or even for a legacy report that no one remembers why it is being produced.
  • Is a scorecard being produced for the function? An effective scorecard would have quantitative measures for the deliverables of the functions as well as objective scores for function goals that have been properly cascaded for the overall IT goals

2) Identify gaps with the current metrics: For each of IT functions there should be regular operational metrics for all key dimensions of delivery (quality, availability, cost, delivery against SLAs, schedule). Further, each area should have unit measures to enable an understanding of performance (e.g., unit cost, defects per unit, productivity, etc). As an example, the server team should have the following operational metrics:

    • all server asset inventory and demand volumes maintained and updated
    • operational metrics such as server availability, server configuration currency, server backups, server utilization should all be tracked
    • also time to deliver a server, total server costs, and delivery against performance and availability SLAs should be tracked
    • further secondary or verifying metrics such as server change success, server obsolescense, servers with multiple backup failures, chronic SLA or availability misses, etc should be tracked as well
    • function performance metrics should include cost per server (by type of server), administrators per server, administrator hours to build a server, percent virtualized servers, percent standardized servers, etc should also be derived

3) Establish full coverage: By comparing the existing metrics against the full set of delivery goals, you can quickly establish the appropriate operational metrics along with appropriate verifying metrics. Where there are metrics missing that should be gathered, work with the function to incorporate the additional metrics into their daily operational work and processes. Take care to work from the base metrics up to more advanced:

    • start with base metrics such as asset inventories and staff numbers and overall costs before you move to unit costs and productivity and other derived metrics
    • ensure the metrics are gathered in as automated a fashion as possible and as an inherent part of the overall work (they should not be gathered by a separate team or subsequent to the work being done

Ensure that verifying metrics are established for critical performance areas for the function as well. An example of this for the server function could be for the key activity of backups for a server:

    • the operational metrics would be perhaps backups completed against backups scheduled
    • the verifying metric would be twofold:
      • any backups for a single server that fail twice in a row get an alert and an engineering review as to why they failed (typically, for a variety of reasons 1% or fewer of your backups will fail, this is reasonable operational performance. But is one server does not get a successful backup for many days, you are likely putting the firm at risk if there is a database or disk failure, thus the critical alert)
      • every month or quarter, 3 or more backups are selected at random, and the team ensures they can successfully recover from the backup files. This will verify everything associated with the backup is actually working.

4) Collect the metrics only once: Often, teams collect similar metrics for different audiences. The metrics that they use to monitor for example configuration currency or configuration to standards, can be mostly duplicated by risk data collected against security parameter settings or executive management data on a percent server virtualization. This is a waste of the operational team’s time and can lead to confusing reports where one view doesn’t match another view. I recommend that you establish and overall metrics framework that includes risk and quality metrics as well as management and operational metrics so that all groups agree to the proper metrics. The metrics are then collected once, distilled and analyzed once, and congruent decisions can then be made by all groups. Later this week I will post a recommended metrics framework for a typical IT shop.

5) Drop the non-value numbers activity: For all those numbers that were identified as being gathered for middle management reports or for legacy reports with an uncertain audience; if there is no tie to a corporate or group goal, and the numbers are not being used by the function for operational purposes, I recommend to stop collecting the numbers and stop publishing any associated reports. It is non-value activity.

6) Use the metrics in regular review: At both the function team level and function management level the metrics should be trended, analyzed and discussed. These should be regular activities: monthly, weekly, and even daily depending on the metrics. The focus should be on how to improve, and based on the trends are current actions, staffing, processes, etc, enabling the team to improve and be successful on all goals or not. A clear feedback loop should be in place to enable the team and management to identify actions to take place to correct issues apparent through the metrics as quickly and as locally as possible. This gives control of the line to the team and the end result is better solutions, better work and better quality. This is what has been found in manufacturing time and again and is widely practiced by companies such as Toyota in their factories.

7) Summarize the metrics from across your functions into a scorecard: Ensure you identify the key metrics within each function and properly summarize and aggregate the metrics into an overall group score card. Obviously the score card should match you goals and key services that you deliver. It may be appropriate to rotate in key metrics from a function based on visibility or significant change. For example, if you are looking to improve overall time to market(TTM) of your projects, it may be appropriate to report on server delivery time as a key subcomponent and hopefully leading indicator of your improving TTM.  Including on your score card, even at a summarized level, key metrics from the various functions, will result in greater attention and pride being taken in the work since there is a very visible and direct consequences. I also recommend that on a quarterly basis, that you provide an assessment as to the progress and perhaps highlights of the team’s work as reflected in the score card.

8 ) Drive better results through proactive planning: The team and function management, once the metrics and feedback loop are in place, will be able to drive better performance through ongoing improvement as part of their regular activity. Greater increases in performance may require broader analysis and senior management support. Senior management should do proactive planning sessions with the function team to enable greater improvement to occur. The assignment for the team should be how take key metrics and what would be required to set them on a trajectory to a first quartile level in a certain time frame. For example, you may have both a cost reduction goal overall and within the server function there is a subgoal to achieve greater productivity (at a first quartile level)  and reduce the need for additional staff. By asking the team to map out what is required and by holding a proactive planning session on some of the key metrics (e.g. productivity) you will often identify the path to meet both local objectives that also contribute to the global objectives. Here, in the server example, you may find that with a moderate investment in automation, productivity can be greatly improved and staff costs reduced substantially. Thus both objectives could be obtained by the investment.  By holding such proactive sessions, where you ask the team to try and identify what would needs to be done to achieve a trajectory on their key metrics as well as considering what are the key goals and focus at the corporate or group level, you can often identify such doubly beneficial actions.

By taking these steps, you will employ a scientific approach to your metrics. If you add a degree of process definition and maturity, you will make significant strides to controlling and improving your environment in a sustainable way. This will build momentum and enable your team to enter a virtuous cycle of improvement and better performance. And then if add to the mix process improvement techniques (in moderation and with the right technique for each process and group), you will accelerate your improvement and results.

But start with your metrics and take a scientific approach. In the next week, I will be providing metrics frameworks that have stood well in large, complex shops along with templates that should help the understanding and application of the approach.

What metrics approaches have worked well for you? What keys would you add to this approach? What would you change?

Best, Jim

IT Service Desk: Building a Responsive and Effective Desk

    Steve Wignall

This is the 4th in a series of posts on best practices in the IT Service Desk arena. To catch the previous material, you can check out the first post or you can read through the best practice reference pages on the the IT Recipes site. To help you best use this site, please know that as material is covered in the posts, we subsequently use it to properly build an ongoing reference area that can be used when you encounter a particular issue or problem area and are looking for how to solve it. There’s a good base of material in the reference area on efficiency and cost cutting, project management, recruiting talent, benchmarking, and now service desk. If you have any feedback on how to improve the reference area structure, don’t hesitate to let us know. We will be delivering one more post on service desk after this one and then I will be shifting to leadership techniques and building high performance teams.

One of the key challenges of the Service Desk is to respond to a customer transaction in a timely manner. Often, two situations occur: either efficiency or budget restrictions result in lengthened service times and poor perception of the service or the focus is purely on speed to answer and the initial interaction is positive but the end result is not highly effective. Meeting the customer expectations on timeliness, being cost effective, and delivering real value is the optimal performance that is our target.

Further, this optimal performance must be delivered in a complex environment. Timeliness must be handled differently for each activity (for example, the service for a significant production incident or service loss is handled as a ‘live’ telephone call, whereas an order for new equipment would be primarily submitted via a web form). The demand for the services is often 24 hours a day and global with multiple languages and interaction occurs over phone, web chat, and intranet (and soon, mobile app interfaces). This optimal performance should have both the cost and the effectiveness of the service desk measured holistically, that is, all the costs to deliver a service should be totaled including the end user and customer cost (e.g., wait time, restoration time, lost revenue opportunity, etc) and engineering time (e.g., time required to go back a gather data to deliver a service or time avoided if service is automated or handled by the service desk).

A great Service Desk not only delivers the operational numbers, it ensures that the workload flowing through the process is ‘value add’ activity that is required and necessary. The Service Desk must ensure that it measures performance as a cost / benefit to the whole organisation and not just in isolation. Doing the ‘right thing’ may actually move the narrower operational Service Desk metrics in the wrong direction; yet at the enterprise level it remains the right thing to do.

Optimize your service desk by managing demand and improving productivity

There are two primary factors that drive your service desk cost and delivery:

  • the number of calls and in particular the peak volume of calls, and,
  • the cost base of your service desk (mostly people costs: salary, benefits, taxes, etc

The volume and pattern of transaction demand is in turn the primary driver of the number of people required and is the key determinant of the overall cost base of the Service Desk. More specifically, the peak load of the Service Desk (the time at which call volumes are highest) is the time that drives your peak staffing volume and is therefore the most important target of demand reduction (i.e. the point that reductions in call / transaction volume are most likely to be realised as a financial cost saving or improved responsiveness to customers).

There are three key opportunities:

  • Mange the transaction volume
  • Manage the transaction pattern
  • Manage the transaction time

And in each opportunity area, we will look to apply best practices such that we improve the effectiveness of the service desk and IT experience overall.

Managing the Transaction Volume

Reducing the overall volume of transactions presented to the department reduces total workload. And while reducing the number of transactions is a good thing, these reductions may not be realised as cost savings or reduced customer wait times if they simply increase idle time during your quieter periods and do not reduce the peak load. The peak load is the point at which resourcing levels are at their highest and yet you are likely to have negative capacity (i.e. your customers will queue as you cannot resource fully to meet the peak). Eradicating demand even within troughs is valuable; however the true value is to focus on the peak. So start by identifying your key volume drivers and your peak load key volume drivers through statistical analysis. The use of Pareto analysis will usually demonstrate that a significant volume of your calls (+80%) are driven by a fairly small number of categories of call, sometimes the top 15 / 20 call types can account for as much as 80% of the total volume of calls. Then, for each call type impacting the peak, do the following analysis and actions:

  • Is it a chronic issue — meaning, is it a repetitive problem that users experience (i.e. Citrix is down every Monday morning, or new users are issued the wrong configuration to properly access data, etc)? If it is, then rank by frequency, missed SLAs and total cost (e.g. 200 users a week with the issue costing 2 hours of lost time is a $32,000/month problem). Allocate the investment based on SLA criticality and ROI and assign it to the appropriate engineering area to address with signoff by the service desk required when completed.
  • Is it a navigation or training issue? Having significant numbers of users call the service desk as a last resort to find out how to do something is an indicator that your systems or your intranet is not user friendly, intuitive or well-designed. Use these calls to drive navigation and design improvements for your systems and your intranet in each release cycle. Look to make it a normal input to improve usability of your systems.
  • Is it that requests can only be handled manually? As I have mentioned in previous posts, often the internal systems for employees (e.g. HR, Finance and IT) are the least automated and have manual forms and workflow. Look to migrate as much as possible to a self-serve, highly automated workflow approach. This particularly true for password administration. Unless you have full logical access automation, it is likely that User Administration and Password Management are key call drivers, particularly at peak as users arrive at work and attempt to log on to systems. Automation of password resets at an application / platform level is often achievable quickly and at a much lower cost than a fully integrated solution. Assign to your engineering and development teams so you can make significant peak load demand reductions with little or no investment and corresponding user experience improvement.
  • Can you automate or standardize? If you cannot automate then look to standardise wherever possible. For example, have the Service Desk work in partnership with your IT Security group and ensure that you adopt a corporate standard construction for passwords and log on credentials. This will result in users being less likely to lock themselves out of their accounts and reduce the peak load. And ensure the standards don’t go overboard on security. I once had a group where the passwords were changed for everyone every month. The result was 20,000 additional calls to the service desk because people forgot their passwords, and lax security because nearly everyone else was writing down their passwords. We changed it back to quarterly and saved $400,000 a quarter in reduced calls and made the users happy (and improved security).
  • Can you eliminate calls due to misdirection? Identify failure demand which are calls that are generated by weaknesses in the design or performance of support processes, including: wrong department / misdirected calls (or IVR choices), use of the Service Desk as a ‘Directory Enquiries’ function, repeat calls and chaser calls (i.e. where the customer hasn’t been able to provide all of the required details in one call or had to chase because their expectations have not been met). Failure demand should be eradicated through the re-design of support processes / services to eliminate multiple steps and common defects as well as improved customer communication and education.
  • Can you increase self service? Identify calls that could be resolved without the intervention of the Service Desk, i.e. through the use of alternative channels such as self service. Work with business lines and gain agreement to direct callers to the alternative (cheaper) channels. To encourage adoption, market the best channels and where necessary withdraw the services of the Service Desk to mandate the use of automation or self service solutions.
  • Is root cause addressed by the engineering teams? Undertake robust Problem Management processes and ensure that your engineering and application groups have clear accountabilities to resolve root cause issues and thus reduce the volume of calls into the Service Desk. A good way to secure buy in is to convert the call volumes into a financial figure and ensure the component management team has full awareness and responsibility to reduce these costs they are causing.
  • Can you streamline your online or intranet ticket creation and logging process? Organizations increasingly want to capture management information about technical faults that were fixed locally and it is not uncommon for business lines to request that a ticket is logged  just for management information purposes. Design your online ticket logging facility to be able to handle all of these transactions. Whilst such information is valuable, the Service Desk agent adds no value through their involvement in the transaction.
  • Do you have routing transactions that can have their entry easily automated?Consider reviewing operating procedures and identifying those transactions in which your agents undertake ‘check list’ style diagnosis before passing a ticket to resolver groups. In these instances, creating web forms (or templates within your Service Management toolset) enables the customer to answer the check list directly, raise their own ticket and then route directly to support.

Managing the Transaction Pattern

If workload cannot be eradicated (i.e. it is value-added work that must be done by the agent) then we next look to shift the work from peak to non-peak service times. Delivering service ‘at the point of peak customer demand’ is the most expensive way to deliver service as it increases the resource profile required and could build in high levels of latent non-productive time for your agents.

One technique to apply to shift the work from peak to non-peak is through customer choice. Leverage your IVR or your online self service ticketing systems to enable the customer to choose a call back option at non-peak times if they call in at peak. Many customer would prefer to  to select a specific time of service with certainty versus waiting an indeterminate amount of time for an agent. They can structure their workday productively around the issue. But you must ensure your team reliably calls back at the specified time.

Customer education around busy and quiet periods to call, messages on your IVR and even limiting some non-essential services to only being available during low demand hours will all help to smooth workflow and reduce the peak load. Further, providing a real-time systems production status toolbar on the intranet will minimize repeat call-ins for the same incident or status query calls.

You can also smooth or shift calls due to system releases and upgrades. Ensure that your releases and rollouts are scheduled at the with peak times in mind. A major rollout of a new system at the end of the month on a Monday morning when the service desk experiences a peak and there are other capacity stresses is just not well-planned.  Userids, passwords, and training should all be staged incrementally for a rollout to smooth demand and provide a better system introduction and resulting user experience. As a general rule doing a pilot implementation to gauge true user interaction (and resulting likely calls) is a good approach to identifying potential hotspots before wide introduction and fixing them.

Managing the Transaction Time

Transaction time can be improved in two ways:

  • improve the productivity and skill of the agent (or reduce the work to be done)
  • increase the resources to meet the demand thus reducing the wait time for the transactions.

Start by ensuring your hiring practices are bringing onboard agents with the right skills (technical, customer interface, problem-solving, and languages). Encourage agents to improve their skills through education and certification programs. Have your engineering teams provide periodic seminars on the systems of your firm and how they work. Ensure the service desk team is trained as part of every major new system release or upgrade.  Implement a knowledge management system that is initially written jointly by the engineering team and the service desk team. Enables comments and updates and hints to be added by your service desk agents. Ensure the taxonomy of the problems set is logical and easily navigated. And then ensure the knowledge base and operational documentation is updated for every major system release.

Another method to improve the productivity of your service desk is to capture the service and transaction data by the various service desk subteams (e.g., by region or shift, etc). There will be variation across the subteams, and you can use these variations to pinpoint potential best practices. Identifying and implementing best practice across your desk should lead to a convergence over time of call duration to an optimal number. Measuring the mean average and the standard deviation around the mean should demonstrate convergence over time if best practice is being embedded and used consistently across the workforce. Remember that just having the lowest service time per call may not be the optimal practice. Taking a bit longer on the call and delivering a higher rate of first call resolution is often a more optimal path.  Your agents with the longest call duration may be fixing more transactions; however it could be that some of these are too time consuming and should have been time-shifted as other customers are now being left to queue.

Managing transaction time has to be done very purposefully; otherwise quality is placed at risk. If agents believe they are under pressure to meet a certain transaction time, they will sacrifice quality to do so. This will result in re-work, reduced volumes of calls resolved at first point of contact and reduced customer satisfaction as they will receive inconsistent and reduced service. Transaction time has to be managed as a secondary measure to quality and resolution rates to prevent this from occurring. There should never be a stated deadline as to when a call has become too lengthy – each customer interaction has to be managed on its own merits and only in the aggregate (say a weekly or monthly average) can you fairly compare the delivery of your agents against each other.

Resource planning is the science of matching your supply of resources to meet the demand from the customer within a specified period of time (let’s say 20 seconds). Call Centres will usually manage their resource profile in 15 minute intervals. The mechanics of doing this is driven by probability – the probability of a call being presented within a 15 minute period (predicted using historical data gathered from your telephony) and the probability that an agent will become available within 20 seconds of the call being presented to answer that call. The ‘magic number’ of agents required in a 15 minute period is met when these probabilities are aligned so that we will meet the required level of service (e.g. 90% of calls will be answered in 20 seconds).

The volume of calls presented is one half of this equation, the frequency with which an agent becomes available is the other. Agents become available when they join the pool of active agents (i.e. when they sign in for a shift) or when they complete a call and are ready to receive the next call. The average transaction time (call length plus any additional time placing the agent in an unavailable state) determines how frequently they will become available in any given 15 minute period. A Call Centre with an average call duration of 2 ½ minutes will have each agent becoming available 6 times in a 15 minute period, whereas a call duration of 6 minutes will only have each agent becoming available 2 ½ times. The probability of an agent becoming available within the 20 second window in the first call centre is significantly higher and their resource requirements will therefore be much lower than the second. The right number for your business will be for you to determine. Then apply the best practice staffing approaches mentioned in our earlier posts. Recruit a talented team in the right locations and look to leverage part-time staff to help fulfill peak demand.

Here are a few best practice techniques for you to consider in managing the Transaction Time:

  • When calculating transaction time, ensure that you include not only the length of active talk time but also any other factor that makes the agent unavailable for the next call to be presented (e.g. any rest time that you have built into the telephony, any ‘wrap up’ time that the agent can manually apply to block other calls being presented etc…).
  • Present calls direct to agent headsets (i.e. a beep in the ear) rather than have their phones ring and require manually answering.
  • Analyse what the difference is between your best and worst performing agents, determine what best practice is and roll it out across the team. This may include everyone having access to the right applications on their desktop, having the right shortcuts loaded in their browsers, keeping high volume applications open rather than logging in when a relevant call is presented and a thousand other nuances that all add up to valuable seconds on a call.
  • Do a key stroke by key stroke analysis of how your agents use the Service Management toolset. Manage the logical workflow of a ticket, automate fields where possible, build templates to assist quick information capture and ensure that there is no wasted effort (i.e. that every key stroke counts). Ensure that support groups are not inflating call duration by requesting fields that are re-keyed in tickets for their own convenience.
  • Invest in developing professional coaching skills for your Team Leaders (you may even want to consider dedicated performance coaches) and embed call duration as an important element in your quality management processes. (Focusing on the length of call being right and appropriate for the circumstances and not just short). Coach staff through direct observation and at the time feedback.
  • Ensure that your performance metrics and rewards are aligned so that you reward quality delivery and your people have a clear understanding of the behaviours that you are driving. Ensure that performance is reviewed against the suite of measures (resolution, duration, quality sampling etc…) and not in isolation.
  • Build your checks and measures to keep the process honest. Measure and manage each element of the process to ensure that the numbers are not being manipulated by differences in agent behaviour. Run and check reports against short calls, agent log in / log out, abandoned calls and terminated calls. How agents use these statuses can fundamentally change their individual performance metrics and so it is the role of leaders to ensure that the playing field is level and that the process is not being subverted through negative behaviors.

On a final note on resource planning, if you have more than once central desk, look to consolidate your service desks. If you have different desks for different technologies or business areas, consolidating them will invariable lower cost and actually improve service. The economies of scale in call centers are very material, Further size and scale make it easier to run a Call Center that consistently deliver the quality, call response time and benchmarks favorable to the external market. Don’t let technology or business divisions sub-optimize this enterprise utility.

Effectively resourcing a Service Desk is about the application and manipulation of the laws of supply and demand. The Service Desk is not a passive victim of these forces and great Service Desks will be heavily focused on maximising the productivity, efficiency and effectiveness of the supply of labour. They will equally be managing their demand profile to ensure that all work is required and value add, workflow is managed to smooth demand away from peaks and that customers needs are satisfied through the most effective and efficient channels to deliver exceptional customer service.

We look forward to your thoughts or additions to these best practices for service desk.

Best, Steve and Jim

Moving from IT Silos to IT Synergy

    Jim D

We will revisit the Service Desk best practices this weekend as we have several additions ready to go, but I wanted to cover how you, as an IT leader, can bring about much greater synergy within your IT organization. In many IT shops, and some that I found when I first arrived at a company, the IT is ‘siloed’ or separate into different divisions, with typically each division supporting a different business line. Inevitability there are frustrations with this approach, and they are particularly acute when a customer is served by two or more lines of business. How should you approach this situation as a leader and what are the best steps to take to improve IT’s delivery?

I think it is best first to understand what are the drivers for variations in IT organizations under large corporations. With that understanding we can then work out the best IT organizational and structural models to serve them. There are two primary sets of business drivers:

  • those drivers that require IT to be closer to the business unit such as:
    • improving market and business knowledge,
    • achieving faster time-to-market (TTM),
    • and the ability to be closer in step and under control of the business leads of each division
  • those drivers that require IT to be more consolidated such as:
    • achieving greater efficiencies,
    • attaining a more holistic view of the customers,
    • delivering greater consistency and quality
    • providing greater scale and lower comprehensive risk

So, with these legitimate pushes, in two different directions, there is always a conflict in how IT should be organized. In some organizations, the history has been two or three years of being decentralized to enable IT to be more responsive to the business, and then, after costs are out of control, or risk is problematic, a new CFO, COO, or CEO comes in and  IT is re-centralized. This pendulum swing back and forth, is not conducive to a high performance team, as IT senior staff either hunker down to avoid conflict, or play politics to be on the next ‘winning’ side. Further, given that business organizations have a typical life span of 3 to 4 years (or less) before being re-organized again, corollary changes in IT to match the prevailing business organization then cause havoc with IT systems and structures that have 10 or 20 year life spans. Moreover, implementing a full business applications suite and supporting business processes takes at least 3 years for decent-sized business division, so if organizations change in the interim, then much valuable investment is lost.

So it is best to design an IT organization and systems approach that meets both sets of drivers and anticipates that business organizational change will happen. The best solution for meeting both sets of drivers is to organize IT as a ‘hybrid‘ organization. In other words, some portions of IT should be organized to deliver scale, efficiency, and high quality, while others should be organized to deliver time to market, and market feature and innovation.

The functions that should be consolidated and organized centrally to deliver scale, efficiency and quality should include:

  • Infrastructure areas, especially networks, data centers, servers and storage
  • Information security
  • Field support
  • Service desk
  • IT operations and IT production processes and tools

These functions should then be run as a ‘utility’ for the corporation. There should be allocation mechanisms in place to ensure proper usage and adequate investment in these key foundational elements. Every major service the utility delivers should be benchmarked at least every 18 months against industry to ensure delivery is at top quartile levels and best practices are adopted. And the utility teams should be relentlessly focused on continuous improvement with strong quality and risk practices in place.

The functions that should be aligned and organized along business lines to deliver time to market, market feature and innovation should include:

  • Application development areas
  • Internet and mobile applications
  • Data marts, data reporting, and data analysis

These functions should be held accountable for high quality delivery. Effective release cycles should be in place to enable high utilization of the ‘build factory’ as well as a continuous cycle of feature delivery. These functions should be compared and marked against each other to ensure best practices are adopted and performance is improved.

And those functions which can be organized flexibly in either mode would be:

  • Database
  • Middleware
  • Testing
  • Applications Maintenance
  • Data Warehousing
  • Project Management
  • Architecture

For these functions that can centralized or organized along business lines, it is possible to organize in a variety of ways. For example, systems integration testing could be centralized and unit test and system testing could be allocated by business line application team. Or, data base could have physical design and administration centralized and logical design and administration allocated by application team. There are some critical elements that should be singular or consolidated, including:

  • if architecture is not centralized, there must be architecture council reporting to the CIO with final design authority
  • there should be one set of project methodologies, tools, and process for all project managers
  • there should be one data architecture team
  • there should be one data warehouse physical design and infrastructure team

In essence, as the services are more commodity, or there is critical advantage to have a single solution (e.g. one view of the customer for the entire corporation) then you should establish a single team to be responsible for that service. And where you are looking for greater speed or better market knowledge, then organize IT into smaller teams closer to the business (but still with technical fiduciary accountabilities back to the CIO).

With this hybrid organization, as outlined in the diagram, you will be able to deliver the best of both worlds: outstanding utility services that provide cost and quality advantage and business-aligned services that provide TTM and market feature and innovation. .

As CIO, you should look to optimize your organization using the ‘hybrid’ structure. If you are currently entirely siloed, then start the journey by making the business case for the most commodity of functions: networks, service desks, and data centers. It will be less costly, and there will be more capability and lower risk if these are integrated. As you successfully complete integration of these area, you can move up the chain to IT Operations, storage, and servers. As these areas are pooled and consolidated you should be able to release excess capacity and overheads while providing more scale and better capabilities. Another area to start could be to deliver a complete view of the customer across the corporation. This requires a single data architecture, good data stewardship by the business, and a consolidated data warehouse approach. Again, as functions are successfully consolidated, the next layer up can be addressed.

Similarly, if you are highly centralized, it will be difficult to maintain pace with multiple business units. It is often better to divest some level of integration to achieve a faster TTM or better business unit support. Pilot an application or integration team in those business areas where innovation and TTM are most important or business complexity is highest. Maintain good oversight but also provide the freedom for the groups to perform in their new accountabilities.

And realize that you can dial up or down the level of integration within the hybrid model.  Obviously you would not want to decentralize commodity functions like the network or centralize all application work, but there is the opportunity to vary intermediate functions to meet the business needs. And by staying within the hybrid framework, you can deliver to the business needs without careening from a fully centralized to a decentralized model every three to five years and all the damage that such change causes to the IT team and systems.

There are additional variations that can be made to the model to accommodate organizational size and scope (e.g., global versus regional and local) that I have not covered here. What variations to the hybrid or other models have you used with success? Please do share.

Best, Jim

 

 

 

IT Service Desk best practices

    Jim D

An important interface for your internal customers is through your IT service desk. Unfortunately, in many situations the service desk (or help desk) does not use up-to-date practices and can be a backwater of capability. This can result in a very poor reputation for IT because the service desk is the primary customer interface with the IT organization. I recall starting at a company tasked with turning around the IT organization. When I asked about the IT help desk, the customer turned to me and said ‘ You mean the IT helpless  desk?’  With a reputation that poor with our customers, I immediately set out to turnaround our service desk and supporting areas.

The IT Service Desk may seem quite straightforward to address — maybe the thought is that all you really need to do is have one number, staff it, be courteous and try hard.  This isn’t the case and there are some clear best practice techniques and approaches that will enable you to deliver consistent, positive interactions with your customers as well as enable greater productivity and lower cost for the broader IT team.

For our discussion, I have two esteemed former colleagues who have run top notch service desks that will be authoring material on best practices and how to deliver an outstanding customer experience through this critical interface. Both Steve Wignall and Bob Barnes have run world class service desks at large financial services companies. And I think you will find the guidance and techniques they provide here today and in subsequent posts to be a surefire manner to transforming your ‘helpless’ desk to a best in class service desk.

First, let’s recap why the service desk is such an important area for IT:

  • the service desk is the starting point for many key processes and services for IT
  • well-constructed, the service desk can handle much of the routine work of IT, enabling engineering and other teams to do higher value work
  • it is your primary interface with the customer, where you can gauge the pulse of your users, and make the biggest daily impact on your reputation
  • with the right data and tools, the service desk identify and correct problem outbreaks early, thereby reducing customer impacts and lowering overall support costs.

And yet, despite its importance to IT, too often Service Desks are chronic under-performers due to the following issues:

  • poor processes or widespread lack of adherence to them
  • the absence, or low quality application, of a scientific and metric based management approach
  • lousy handoffs and poor delivery by the rest of IT
  • inadequate resources and recruiting, worsened by weak staff development and team-building
  • weak sponsorship by senior IT leaders
  • ineffective service desk leadership

Before we get into the detailed posts on service desk best practices, here are a few items to identify where your team is, and a few things to get started on:

1. What is your first call resolution rate? If it is below 70% then there is work to do. If it is above 70% but primarily because of password reset, then put in decent self serve password reset and re-evaluate.

2. What is the experience of your customers? Are you doing a monthly or quarterly survey to track satisfaction with the service? If not, get going and implement. I recommend a 7 point scale and hold yourself to the same customer satisfaction bar your company is driving for with its external customers.

3. What are the primary drivers of calls? Are they systems issues? Are they due to user training or system complexity issues? Workstation problems? Are calls being made to report a surplus of availability or general systems performance issues? If you know clearly (e.g., via Pareto analysis) what is driving your calls, then we have the metrics in place (if not, get the metrics – and process if necessary — in place). Once you have the metrics you can begin to sort out the causes and tackle them in turn. What is your team doing with the metrics? Are they being used to identify the cause of calls to then go about eliminating the call in the first place?

For example, if leading drivers of calls are training and complexity, is your team reworking the system so it is more intuitive or improving the training material? If the drivers are workstation issues, do you know what component and what model and are now figuring out what proactive repair or replacement program will reduce these calls? Remember, each call you eliminate probably saves your company at least $40 (mostly in eliminating the downtime of the caller).

4. Do you and your senior staff meet with the service desk team regularly and review their performance and metrics? Do senior IT leaders sponsor major efforts to eliminate the source of calls? Does the service desk feature in your report to customers?

5. If it is a third party provider, have you visited their site lately? Does your service area have the look and feel and knowledge of your company so they can convey your brand? And hold them to the same high performance bar as you would your own team.

Use these five items for a quick triage of your service desk and our next posts will cover the best practices and techniques to build a world-class service desk. Later this week, Bob and Steve will cover the structure and key elements of a world-class service desk and how to go about transforming your current desk or building a great one from scratch. Steve will also cover the customer charter and its importance to maintaining strong performance and meeting expectations.

I look forward to your thoughts and experiences in this area. And perhaps you have a service desk that could use some help to turn around IT’s and your reputation.

Best, Jim

 

 

 

Evaluating and Selecting Senior Talent – Perhaps the Google Way?

    Jim D

There was an interesting article earlier this week on the interview approach that Google has used as part of their talent selection in the Wall Street Journal by William Poundstone. My preceding post reviewed the Google approach and what best practices there are for more junior IT talent. In this post, I cover the best techniques for evaluating and selecting senior IT talent.

As mentioned, according the the WSJ article, currently Google gets over a million applications per year, and from this only about 1 in 130 applicants are hired. Yet getting this flood of applicants and having ratios of candidates to hires close to 1 to 100 is not unusual. At the last two large companies I have held senior positions in, we received hundreds of thousands of applications per year, and the end ratio to the hire was close to 1 to 100. And, as an IT leader making sure your HR department can handle these ever-growing volumes effectively is an important service you should provide, especially if you are a retail company. Remember every potential applicant who has a poor experience on your web job site and process is a potential customer who is now turned off on your company. Again, the preceding post covers how to filter and handle this flood today, we will cover the senior end of the spectrum.

For recruiting senior staff, I think it is important to understand two key facts:

  • They already know the buzzwords and techspeak and political positioning and that you are unlikely to catch them out in an interview with traditional questions (e.g., ‘What was your best project experience and why?’ or ‘When have you failed and what did you learn?’ or ‘What weaknesses do you have?’)
  • Fully one third of all senior hires through traditional methods are duds and only one third are outstanding hires or A players

So how do you effectively sort through a knowledgeable field of seemingly qualified applicants and make the right hire and avoid the duds?

The Google approach, and apparently a growing approach elsewhere is to include brain teasers in the interview process such as:

‘You are shrunk to the height of a nickel and thrown into a blender. Your mass is reduced so that your density is the same as usual. The blades start moving in 60 seconds. What do you do?’

Hopefully, these brain teasers will enlighten the interviewer about the intellect and creativity of the candidate, and also provide how they might respond in a tough situation. While I think this can be better than the stock interview questions that the candidates are already prepared to answer, I think there are a number of better techniques to sort out the best candidates from those who are just adequate or worse, the duds. And again, I think you must start much earlier in the process than the interview.

You should have a dedicated process just for senior candidates staffed with your best recruiters. And these recruiters are good at three things:

  • Being good at cold calling and getting hold of A players who are busy and not looking for a job (we’ll talk later about the source of the names, but this is the entry step)
  • Checking references – really finding out how well and in what manner this person has delivered
  • Recognizing critical cues about the candidate based on the candidates behavior throughout the selection process

In your selection process for senior talent, the first step is the candidate sourcing, or where you get the names of potential top talent that would fill one of your senior positions. This is actually probably the most important step of the process, because if done well, you will have a ready source of mostly ‘A’ caliber talent and you will avoid most of the duds ever getting into your recruiting process. For reliable sources of good talent I would rely on the following:

  • your own personal ‘virtual’ bench – you should cultivate and maintain a virtual bench throughout your career. Those outstanding performers who worked for you or with you and would come and work for you again.
  • thoughtful referrals from your current ‘A’ players – use their virtual bench and their knowledge of other strong performers to reach the A players that you might otherwise not find.
  • industry referenced talent based on either:
    • strong results at top firms or progression working under a well-known strong leader – that’s where quality results, leadership, and excellent approaches are forged.
    • strong recommendations from previous colleagues now working with the candidate – get a real-life view from a reliable perspective.
    • balanced recommendations coming from an established vendor – while taking care to understand their potential bias of course, could point out talents from someone who has a the perspective to measure and benchmark.
  • top recruiters or search firms known for their quality (this must be used in a cautious manner though) – also can have great perspective and if they know you well, and are focused on your needs can get you the right talent. Don’t forget often talent is off the table because of agreements with other clients.

Once you have the right list of candidates then you move into the evaluation and selection process. I have successfully implemented top-grading approaches to interviewing but I would suggest I am an 80% adherent of this method. The top-grading approach can be lengthy and exhaustive but I think you can trim it substantially and achieve the same effect (though I am sure Brad Smart would disagree). And you can improve it by adding and emphasizing behavioral and team interviews. Given that many senior hires do not work out due to culture misalignment, leadership style, or poor teamwork; a behavioral interview focused on these aspects will reveal potential issues. I recommend doing a team type interview where at least one, if not both of the interviewers are skilled in behavioral interviewing and non-verbal cues. Ensure you explore their flexibility and adaptability for   different environments and cultures. Someone who has been highly successful in one environment for 10 or 15 years may be a fish out of water in your firm.

As for those key questions to help sort a great fit from an okay fit, I recommend that you will get a clearer response if you ask a ‘reflective’ question versus a direct question. For example, if you want to understand their personal attributes, rather than ask them a question like “Do you work hard’ or ‘Do you consider yourself innovative’, etc, instead ask them to reflect their own image with questions such as ‘When you are building a team, on what attributes do you select the team members?’  They will not typically have a stock response for a reflective question, and they will be less guarded in their response because they would not perceive that they are talking about themselves, merely their approach. But their answers can be illuminating, it will show what they value. Someone who builds a team based on loyalty and experience attributes is very different than someone who builds a team based on initiative, intelligence, and ability to work through problems. Reflective questions can provide these insights.

Another reflective approach is to simulate leadership approaches and decisions with broad scenarios. Suggest they have inherited a poor performing team. Ask them what they would do. Again, you will get very different answers — some might delegate the problem to a trusted expert, others will apply an improvement approach that has worked for them previously, or they may form a committee to investigate. These are all illuminating. You can also try ‘off-guard’ questions to test their resilience or knowledge. You can even be slightly confrontational to see how they react to such situations. Do they constructively defend their positions or do they just fold and seek full consensus.  I recommend building a developing your own scripts that enable further insights into your senior candidates.

As you narrow down the choices, ensure you check the reference before you have made up your mind. I have seen many poor senior hires where one or two well-placed phone calls would have steered the company clear of the choice. And, if you do make the wrong hire, don’t wait to fix it. The single biggest regret that most senior managers have is not moving fast enough to replace a poor performer. If they are not doing well in the honeymoon period, they will not get going when things get tough. Spare them and you and make a quick and respectful break. Plus, you will likely still have the #2 or #3 candidate available.

The last recommendation I have for senior hires is: don’t forget about the ones on your current team with potential. For senior roles, I think large organizations often ‘pigeon-hole’ current talent and never see the potential they truly have. Someone who is successful in their current role, is smart, capable, coachable, works hard, and gets outstanding results is someone who likely can step up to the next level with assistance. Don’t overlook them.

If you deploy these techniques with senior hires, you should be able to reduce the ‘duds’ rate to 10% and increase the ‘A’ player rate to 60 or 70%. This is a huge improvement that will make a major difference in your organization. So, what techniques or ‘key questions’ have you used to make the right senior hires? Let me know, I am very interested in your approach as this is a tough area to be consistently successful in.

And if you were wondering about the brainteasers, WSJ and Mr. Poundstone also provided the answers to those Google interview questions. I did not provide the ‘right’ answers to the ‘reflective’ questions though.

Best, Jim

Evaluating and Selecting Talent – perhaps the Google Way?

    Jim D

There was an interesting article today on the interview approach that Google has used as part of their talent selection in the Wall Street Journal by William Poundstone. According the the WSJ article, currently Google gets over a million applications per year, and from this only about 1 in 130 applicants are hired. Getting a flood of applicants and having ratios of candidates to hires close to 1 to 100 is not unusual. At the last two large companies I have held senior positions in, we received hundreds of thousands of applications per year, and the end ratio to the hire was close to 1 to 100. Since the advent of the internet job boards and social networking, most large companies are now dealing with a flood of applicants. In fact, enabling your HR department to handle effectively these ever-growing volumes is an important service you should provide, especially if you are a retail company. In other words, every potential applicant who has a poor experience on your web job site and process is a potential customer who is now turned off on your company.

So how do you effectively sort through the flood of applicants effectively, select only the best and leave the rest with a positive experience?

The Google approach, and apparently a growing approach elsewhere is to include brain teasers in the interview process such as:

‘You are shrunk to the height of a nickel and thrown into a blender. Your mass is reduced so that your density is the same as usual. The blades start moving in 60 seconds. What do you do?’

Hopefully, these brain teasers will enlighten the interviewer about the intellect and creativity of the candidate, and also provide how they might respond in a tough situation. While I think just about any off-the-wall puzzle question could do that, I think there are a number of better techniques to sort out the best candidates from those who are just adequate. And I think you must start much earlier in the process than the interview.

First, you should have two processes: one for senior candidates and one for everyone else (entry, junior, and mid-level). Let’s take the more junior roles first in today’s post. You should note that the source of the candidate has very different yields in terms of strong hires. Thus, you should treat candidates differently based on the recruiting method. And you should greatly prime those recruiting methods that are proven. For the more junior roles, your best sources for ‘A’ caliber staff are graduate and intern programs and referrals from current ‘A’ staff. In fact, I would venture these are 2 to 3 times more effective at getting top staff than all your other methods. So, assuming you have invested as much as possible in these two methods (you have referral awards in place, you have an extensive and well-supported intern and graduate program with appropriate universities), how best to handle and sort the flood of applicants from your other sources and fill the remaining shortfalls?

Consider the process from applicant to new hire as a giant funnel. And one where your internet interface must be top-notch to be appealing to your top candidates and thoughtful yet efficient at filtering and still providing a considerate experience for those you will not hire but could be your customers. To ensure you are getting the right candidates at the end of the process, and yet prevent your costs from soaring given the number of applicants, you must have efficient and effective early steps in the selection process. I recommend having a subject area test that an applicant takes via the internet for the vast majority of the junior positions. Your technical team can compile the test (say 200  questions) for the HR recruiting team and keep it up to date. Rotate a different 40 or 50 questions to each applicant that they can take the test over the internet in a set period of time. This will then filter out 80% of the applicants that are often not qualified and just applying. Your company can then send a thoughtful letter explaining they did not score high enough to be considered further but you appreciate that they applied.

Next, make it very clear throughout the process, that you will check references. This will cause the poor performers to think twice about applying to your company. As you move to the next step of identifying the candidates to interview from those who passed the test, I recommend setting a high bar where the candidates must be qualified but then have one additional outstanding experience or quality (e.g., won an award at their previous company or school, showed initiative in gaining additional certifications or knowledge of your company, etc). Now you have optimized the pool that you will interview — not too big to make it too time-consuming and expensive, and not too small to gain diversity and ensure you don’t miss great candidates. Again, I recommend two additional methods for the junior candidate process to achieve a better screen: a problem or work simulation; and a team interview.

The problem or work simulation (not a brain teaser), would be a 1 or 2 hour session where you give the candidate an exercise similar to the work that they will be doing. If a Unix administrator, give them Unix scripts to write. If a developer, ask them to design or or outline how they code an interface, etc.  This will give you real insight into their capabilities.

The team interview is critical. Often, organizations make the mistake of having only management interview a candidate when in reality, those who are more familiar with the work, and who often will hold a higher bar on the selection, are the teammates and peer staff that this person would work with. In fact, they don’t want someone who is incompetent or would be a poor fit because then they have to carry the load. So include in them in the process. Have one of the more outgoing and senior individuals lead the interview with one or two others participating. And ask the HR person or someone skilled at nonverbal communication to join. Then, when the lead person is asking the questions, the others can observe the body language and other signals that this candidate is giving off that most interviewers miss because they are so focused on the next question. They can ask questions as well of course but should focus on what is not said. Given the importance of team in IT, this is a critical filter to ensure you get people who not only know what must be done, but can do it in the team and culture setting that you have at your company. I have employed the team interview process to ensure you set a consistently high bar, eliminate those who would be detrimental to the team, and importantly, avoid the manager picking only their favorites. And don’t neglect checking the references. And the more senior a person is, the more important it is for you to check the references.

Have established the key selection steps above, the tougher part can be getting the candidates in the first place. Often, the best candidates, the ‘A’ players are not in the applicant pool but are busy working somewhere else. This is where your referrals from your ‘A’ players come in. Your top engineers often know the other good engineers at other companies or elsewhere in the industry. Ensure you have recruiters willing to follow up on the referrals and if necessary, cold call. And make sure, once the candidate is past the initial filters, you move them quickly through the process — otherwise you will lose out on the best candidates to other companies who moved quicker.

Every now and then you will come across other approaches that allow you to identify the top performers. I recall when working for a company in the Midwest that we had a critical need for MUMPS (or Cache) developers (we had a major financial services legacy system developed on a tool primarily used in hospital applications).  We had enormous difficulty finding anyone who had the experience much less developers who were top-notch until, in talking to one of the senior engineers, I found out he had just received a certification and he had not scored as as high as some others nationally. When he showed me the website with the scores listed of those who had taken the test nationally, there was the gold mine of all the top developers in that field. By the next day, we had our best recruiters calling those developers to see if they were interested in a new job at a new company. In fact, I think we ended up hiring 7 of engineers who scored in the top ten on that list.

So you may not have a list of the best fall into your lap like I did at that time, but you can get the best by always having your door open. In other words, for most shops of any size, you will always need project managers, network engineers, server engineers and developers and designers. By taking a ‘pipeline’ approach, where you always have a ‘proxy’ opening for these positions, you can be choosier (you are not under a deadline to fill a position) and when the ‘A’ player who is working at another company gets frustrated one day and decides to post his resume or look, you will come in contact. And with a tuned process using the steps above, you will likely land the best candidates.

Doing a robust intern and graduate program is another form of a pipeline. If you do not have these in place, establish strong intern and graduate programs with the universities near your key sites. It will be a good source for as much as 20% of the new and replacement staff you need. View the intern assignment as one long interview and be sure to have a job placement offer ready at the end of the internship to assure the best interns of a place at your shop when they graduate the following year.

If you deploy these techniques, and ensure your managers place recruiting tasks as important and urgent, and review regularly the operational metrics around recruiting (not just time to hire but more importantly quality of hire by vintage and by source) you will build a strong pipeline of talent that enables you to build sustainably a high performing team. In my next post, I will talk about the different approaches to use for more senior positions as well as top-grading, a very good technique to filter at senior levels.

And by the way, WSJ and Mr. Poundstone also provided the answers to those Google interview questions. Enjoy!

What techniques or best practices have you used to recruit? Any particular pitfalls or issues to avoid? What companies do you admire for their recruiting processes?

Best, Jim

 

 

 

 

Too busy to be productive? Traps of our modern world

    Jim D

There was a very good article in the Wall Street Journal yesterday on ‘How to Save an Unproductive Day in 25 Minutes’.  I found it useful that the article points out a few techniques to keep that day from being a complete loss. But while the authors pointed out a portion of the cause of unproductivity (fragmentation and interruption), they failed to really pin down why so many of us struggle to be productive at work. Or perhaps to put it another way, why so many of us spend nearly all of our time killing alligators and spend so little time draining the swamp. This tendency of being ‘too busy to be productive’ finds particularly fertile ground in IT organizations.

The reason this is more prevalent in IT teams is because in IT there are are the usual ‘urgent’ distractions of email and phone calls and business meetings AND there are additional and very real urgent distractions of production issues and high priority projects that are running late but must be completed on a specific date. Thus, the opportunity and time to do important foundational tasks is even smaller. As a result, I come across many IT teams that are running at 100 miles an hour, not doing a good job of delivery of production or projects and their teams are at or close to burnout. And yet the solution to this very real and overwhelming issue is close at hand for IT leadership to leverage.

To solve this ‘too busy to be productive’ issue, you must address it on two levels: for your self and for your team. If you are running around with your hair on fire, then no amount of coaching by you will change how your team approaches their work. Let’s start with the knowledge that we will be able to change both your productivity and your team’s dramatically in two to three months. Understand that going forward, things that are important (and may or may not have a critical time deadline) will take precedence over everything that tends to interrupt but is not important. And you must demonstrate this improved choice everyday for the next 3 months. Here are the steps to get you and your team out of burnout and delivering with much greater quality and capability:

For you:

a) First, get your calendar balanced. Take your calendar for the next two months and let’s implement some radical changes. First go through your calendar and categorize your activities as either important or not important, reactive (dealing with a crisis demand or the fallout of an issue) or proactive (e.g. planning or addressing root causes). After categorizing, it would be interesting to see how much time you are spending on important and proactive work. My bet is it is less than 25%. And it is even less than that because the first part of the meeting focuses on today’s production failure rather than the planning work you were going to do. Next, either delegate or eliminate all the not important meetings from your calendar. Then, at least 3 times a week allocate 2 hours for important proactive work. Ensure you cover the areas you know need the most attention. If production is a problem, then spend two hours on root cause and how to improve change quality. If project delivery is a problem, spend an hour with your key team reviewing your project metrics and constraints affecting delivery and how to solve them. Spend at least 1 hour per week ensuring your key goals for the next 3 months and the next year are clear, and craft the messages to ensure they are well-communicated. Spend another hour figuring out how you can improve or coach your team to better performance. And stop doing every email and phone call that comes in. You do not need to meet with vendors for new products and solutions when you are having issues with your current delivery. At least half of your emails never need to be read or responded to – ignore them. Stop interrupting your meetings due to phone calls unless it is your boss or a very important customer.   Throughout your day, continually evaluate if you are spending good, solid time on important proactive work.

b) Make clear decisions and ensure you empower the team to execute with quality. Sometimes the cause of the productivity issue is a team caught up in over-analysis. If you are not making clear decisions or if you are making micro-decisions then you can cause your team to do 200% of the work necessary as they try to buttress their recommendation and collect every data point possible. Or the team may abdicate doing work they should do because in the end, they know that you will overrule them and make a micro-decision. Be self aware enough that you are causing these effects. If, in the past three months you have either recalled previous decisions more than once or sent multiple decisions back for more research than either the team is inadequate or you are not decisioning effectively. Sound out with a trusted colleague or coach if you need to improve your decisioning process. The bottom line is that you must stop requiring or doing unimportant analysis work or decision work. Let your team make the decisions for the areas they are accountable for and stop requiring perfect facts to make a decision in this imperfect world.

For your team:

a) First, set goals and expectations that i) you want them to deliver with quality and ii) you will support them to fix things so their work can be done in an improved manner. You must let them know that not only is it ‘safe’ to do things with quality, it is expected. Your team and organization may have fallen into the trap of thinking the only thing that is important is that work must get done based on the timeline, even if it means slamming something in that is riddled with defects. By insisting on quality first, you put your team on notice that this is foundational. Now, it should also be noted that this is not a pass to then have endless delays and no accountability to deliver. Instead, you must work hard to deliver in as timely a manner possible, but with the quality.

b) Use the proactive important time or your calendar to work with your team on the things that will improve how the work is getting done. Are your processes convoluted and time-consuming? Then spend time with the team to straighten them out and lighten the load. Are the tools inadequate? Then figure out what is best practice and pilot an improved set. Are things going in with lousy quality and causing production issues and lots of rework? Then stop letting poor quality change in and fix it before production. Do this even if it means a train wreck on a promised implementation date with the customer. Go and personally talk to the customer that quality is too important to you and to him or her. (I have never met a customer who remembered they insisted something go into production when it was known poor quality and instead blamed IT. Conversely, if you delayed something by a few weeks or even months yet it went in with quality, 6 months later, they invariably remember the successful launch versus the delay.) Spend your time with your team draining the swamp.

c) Set their goals and their schedule leveraging the fact the people do urgent things first. In other words, it is a natural tendency to focus on the urgent things like email instead of getting a backout plan done for a change or mapping out how we improve our development process. So, as the leader, set clear deliverables and clear dates and accountability for the important things (thus making the important and proactive work important AND urgent) for your team. It is a very effective management technique. Then, you will find that much more of the proactive work will get done.

Watch what happens then as a virtuous cycle takes hold. Because implementations start to get done with more quality, there is less fallout and production incidents. With reduced demand to work production issues, your team should have more time and focus on doing more proactive work (you must do (c) above to get this effect, otherwise they will just do more email or other urgent and unimportant work). And as they do more proactive work, they eliminate bottlenecks and rework and become even more productive. This cycle will take a few months to gain traction. And if your organization is really in a rut it may take as long as 6 months to show measurable difference. But usually, the effect is much quicker, and the first lift can be outpaced by the second and third and subsequent lifts as the cycle repeats. I recall one infrastructure component team that had a terrible production track record, the rest of IT viewed them as a bottleneck in the project process and the team, being close to burnout, saw no solution except to double or triple the number of staff. By implementing this approach, within a few months their change success rate went from the mid eighties to better then 99% and they trimmed their implementation processes significantly in terms of effort to deliver a unit of work. Everyone understood what their goals were and what was important to get done to be successful. And when I asked one of the managers to compare his team’s work to the state three months prior, he said ‘It is night and day. I can get all the important work done and our implementations go smoothly. I no longer spend every evening on a bridge call trying to figure out why something is not working. And I come in the next morning refreshed and productive. My week is in a box.’ This was the result in just a few months.

It can be tough in IT with the press of production incidents and the pressure of critical project deadlines. Add to that our everyday distractions of email and mobile devices and trying to keep up with the pace of technology and we soon lose the forest for the trees. Perhaps the best treatise on this effect is in ‘The Seven Habits of Highly Effective People’ by Stephen R. Covey and his time management matrix.  By leveraging this knowledge of techniques to ensure we work on the important things versus the unimportant but urgent, you can be a better manager and your teams can be more successful and have their week in a box. You might even buy copies of this book for your managers so they understand what is happening themselves and learn personal techniques to address it.

All of us undoubtably, have had some experience where we felt trapped in an overwhelming level of work and no real way out. How did you solve this? Do these approaches resonate with you? Have you employed them to change your team in a sustaining way? I look forward to hearing from you.

Best, Jim