About two hours after my last post on changing the IT organization, I realized I had started from articles on strategic change to go toward tactical moves in team change, but I hadn't talked about the real place to start: with oneself. Possibly the most important lesson for any manager is that you cannot change another person; you can only change the situation for that person in the context in which you have influence. He/she must then determine that change is necessary and that effort will be taken to achieve the change.
And yet we talk about change as something that can be imposed on an organization from above. Task forces are convened to create pithy messages and educate everyone on why change is great and life will be better. Perhaps goals and rewards will be realigned to provide incentives for "getting on the bus." And these are necessary, but cannot be the end of the story. At the end of the day, each person will look to his/her immediate supervisor and teammates for leadership by example, and that's where change really needs to happen.
Too often we get either overly satisfied or complancent with our own behaviors, routines, and ultimately performance. Then, when something comes along to shake that up, we double down on "how it's always been done", making any effort to improve that much more challenging. This isn't because people are bad or lazy; it's just who we are. We are creatures of habit, and breaking habits is very difficult. But hard doesn't equal "shouldn't be done." If people are looking to you to set an example (regardless of position in the hierarchy), you need to ensure you are doing your part to help yourself and your team.
The key is understanding what change is necessary and committing to changing yourself appropriately to support the overall effort. This doesn't mean suppressing your nature or "not being yourself" - instead, find ways to integrate new behaviors with old so that you can still be comfortable with how you present yourself and interact with others. This also likely means asking questions of others to gain clarity, requesting (and receiving) candid constructive criticism, and being very conscious of your actions on an ongoing basis. You may not like the answers you get and may resent those who give them. You will almost certainly find yourself a little drained from the effort of always watching and checking yourself.
Again, none of this is easy to do, and very few of us are born leaders with the requisite talents and skills to guide others toward an improved situation. But people can tell when you're working to change, and will both appreciate your effort and start thinking about their own changes to make. We all lead others in some way, and we all have people who take their cues from us, so are you going to let them (and yourself) down?
Sunday, February 6, 2011
Saturday, January 29, 2011
IT means change, and change means people
An ongoing discussion with colleagues (and in most IT organizations, I suspect) is how best to use the people and resources at hand to deliver services and support to customers. While many on the outside look at IT as being all about technology, the reality is IT leaders and professionals need to continually examine themselves and their teams when figuring out what's next. As Brett Anderson at CIOUpdate.com puts it, "it always comes down to people" when IT change is in the wind.
In the not-too-distant past, IT professionals could find a niche specialization, lock themselves in an office or back room, and happily work in a virtual vacuum for years or decades. Now, the trend toward unified infrastructure, managed IT services, and cloud computing have all forced the question of "what are our IT people actually doing?" to bubble up, and appropriately so. Many services that once required specific and local controls to add value, such as messaging and collaboration, have both become commoditized and increase in value when allowed to take full advantage of network effects. The results are predictable: more institutions are shifting commodity (and sometimes competitive) services to the cloud or other third parties, and IT organizations are getting a little lost in their focus as their world has started to transform.
The general response from experts has been, "Retrain your people and focus them on business-facing issues." Great in theory, but not exactly easy in practice. Though not quite as drastic as turning manufacturing workers into knowledge workers, telling someone who has spent 10+ years in say, systems administration, that now it's time to be a business analyst is not going to help you or your customers. Offering training or guidance isn't enough either; what if being a sysadmin was the end goal for that person? It takes relatively little time or effort to develop routines and habits, and faced with (possibly extreme) change, those routines and habits become both havens and crutches. My hunch is that any IT organization facing change (i.e. almost every IT organization) contains people with varying levels of ability, knowledge, and willingness to redefine themselves in a new context.
And to be clear, we're ultimately talking about people changing themselves. Communicating visions, mission statements, or value lists are necessary, but likely will not on their own accomplish the kind of shift from "support the technology" to "enable the business" that is increasingly required. Even hands-on management has its limitations, as a key tenet of management is that a person cannot change another person. The only lasting change for a person is one that is self-realizing and self-actualizing. A leader's role, then, is to create a situation for each person that helps him/her to understand both what change is necessary and how to start moving in that direction.
If a vision of the post-change organization has not been communicated, that needs to be done. That post-change vision also must include some detail about the roles that are most valuable to the business and what those roles entail. At least as important is communicating the incremental improvements on the road to the end-state, so people can both see how the organization will get to the end and start to understand their role in doing so. Feedback should be encouraged and the incremental steps may need to change over time to accommodate shifting external conditions, though the end-state should remain consistent.
Leaders and managers then need to commit to one-on-one interactions with each person to engage in a personalized feedback loop and aid in understanding new roles and responsibilities as they arise. This will also help managers to assess the person's ability and willingness for change, and create the optimal situation accordingly. Like most management techniques, fairness will not mean equality here; be prepared to adopt different approaches and time commitments for each person. Issues may range from developing analytical skills to improving verbal communication to overcoming fear of failure, and managers must be ready to help address them all.
At the same time, leaders need to find opportunities to extend some of the same techniques into a group setting and have people start helping each other to change together. There is a lot of value in peers finding shared meaning and finding ways to solve common problems, as this ultimately helps people to truly internalize the organization's vision/mission/values. You know you're on the right track when your team comes to you with shared ideas for improvement that they have already started to execute on. Encouraging those results lead to the desired virtuous cycle of continuous improvement.
Re-reading the paragraphs above, it still sounds too easy. It's not - and it's hard because real personal and behavioral change is the hardest thing anyone can do, and your ability as a leader to effect such change is minimal. But it's also the most important thing that can be done to enable the organization to move forward, and often yields more than enough reward to justify the effort.
In the not-too-distant past, IT professionals could find a niche specialization, lock themselves in an office or back room, and happily work in a virtual vacuum for years or decades. Now, the trend toward unified infrastructure, managed IT services, and cloud computing have all forced the question of "what are our IT people actually doing?" to bubble up, and appropriately so. Many services that once required specific and local controls to add value, such as messaging and collaboration, have both become commoditized and increase in value when allowed to take full advantage of network effects. The results are predictable: more institutions are shifting commodity (and sometimes competitive) services to the cloud or other third parties, and IT organizations are getting a little lost in their focus as their world has started to transform.
The general response from experts has been, "Retrain your people and focus them on business-facing issues." Great in theory, but not exactly easy in practice. Though not quite as drastic as turning manufacturing workers into knowledge workers, telling someone who has spent 10+ years in say, systems administration, that now it's time to be a business analyst is not going to help you or your customers. Offering training or guidance isn't enough either; what if being a sysadmin was the end goal for that person? It takes relatively little time or effort to develop routines and habits, and faced with (possibly extreme) change, those routines and habits become both havens and crutches. My hunch is that any IT organization facing change (i.e. almost every IT organization) contains people with varying levels of ability, knowledge, and willingness to redefine themselves in a new context.
And to be clear, we're ultimately talking about people changing themselves. Communicating visions, mission statements, or value lists are necessary, but likely will not on their own accomplish the kind of shift from "support the technology" to "enable the business" that is increasingly required. Even hands-on management has its limitations, as a key tenet of management is that a person cannot change another person. The only lasting change for a person is one that is self-realizing and self-actualizing. A leader's role, then, is to create a situation for each person that helps him/her to understand both what change is necessary and how to start moving in that direction.
If a vision of the post-change organization has not been communicated, that needs to be done. That post-change vision also must include some detail about the roles that are most valuable to the business and what those roles entail. At least as important is communicating the incremental improvements on the road to the end-state, so people can both see how the organization will get to the end and start to understand their role in doing so. Feedback should be encouraged and the incremental steps may need to change over time to accommodate shifting external conditions, though the end-state should remain consistent.
Leaders and managers then need to commit to one-on-one interactions with each person to engage in a personalized feedback loop and aid in understanding new roles and responsibilities as they arise. This will also help managers to assess the person's ability and willingness for change, and create the optimal situation accordingly. Like most management techniques, fairness will not mean equality here; be prepared to adopt different approaches and time commitments for each person. Issues may range from developing analytical skills to improving verbal communication to overcoming fear of failure, and managers must be ready to help address them all.
At the same time, leaders need to find opportunities to extend some of the same techniques into a group setting and have people start helping each other to change together. There is a lot of value in peers finding shared meaning and finding ways to solve common problems, as this ultimately helps people to truly internalize the organization's vision/mission/values. You know you're on the right track when your team comes to you with shared ideas for improvement that they have already started to execute on. Encouraging those results lead to the desired virtuous cycle of continuous improvement.
Re-reading the paragraphs above, it still sounds too easy. It's not - and it's hard because real personal and behavioral change is the hardest thing anyone can do, and your ability as a leader to effect such change is minimal. But it's also the most important thing that can be done to enable the organization to move forward, and often yields more than enough reward to justify the effort.
Sunday, January 16, 2011
Who needs to be convinced about cloud availability?
In the wake of Google's announcement that their SLA for Google Apps is now 99.99%, with all downtime (planned or unplanned) counting toward the SLA, the question has arisen: is service availability still a valid reason to avoid cloud services? At this point, the question may be less a matter of numbers and more one of perception and education. For whatever reason, people tend to believe two things about the availability of the technology they own/use, especially in the workplace:
- It should just work, all the time, without any issues.
- If I can see/touch it and know the people who run it, it's more reliable and I know issues will get fixed more quickly.
These sentiments remain prevalent across both technology consumers and IT professionals. Google's announcement speaks to the first point - IT is seen as a utility that is always available to be consumed, like electricity or water. This point is the more rational of the two, and cloud providers tend to aim at educating potential customers about the results of building an infrastructure that understands and accounts for component failure while continuing to provide services. SLAs and uptime figures are published and cited to support providers' arguments, and they generally meet or exceed people's expectations. Indeed, millions of people use a cloud service all the time - Gmail, Facebook, Twitter - and already use these services as utilities: always on and available when needed.
But what about the second point? Why is such value and importance placed on knowing exactly where the technology is and who runs it? In many organizations, end-users tend to know and (hopefully) trust their local IT staff, which makes them more confident that when something breaks, the IT team can be counted on to fix it. People also like to know that they have one or more specific IT people they can contact if something goes wrong, and that they can influence or control the IT people to get the problem fixed.
IT organizations are also complicit in reinforcing the stereotype of the IT organization that can fix anything and jumps at every issue. The idea of the IT "hero" or "wizard" is long part of our culture, to great apparent emotional benefit. After all, who doesn't want to feel like a hero sometimes, especially when being perceived that way can help ensure IT headcount and investment? This tendency absolutely benefits both parties in terms of customer satisfaction, but also presents challenges in moving toward a model that includes the cloud (or any third-party managed solution).
So cloud providers' challenge is two-fold: persuade IT organizations that infrastructure maintenance is not where they can add the most value to their organization; and then help IT to convince their consumers that local doesn't always mean better when talking about service delivery. Helping IT reconsider its position in the organization may require providers to seek partners that focus more on technology strategy, as Google and Microsoft have begun to do, and craft messages in their opening pitches and materials that help IT management visualize their new role and value. If providers can clear the first challenge, IT will likely champion addressing the second.
But what about the second point? Why is such value and importance placed on knowing exactly where the technology is and who runs it? In many organizations, end-users tend to know and (hopefully) trust their local IT staff, which makes them more confident that when something breaks, the IT team can be counted on to fix it. People also like to know that they have one or more specific IT people they can contact if something goes wrong, and that they can influence or control the IT people to get the problem fixed.
IT organizations are also complicit in reinforcing the stereotype of the IT organization that can fix anything and jumps at every issue. The idea of the IT "hero" or "wizard" is long part of our culture, to great apparent emotional benefit. After all, who doesn't want to feel like a hero sometimes, especially when being perceived that way can help ensure IT headcount and investment? This tendency absolutely benefits both parties in terms of customer satisfaction, but also presents challenges in moving toward a model that includes the cloud (or any third-party managed solution).
So cloud providers' challenge is two-fold: persuade IT organizations that infrastructure maintenance is not where they can add the most value to their organization; and then help IT to convince their consumers that local doesn't always mean better when talking about service delivery. Helping IT reconsider its position in the organization may require providers to seek partners that focus more on technology strategy, as Google and Microsoft have begun to do, and craft messages in their opening pitches and materials that help IT management visualize their new role and value. If providers can clear the first challenge, IT will likely champion addressing the second.
Monday, October 25, 2010
IT organizations in the cloud
With all the talk about the technological and financial aspects to the cloud, there seems to be surprisingly little about the organizational implications of shifting services into the cloud. If you don't have as many servers, do you need so many systems administrators? What about software developers or quality assurance people?
The easy, but not necessarily best, answer is eliminating those positions (and therefore the employment of those people). While that is perhaps tempting, a better approach is to consider what roles you'll need to best manage and support your business needs as the IT environment evolves, and then match the smart people on your team to those roles.
Reconsidering the IT mindset
Moving services (or establishing new services) into the cloud is like writing software for the iPad or Android - it requires a very different mindset to manage properly. In particular, a cloud-based service or product is thought to be very easy to support and very fast to turn on. In addition, cloud service providers are constantly releasing new features, driving demand for those features to be enabled in your environment. As a result, end-users' expectations of IT responsiveness for support, changes, and new features will only increase as services are moved to the cloud. Moreover, if IT manages cloud as it has other technologies, end-users are more capable than ever at going around IT to get what they need - indeed, now they can just sign up for a service over the Internet and get people using the service without IT even knowing about it.
To avoid this, IT needs to become more proactive than ever at driving service management to the end-users. IT needs to effectively sell itself as the best channel for acquiring cloud services because it understands both the business and the technology better than anyone else. This isn't a new concept - IT has had to become increasingly business-focused and customer-facing over the past decade. What is new is the ease of acquiring IT services without the IT department's involvement.
Roles and redeployment
The odds are high that your IT environment will move incrementally (and likely not fully) into the cloud. As such, your existing applications and infrastructure people will still need to continue supporting the data center and in-house applications. At the same time, you should start to shift some of your people toward the following roles that will enable IT to become more of an asset to the company for both cloud and in-house services:
- Service Desk- On a day-in-day-out basis, end-users will continue to work most with the Service Desk team. In addition, the ease of configuration often provided in cloud services means that more tasks can be moved to the Service to improve first-call resolution and overall customer (and job) satisfaction. Consider augmenting the traditional service desk analysts with application specialists who can serve as subject matter experts and points of escalation for support.
- Business Analyst- It is increasingly crucial that IT understands business needs, which are rapidly changing as customer demand shifts and technologies improve. Rather than wait for the business to declare their needs, engage directly with each department through frequent meetings and hallway discussions to make sure that (1) their needs are heard and understood by IT, and (2) they understand that they can rely on IT to "get it" and deliver the desired solutions.
- Quality Assurance- Just because you didn't develop it doesn't mean you don't have to make sure everything works before going live. Your QA people understand how to write and execute test cases to ensure a minimum of issues when releasing a new service or feature, which will help in building confidence in moving to the cloud.
- Network Administrator/Engineer- Cloud services require network/Internet connectivity, which is now a mission-critical infrastructure component. IT may spend more time focusing on network performance, monitoring, and maintenance to ensure access to corporate applications.
As you evaluate these and other roles, consider the strengths of your existing team members and identify those that can start evolving into these roles. Next, determine all of the change factors (compensation, reporting structure, etc.) as a result of any reorganization. Then start engaging one-on-one with team members about the possible opportunity to expand and evolve his/her role into the cloud space. Positioned correctly, the response may well be enthusiastic beyond your expectations.
Sunday, October 10, 2010
Building momentum
It's been over a month now since I started my new role as an IT leader. In that time, I've focused on meeting people, learning about the institution and its expectations of IT, and understanding what we do and how we've gone about doing it. It's provided me with key insights when considering both immediate next steps and the overall path forward.
Organizations of all sizes and shapes tend to figure out a way of getting things done and stick with that path, largely out of famiilarity. While this can help to improve the precision of task completion (i.e. the same task is done the same way each time), it also can close the door to different practices and methods. I've long thought that once a group of smart and curious people start really considering their options, they tend to arrive at a new and interesting way to get things done. Getting started with those first rounds of consideration, then, are key.
Like anything else, the leader's role is to motivate others and create the right situation for the team to succeed. This is not an overnight activity - it takes significant time and effort (proportional to the size of the organization) to both communicate a vision and get everyone actively excited about the possibilities of participating in that vision. Moreover, the leader must be consistent in the message and continually find concrete examples that support the vision.
The primary positive effect of this is momentum - the team gets excited about the opportunities to grow and renews its commitment to its mission. You may also find, as I have, that you get excited as well - having these conversations and getting positive responses is motivation to keep working toward creating the situation for continuous improvement and high performance. A motivated group is probably the most important part of what comes next.
Organizations of all sizes and shapes tend to figure out a way of getting things done and stick with that path, largely out of famiilarity. While this can help to improve the precision of task completion (i.e. the same task is done the same way each time), it also can close the door to different practices and methods. I've long thought that once a group of smart and curious people start really considering their options, they tend to arrive at a new and interesting way to get things done. Getting started with those first rounds of consideration, then, are key.
Like anything else, the leader's role is to motivate others and create the right situation for the team to succeed. This is not an overnight activity - it takes significant time and effort (proportional to the size of the organization) to both communicate a vision and get everyone actively excited about the possibilities of participating in that vision. Moreover, the leader must be consistent in the message and continually find concrete examples that support the vision.
The primary positive effect of this is momentum - the team gets excited about the opportunities to grow and renews its commitment to its mission. You may also find, as I have, that you get excited as well - having these conversations and getting positive responses is motivation to keep working toward creating the situation for continuous improvement and high performance. A motivated group is probably the most important part of what comes next.
Sunday, September 19, 2010
Getting it right the first time
I came across an excerpted transcript of a podcast on HP's cloud management software, which included this statement by Robin Purohit, Vice President and General Manager of the Software Products Business Unit for HP Software & Solutions:
Although the source article was ultimately about management software, this holds even more true when talking about upstream processes such as governance and standards definition. Moving to the cloud means empowering end-users with a greater ability to shape his/her environment than in a traditional IT setting. If there isn't at least a basic set of guiding principles to abide by, you can be sure that in a few months the company's account will contain much of the same clutter and inconsistency as is often found in areas like file shares and document management systems.
Defining standards of usage for cloud-based services should be similar to doing so for other services:
Back to the beginning - "getting things right the first time." Your governance structure and standards don't have to be perfect before deploying a service. They should be based on pragmatic understanding of the service, meet the most critical needs to protect the company from legal action or financial vulnerability, and be straightforward enough for everyone to understand and comment on. Feedback should be captured and used to help hone usage standards. Ultimately, your organization should have a usable and fairly created set of standards that are internalized by end-users and will implicitly abide by, reducing efforts for maintenance (such as data gardening and access auditing).
If you think of Agile and the pace at which now new application innovations are bring rolled out, it really means that you have to get things right the first time.I was struck by this initially because "getting things right the first time" seems antithetical to Agile, which is based on a philosophy of rapid, incremental improvement. At the same time, there's also the realization that once a policy or process is released, making changes to that policy or process is very difficult, and such change probably cannot keep up with the rate of change in technology. This is especially true in the cloud, where providers constantly release new features and functionality, almost without warning.
Although the source article was ultimately about management software, this holds even more true when talking about upstream processes such as governance and standards definition. Moving to the cloud means empowering end-users with a greater ability to shape his/her environment than in a traditional IT setting. If there isn't at least a basic set of guiding principles to abide by, you can be sure that in a few months the company's account will contain much of the same clutter and inconsistency as is often found in areas like file shares and document management systems.
Defining standards of usage for cloud-based services should be similar to doing so for other services:
- Identify roles and responsibilities for governance
- Educate governance body on the service and its capabilities
- Draft usage standards and present to the governance body
- Establish a consensus on usage standards
- Communicate usage standards as part of the roll-out and ongoing support
Back to the beginning - "getting things right the first time." Your governance structure and standards don't have to be perfect before deploying a service. They should be based on pragmatic understanding of the service, meet the most critical needs to protect the company from legal action or financial vulnerability, and be straightforward enough for everyone to understand and comment on. Feedback should be captured and used to help hone usage standards. Ultimately, your organization should have a usable and fairly created set of standards that are internalized by end-users and will implicitly abide by, reducing efforts for maintenance (such as data gardening and access auditing).
Saturday, September 4, 2010
Getting to new and improved services
I've been spending a lot of time recently thinking about providing IT services effectively and efficiently and how to make improvements along both dimensions in any given situation. To start, let's look at IT responsibilities in two major categories:
"Keeping the lights on" consist of a series of challenges that have largely been solved within the industry. Quick searching for any facet, ranging from authentication/authorization to service desk management to configuration management, will yield results for processes, tools, and methods. In fact, it's almost overwhelming to consider all of the available options.
The goal is to optimize the efficiency of this category. No one gains a competitive advantage from "keeping the lights on", so we should spend the minimum in resources to achieve the organization's needs for support and maintenance. Bear in mind, however, that doing so will be different for each organization - for instance, some organizations accept a remote call center approach for efficiency, while others demand a high-touch, in-person support experience. When evaluating an environment for efficiency, you should consider the following factors:
- New/improved services - business analysis, projects, research, development
- "Keeping the lights on" - break/fix, service requests, planned maintenance
"Keeping the lights on" consist of a series of challenges that have largely been solved within the industry. Quick searching for any facet, ranging from authentication/authorization to service desk management to configuration management, will yield results for processes, tools, and methods. In fact, it's almost overwhelming to consider all of the available options.
The goal is to optimize the efficiency of this category. No one gains a competitive advantage from "keeping the lights on", so we should spend the minimum in resources to achieve the organization's needs for support and maintenance. Bear in mind, however, that doing so will be different for each organization - for instance, some organizations accept a remote call center approach for efficiency, while others demand a high-touch, in-person support experience. When evaluating an environment for efficiency, you should consider the following factors:
- Variety of technology to support and ability/need to standardize
- Importance of support characteristics, including speed of response and resolution, interaction types (email, phone, in-person), and environment context
- Automation of common tasks
- The people who actually fulfill these tasks, such as end-user support, systems/network administrators, and application support personnel
- Key end-users that require a significant portion of IT's effort for support
- Business leadership that can help articulate overall technology goals and objectives and provide context for technology strategy
Subscribe to:
Posts (Atom)