Building the Nimble Team - Retaining Talent

Over the years, we noticed a pattern where really talented, early career hires achieved success in the first 1 to 3 years, and then failed to thrive. It happened probably with less than 10% of hires in that category, but those staff members represented new skills, fresh perspective, and diversity of thinking.   It was not what we wanted to see; we want to retain new hires.  We have been thinking about this challenge and working to improve.

We generally notice the issue with the first technical or project transition. The individual will not successfully navigate to the next project or the next technical knowledge base. This is critical, because a technical career will require the ability to change directions many times over the life of the career. I noticed this blog presenting more of the perspective of the person who didn't succeed. There are perspectives specific to the Microsoft situation, but there are some general pieces I'd like to note.

The author, Ellen Chisa, is very frank about her experience.  She describes that she "put a lot of pressure" on herself to do well. She wanted to be excellent. The problem I see, from my very ancient perspective, is that this excellence demand totally existed in her own head. She didn't take in any information from other people about what excellent was, or even if excellence was something that management wanted to bestow on other people. A big red flag statement to me: "It's strange to feel like you're failing even when you're promoted." So the organization values you, gives you a promotion, but you cannot take in and absorb that success.

Note that she describes a "plummet" that starts when "it was time to move on to something else." She had to learn new things but "For some reason, that didn't happen."  This is the situation we've encountered as managers in our own organization.   As leaders, we need to learn to recognize it early and help people make transitions.

There are actions we should recognize.  A person who expresses fear that they are not succeeding, and does so periodically, even though the supervisor feels that the person is successful and the team respects the person's contributions. A person who becomes emotionally undone at their first failure should be a red-flag. A person who has been successful in their job, but with a change - a technology upgrade, a new project - is suddenly having problems. A person who has trouble starting on a new task. There are different types of initiative. You may see someone who can demonstrate initiative and self-start with something that they are familiar with, but become totally frozen when it is something new.

If you observe those changes, there are definite things we can do.  For one, we can emphasize values along with success and recognize those values in failure.  For example, one value is learning.  We can celebrate what we learned from failed projects.  Thomas Edison once said "I have not failed. I've just found 10,000 ways that won't work." If we want to encourage staff members to experiment and learn, leaders need to identify what we learned. Discovering what path not to take is very important to long term success. When an employee starts expressing concerns about failing, start emphasizing conversations about what has been learned so far in the effort and how the organization will benefit from that learning.

When an employee expresses the "feeling of failing" even when the employee is meeting all standards of success, we have more personal discussions.  I've found it useful to discuss the unique contributions the individual made to the organization, and how those contributions link to bigger goals and initiatives. This isn't one conversation, in my experience, but a way of working with that individual over time.  It helps to thank the employee for his or her contribution in very specific messages.

The book Leading Geeks has other suggestions. Author Paul Glen describes characteristics of information technology work.  He suggests that failure is normal, ambiguity rules, and figuring out what to do can be harder than doing it.  Those early in their career can struggle with these ideas.  After spending time in the classroom, I have some sense of why.  In class, students are often given a defined project to complete in 15 weeks.  If they follow the defined path, they will complete the project successfully, some with more success than others.  Then they come to work and we cannot tell them where to start or what done looks like on many projects.  We have to discover the path and conclusion in a way that we do not in a classroom setting.  There has to be some comfort in just diving in, and finding out two weeks later that there was a better starting point.  If we find a staff member showing signs of inability to start, it helps to pull up a chair and dive in together.

Leaders building nimble organizations need to identify people having these difficulties as early as possible so everything can be done to help and retain that employee.  I think important responses are to talk about all values, including learning and contribution, not just the value of completion success. Also, monitor inexperienced employees as they go through their first transition, whether it is a new technology, a major upgrade, a new project, or a new team assignment.  Talk about their responses to change.  When an employee is demonstrating what looks like a lack of initiative, pull up a chair and question details while getting hands on the keyboard or some similar engaged activity.  Have sincere conversations about contributions and values.  I've found these actions to help.  Please share any ideas you have.

Anchor or Wings?

Is your strategic plan an anchor or a set of wings?  This is a very important question for CIOs to consider if they are trying to be nimble, agile, and responsive to organizational change.

An anchor drags you down, locks you in place, and keeps you from drifting away.  This may be a good thing if your IT team feels overrun by requests, coming from all directions.  After all, our organizations cannot be all things to all people at a moment's notice.  A strategic plan that has broad organizational support can sift out the high priority projects.  A strategic plan provides focus.

But strategic plans are often another dot on a trend line of known items. If you created a five year IT strategic plan in 2009 and are just finishing that plan, your original plan probably did not address the impact of:

• iPads, introduced in April, 2010
• Server virtualization (major players introduced products in 2009-2010)
• Educational model changes like flipped classrooms and MOOCs

That kind of long term planning had its place in the past, but it does not work in today's high speed change environment.  Our educational environments, and specifically our supporting IT organizations, are not in a position to reject game-changers like iPads or flipped classrooms.  Instead, we need to embrace change.

Black swan events, those unpredictable events that change our world, happen. If you hold firm to the multi-year strategic plan in order to control demands on your organization and provide resource alignment, you can become out of touch with technology directions, and miss opportunities to be nimble.

In his book The Black Swan, Nassim Taleb describes black swan events as having three principal characteristics:

1. The events are truly unpredictable.

1. Massive impact occurs from these events.

1. In hindsight, we use trends, narratives, and history to make the randomness of events appear more predictable.

Taleb describes the "triplet of opacity" (p. 8):

• "the illusion of understanding, or how everyone thinks he knows what is going on in a world that is more complicated (or random) than they realize;

• the retrospective distortion, or how we can assess matters only after the fact....;

• the overvaluation of factual information and the handicap of authoritative and learned people..."

We may get pulled into thinking that if we truly follow and better track the trends, and we plan more effectively, our IT organizations can feel less yanked around, less like a flag blowing in a strong wind. We can become enamored and protective of the plan, and closed to the idea of making changes along the way.

But perhaps instead, we should embrace that strong change wind and stop seeking an anchor.  Sailors constantly adjust their sails to changing wind directions and conditions.  Or let's think about the balance of forces needed for flight:  drag, gravity, thrust, and lift.  We just cannot be nimble if we only think about drag and gravity with our strategic plans.  We need to build in the balancing forces of thrust and lift.  We need to make sure that using a strategic plan as a project gate-keeper does not stop us from embracing exciting change.  In a recent NYT article Management Be Nimble, Adam Bryant identified six organizational drivers that are commonly described in cultures emphasizing innovation.  The first item was to create a "simple plan":  "One of a leader’s most important roles is to boil down an organization’s many priorities and strategies into a simple plan, so that employees can remember it, internalize it and act on it. With clear goals and metrics, everyone can pull in the same direction, knowing how their work contributes to those goals."  

Perhaps, then, it is our ability to lead through synthesizing ideas and breaking down complex plans. Those actions give us the thrust and lift needed to be nimble.  We need to be willing to change plans and directions, and do so quickly.  On our campus, we are experimenting with an evergreen three-year technology plan.  We will always be in year one of a three year plan; we will have the flexibility each year to visit our issues.  We see this working more like New Media Consortium's Horizon Report.  We will have to work to build ongoing technology connectedness, making sure projects come to completion, but we need to make sure we balance with action and lift - those things that provide a quick change in direction.

Sensitivity as an Organizational Resource

When reviewing articles about organizational nimbleness and agility, two factors that consistently emerge as positive response mechanisms are:

• quick response to strategic opportunities, and 
• integrating the customer voice.  

That means as CIO leaders, we need to develop staff members who recognize, inform on, and utilize strategic opportunities.  We need to identify and encourage staff members who discover and listen to the customer voice.  The most valuable team members are those who can see opportunities, hear what our constituents want, and connect the dots to build organizations that are ready to contribute to achieving university goals.  I call this ability "professional sensitivity."

The definition of sensitivity includes things like "an awareness and understanding of the feelings of other people" and "the capacity of an organ or organism to respond to stimulation."   Another reference suggest a definition of "readily or excessively affected by external agencies or influences."   These attributes can be a positive resource in an organization.  Teams that are sensitive to the feelings of people using technology are often more service oriented; we know, for example, that an important skill for service desk staff is empathy for the caller.  IT staff members that recognize new external trends early and quickly, like the impact of iPad introduction in educational environments, are more successful contributors.  If we combine the concepts of professional empathy, responding to stimulation, and readily affected by external agencies, we can see that this professional sensitivity is a positive asset in an IT organization.  An IT organization that is going to be agile in supporting the university must demonstrate professional sensitivity.

I'm sorry to use the phrase, but have you worked with someone with a reputation for being a workplace zombie?  Someone who just goes through the day and doesn't seem to know what is going on around them?  They may be able to contribute technically, but they are so unaware of what is going on around them that you have to constantly connect dots and describe rationale.  What they produce might work technically, but you find yourself asking "why in the world did you do it that way?" because the solution doesn't connect.  They make suggestions that seem out of touch with current workplace reality. 

To make sure we develop staff that demonstrate professional sensitivity, we can focus on three areas of skill development:  analytics, awareness, and negotiation.

Educause describes analytics as the tools, techniques, and solutions "used in a higher education environment to analyze various collected data points to gain insight and make informed decisions about complex issues." Educause presents a lot of material to support organizational development of an analytics culture.  For IT organizations, we can look at meaningful data collection within our organizations.  Also, participation in national surveys such the Educause Core Data Service survey and The Campus Computing Project survey, is important.  Encouraging staff members to analyze and comparing results of those surveys to their own environment is important.  Time is needed to develop skills that recognize data patterns and trends, and such analysis is often improved by group review and discussion. IT organizations that are fully analyzing and utilizing trends are better prepared to jump on new IT projects in effective and positive ways.

Awareness is observing what is happening around you; it seems so obvious.  But are all your IT staff reading a variety of news sources?  Are they participating in communities?  I remember having a staff member who was really struggling in producing quality work.  The work was done, but it didn't meet requirements.  I finally asked the staff member to write a self-evaluation describing each step he had taken; I was stunned when I read it.  The entire self-analysis was "I thought about this, then I did that, then I tested this."  In the entire self-analysis, there wasn't a single point when the employee had involved anything or anyone else outside himself.  There was no source of diversity of thought, including no involvement of the diverse backgrounds of fellow team members. Strong awareness skills develop when staff members can take those external sources and recognize patterns.  A good example of awareness that I've written about before is Bill Cunningham and his On the Street series in the New York Times. Intense observation adds greater perspective to analytics and trend analysis; observation and awareness can be current and forward-looking, while anaytics, with its data focus, can be looking backward and using a trend line.  A trend line would not have told us about the iPad impact, but observation and awareness does inform us.

Finally, professional sensitivity requires strong negotiation skills.  Negotiation skills involve empathy and a strong appreciation for another person's position.  We need to navigate decision processes by finding paths that allow everyone to win.  By being empathic, and finding win-win scenarios, we avoid wasting time on unimportant details and disagreements over direction.  This allows us to be nimble, moving in positive directions with speed.  Negotiation requires that we are successful in persuading others to appreciate our position as well.  An interesting recent article talks about how we need to think about our persuasion skills, for example, "When trying to persuade, a study says, stop at three claims." (The Power of Three)

Developing professional sensitivity as an organizational resource, something that we bring forward and utilize in projects, is an action a CIO or IT leader can do.  By investing in developing this resource, the result is that the IT organization improves its ability to be agile and nimble in change-disruptive environments. 

Adaptability and Initiative Capacity as Resources

Earlier I suggested a model for leaders to use to assess agility and nimbleness in their IT organizations. To create the IT organizations that contribute to our higher education organizations in a time of significant change, we need to be fast to react, implement, and change in our technical environments. As a CIO, I cannot just say "think faster" and "respond quicker" and "change faster."  I need to identify and build the resources to enable that sort of nimbleness.  I suggested these resources needed to be identified and enhanced:  time, human capital, funding, space, knowledge, sensitivity, initiative capacity, and adaptability.  Some resources are easier to understand, like funding and human capital.  Other resources, like adaptability and initiative capacity, are harder to assess and develop.

As an IT leader, have you ever encountered that staff member who was enamored and protective of an IT system that had outlived its usefulness?  I have encountered this several times in my career. The first was a highly talented employee who believed that all MVS terminals should be under his control, even when the automotive employer wanted to distribute controls to speed growth. Then there were the developers who believed in continuing with full system development, even after the university decided that unmodified package implementation was the preferred direction. There were other developers later who insisted that only mainframe technologies were worthwhile and client-server had no future. There were talented staff members who simply could not adapt to changing technology frontiers.

Also, there have been moments when I've approached a team about what should have been an exciting new project, only to be greeted by silence and heavy sighs.  Fortunately, this has been rare, but it is very difficult when a high functioning, highly talented team lacks enthusiasm for a new project.  It seems to happen most when the normal cycles of project start, peak, fade are lost in a swamp of never-ending work.  When teams are stuck in the Star Wars scene where the characters are just trying to get on top of the trash pile, another exciting new project is just one more thing on a pile of stuff that is over-whelming.

As the CIO, I need to make sure that I take actions to develop adaptability and initiative capacity in the organization.  How do I do that?

Encourage staff members to develop personally, so that their identity is not wrapped up in one system or project.  Don't allow staff members to become so personally identified with a system or project that they cannot let it go without suffering abandonment and personal identity issues.   Encourage staff members to develop a full career, with a variety of tasks and projects.  We cannot just assume they understand that a project on which they spent hundreds of hours and achieved personal accolades will fade and die some day.  We need to help our staff members see that trajectory, and reaffirm their career value and contribution even when a system is eventually discontinued.

Reward change acceptance, even if it is just acknowledgement during reviews or public presentations.  Provide greater acknowledgement to those who lead change efforts.  And reward staff members who close down older systems and environments.  Recognition cannot just go to the start-up of something new, but it also needs to go to those who take on the important work of closing down and letting go of the old.

Assess the capacity for a team to engage in a project.  They may not have the energy or enthusiasm for a really needed project.  Can you rework teams to provide fresh energy?  I find adding student employees, for whom a project is new, can reinvigorate a team that is growing weary.  Timing a project can be key; capacity for a new project may not be there in December, but the same group may welcome it in May if there's a slow down in day-to-day tasks.  Perhaps some effort needs to be put into clearing the deck and finishing some projects, then allowing for a bit of a gap to breathe and think, to create mental and energy capacity to engage in some new critical endeavor.  We build in a day to pause at the end of December, as an organization, and I'm looking for ways to bring pauses into the year.

As a CIO, it is important to recognize that you may have the people, the time, the money, and the knowledge to engage in a project, but still not have adaptable staff with the initiative capacity to take on the work.  We need to make sure we assess and develop those resources as well.

Building Agile Organizations: Common Good Services and Adaptibility

The economic downturn in the business world generated business commentary that can be useful for today's changing higher education market.  "The agile organization puts its 'non-negotiables'... in the center, while empowering the local units... to be more responsive and adaptive to local markets, customers, and trends." (Outlook 2009 Accenture).  Let's take that statement and consider how it might work on a campus, with centralized and decentralized information technology operations.

What are our "non-negotiables" that we believe must be part of central IT?

How can we encourage local support to be responsive and adaptive to department needs?

Let's look at each of these questions.  Non-negotiables are those IT solutions and services that benefit the campus community.  The higher education IT organizations appear to favor the term "Common Good Services," originally attributed to the University of Minnesota.

Purdue University provides a nice example of how they use the idea of central services to make organizational decisions in their document Common Good Services Philosophy.  In that document, they speak about the recognition of core services:
""Common Good Services" refers to that set of basic, non-specialized computing resources that is
beneficial for nearly all members of the Purdue community.  Common Good Services are those
basic information technology services that most community members would agree are critical to
conducting business (academic, business, student, and research) at a modern research university."
These services are always on and not customized to a specific department.

The University of Texas at Austin uses the Common Good list to identify services that are funded and available through a core data and network charge, so there's an established funding link.

I like how these organizations have identified those core services and clearly linked them to their specific applicable funding models and to their decision processes.  Also, using the philosophy to explain why something is centrally funded versus funded by a local department is very useful.  

How can we use this to enhance an adaptive IT organization?  By clearly establishing the solutions and services that are core and part of the common good, we are transparent in priority setting and funding models.  We can use this to explain how we spend our budget funds, as so much of what we maintain for the common good can lack transparency to senior leadership.  

Common good services provide a consistent service level, in a practical way.  Faculty members and students, walking from one academic building to the next, can expect a consistent level of network services, for example.  Redundant processes and duplicative costs are removed, freeing resources to work on other priorities.

The common good services can provide a reliable, consistent, and stable foundation on which to build more responsive and adaptive solutions at the edge.  If we provide a consistent core, and then encourage local units to build responsive and locally customized solutions on that foundation, we can promote organizational adaptability and responsiveness.  The Outlook 2009 Accenture article on agile organizations suggests:

"The bureaucracy that results from an overly centralized model can stifle innovation and result in delayed market responsiveness.  On the other hand, an overly decentralized model can result in inconsistencies in response, slower product development, organizational redundancies and excessive costs."  

On my campus, while we've clearly identified our core services to our community, we haven't done as well as Purdue in documenting the philosophy.  I can see where doing so would help our community understand what is centrally funded and what is at the edge.  It would also help our IT managers understand how certain decisions are made and how they can help work with that model.  This will be a step in our process of building a more agile IT organization.

Resources for Agility: Knowledge as a Resource

I suggested that we need to track resources beyond the typical project management trio of resources of time, people, and budget.  If we are truly building agile and nimble IT organizations, just tracking those three items (time, people, budget) will not create the environment needed for success.  The consumerization of IT is making it easier for the departments we serve to simply bypass the university IT organization.  Policy that forbids bypassing central IT will only work so far and so long before our communities determine that IT simply is an obstacle to their own success.  We need to offer our constituents options that compare favorably to externally provided resources, or when that isn't possible, we need to offer valued-added services in the selection and management of externally provided resources.  Simply comparing time, people, and money resources on projects will not yield a full description of any service.

Another resource we need to track is knowledge, as represented in the skills and talents held by our IT staff members.  For example, we may have the right number of people for a project.  We may have managed the project portfolio so there is time to execute the project.  There may be adequate funding for the project.  But with the device and software proliferation we are seeing in the industry, there may not be adequate knowledge to execute the project.  In prior times, we likely would have embarked on a technology training program to bring our IT staff members' skills current to the technology direction. But if we do that today, how well will we compare to a service-provider who can start the project today because they already have the skills?  Can our communities wait for us to retool?  So knowledge is another resource we have to track.    

What does it mean to track knowledge as a resource?  We need to keep technology skill inventories so we know the list of skills that are present and ready to use.   When we hire for a position, we need to identify the organizational skills gap and we need to hire to fill a skills gap.  But increasingly, we also need to hire people who demonstrate an ongoing ability to learn, to add on skills, to up-skill their current knowledge, and do so at a pace that matches the environment.  

The hiring process needs to emphasize the selection of an employee who can demonstrate the ability to personally manage many skills.  For example, hiring a strong and specialized Oracle database administrator may fit an organizational requirement.  Likely our interviews and selection process emphasize Oracle database management skills.  But really, to be successful, that DBA also has to be adept at managing modules that are installed on premise and modules operating in the cloud, managing e-mail, managing workload in a ticketing system, processing system downloads, communicating system needs to a VM / storage architect,  articulating identity management and login protocols, and reviewing firewall rules with a network security engineer, among other skills.

Let's review how baseball teams select players for whom they wish to trade.  Maybe a team manager starts by picking the position - like first base.  Sure, the team wants a .300 hitter and low error rate.  But when you read about it, they look for hitters that will have high hitting percentages in the particular home ballpark. Does the candidate bat better against left-handed or right-handed pitching? Management will look at how well that hitter hits in the post-season or at various positions in the batting order. Management may dig even deeper, looking at fielding percentages in different player-on-base scenarios.  And so it goes, digging deeper and deeper into the stats to see exactly which player is really the best fit.  

I'd like to get to a point where we know all the "specialized skills" and "deep skills" that we need in our IT organization.  Also, we should analyze technology directions requiring new or upgraded skills, and have that articulated into our skills inventory.  The skills inventory also needs to identify gaps and match gaps to hiring and training processes.    Our training programs need to be looking out and building training plans for each employee that builds added skills, not just replacement skills, into the future, filling gaps in our inventory.  Employees that can handle this level of adaptability over time and quickly respond with new skill building are going to be the valued team members.

I wonder if we can use our growing knowledge of analytics to managing knowledge as an IT organizational resource.

   

Creating the Agile and Nimble Organization

I have been thinking about the challenges we are facing in our colleges and universities, and how to build the teams and the IT organizations that are ready for future challenges.  Martin Ringle, CIO at Reed College, and I have chatted a little, and Marty extended an invitation to present and participate in a strategic discussion at the NorthWest Academic Computing Consortium (NWACC).  I accepted with pleasure; I thought the interaction with such a talented group of IT leaders would be inspirational (and it was).

Knowing that I needed to be ready was the best motivation to pull my ideas together.  First, all the talk about MOOCs and cloud computing had pushed the idea that our organizations need to change. There are many articles about higher ed IT being in a period of transformation; for example:

"A Transformative Period:  Is Higher Education IT Having an Identity Crisis?"  Grama, Joanna Lyn. EDUCAUSE Review Online, June 2013.
 
If we are indeed in a transformative period, a different organization model, one that is more nimble and agile (not to be confused with formal agile methodology), would be better equipped to be successful.   If that's so, what are the characteristics of an agile and nimble organization? How do we know when we have fully addressed those components?  I'm going to make that the focus of my blogging efforts for a while.

I started with a basic review of business literature and found these documents from the business world:

❖Blanchard, Stacy, Cheese, Peter, Silverstone, Yaarit, and Smith, David. (2009, October).  "Creating an Agile Organization". Outlook: The Journal of high-performing business. http://www.accenture.com/us-en/outlook/Pages/outlook-journal-2009-agile-organization.aspx 

❖Project Management Institute. (2012). "Organizational Agility".  PMI's Pulse of the Profession. http://www.pmi.org/~/media/PDF/Research/Organizational-Agility-In-Depth-Report.ashx

❖Selingo, Jeffrey J. "Attitudes on Innovation: How College Leaders and Faculty See Key Issues Facing Higher Education," The Chronicle of Higher Education, 2013

❖The McKinsey Quarterly. (2006) "Building a nimble organization: A McKinsey Global Survey".  The McKinsey Quarterly.  http://leadway.org/PDF/Building%20A%20Nimble%20Organization.pdf

The business world experienced this transformative state after the 2008 economic crisis.  The literature from that realm suggests the following response mechanisms as key success components:

• Quick response to strategic opportunities
• Shorter decision cycles
• Focus on change and risk management
• Integrating the customer voice
• Building interdisciplinary project teams

From those readings and analyzing other general news comments, I've built the following list of components that I am calling the "Agility Resource Model":

These eight characteristics would represent the resources we need to manage if we are to create agile organizations.  The numbers, for now, are placeholders indicating an equal slice.  I am working on building a model behind the resource display that would allow an organizational leader to do some assessment and analyze how well leadership is addressing each of the eight resource factors.

Those who traditionally manage projects will recognize the time / people / money resources that are managed in any project.  But if we are creating organizations that need to be resilient and response in changing times, we cannot limit our thinking to those three resources.  Transformative periods, characterized by turbulence, instability, and ambiguous, unknown futures, require organizations to be nimble.   IT organizations need to present adaptability in addition to speed; they must be quick to adapt. We need to change tactics and direction quickly, and once headed in a direction, we need to maintain a fast pace.  We need to demonstrate responsiveness to impacts that will inevitably occur; we need to respond, not panic or succumb to being overwhelmed.

Over the next few weeks, I'll explore this topic in more depth.  As always, I appreciate your comments and feedback.