Interfacing with the cloud

I was having a breakfast meeting with a technology start-up CEO last week, and the discussion turned to user experience and interfaces. He asked me, "What is the best interface you've worked with?" I started thinking through this, focused on my computer, and provided a couple of examples. He nodded, then said, "I'm surprised you didn't mention this", gesturing at our iPhones. After a second or two, I realized the reason I hadn't thought of the iPhone is that I never think of my iPhone - I just use it.

More than Palm's old tenet of "if it takes too many taps, we need to rethink it", the gold standard for interface design should be that the end-user does not need to consider it at all. Rather, the end-user should be so comfortable with using the interface that the focus can then turn to the actual function or process the interface is supporting.

What does this have to do with cloud? Leaving aside the computer-to-computer interfaces so important today, we still have an immense number of Software as a Service (SaaS) applications available for end-users to purchase and consume. Often, these are contrasted with more traditional enterprise applications on the dimensions of cost and feature set, but I think SaaS providers have (and take) an opportunity to also differentiate on interface design, for the following reasons:

1. The interface is the thing for customers - The ongoing consumerization of IT means purchasing decision-makers are not necessarily IT people, but line-of-business managers who assess based on functional needs rather than infrastructure integration. They don't see the software install, database, or infrastructure - they see only the interface shown to them. By removing the infrastructure from the discussion (other than to demonstrate its ability to provide a reliable service), SaaS providers can focus attention on the user interface and how well it will meet those functional needs.
2. User feedback is embraced and quickly acted on - Because the application is not distributed to many independent customer infrastructures, it can be updated as often as needed to meet customer requests. For instance, Rally Software, offering a SaaS Scrum project management application, uses Scrum and releases updates every 6-7 weeks; the updates come directly from customer requests.

I realize this is nothing new, and interface design has always been important. But we still have so many interfaces still incredibly non-intuitive and difficult, getting in the way of actually getting things done, even as the iPad, Android tablets, and even Windows 8 offer a new way to think about how to interact with any application. Hopefully as cloud computing becomes increasingly mainstream in the large enterprise, decision makers will demand the gold standard of interface design ("I just use it") and the market will respond accordingly.

Taking time to lift the curtain

A relative of mine called me earlier this week because she couldn't access any web pages. She had already called her ISP multiple times, but got no assistance. After a few minutes of testing and checking her configuration, I had figured out it was a DNS server issue. Changing to Google's free DNS servers fixed the issue.

As is usually the case, she said, "you're a wizard!" to which I have no real answer. My initial thought was, "no big deal" - pretty standard for someone who works in IT. Then I started to consider how difficult it is to truly adopt the perspective of someone who hasn't spent the past X years in technology - it's too easy to assume that people understand what to do when confronted with a seemingly basic problem.

Why bring this up? Because at the same time, a hot topic is how IT people are increasingly not needed for basic support and need to adopt new higher-value roles. Another is the consumerization of IT, driven by continuing developments in cloud computing. But does the chatter around these topics obscure a widening gap between people who can support themselves and get connected to all these services, and those who cannot? And if so, how to close that gap?

The usual response, which I tend to agree with, is education. Technology is scary to many people, and the first response to the unfamiliar is to freeze up or retreat. Making the unfamiliar and scary less so for customers allows them to re-process what they are dealing with and come up with ways to fit that technology into their business practices.

A blinding flash of the obvious, right? Well, yes, but only in concept. Execution is a whole different matter. To its credit, IT does often include some sort of communication and training plan in any large-scale project or rollout. But what is in the plan? Sending emails, creating web pages, maybe some opt-in training. And while these make offer a wealth of information, they are no substitute for open forums, one-on-one meetings, and required (or at least well-incentivized) hands-on training.

Yes, these are expensive. They take up a lot of time, and need strong leadership to pull off. As the head of an IT organization, I spend a significant amount of time doing just that - conversing with my customers, listening to their concerns, and helping them adjust to new tools. In environments influenced by fear of change, the result (productivity and comfort with changing technologies) is well worth the investment.

The cloud operations model

James Urquhart posted an insightful article on the false debate around whether private cloud is really cloud. By positing the idea of cloud as both a business model and an operations model, Mr. Urquhart opens the door to a continuum of paths to the cloud, regardless of how risk-taking or risk-averse any particular company is.

I discussed this topic last month based on a spirited discussion on Twitter about the validity of private cloud. I used a lot more space to describe what Mr. Urquhart puts into one paragraph (my emphasis):

[I]f you look at cloud as an operations model, the value of running an efficient resource pool with reduced bureaucracy is highly compelling, even if you can't reach the efficiencies of a larger public-cloud provider. Given the complexities of moving data, applications, processes and everything else IT to the public cloud, an internal cloud service becomes a highly compelling option.

Many medium-to-large enterprises have not only computing power that can be more effectively and efficiently deployed, but also a lot of people performing similar, and perhaps identical, tasks in different departments or business units. This may have arisen from various events in corporate history, be it dissatisfaction with company-wide services, political maneuvers, or grass-roots efforts grown wild. The result is the same - lots of people doing the same job, and that job tends to be lower value (maintenance, support) than what is needed (business alignment, service creation/improvement).

In a cloud operations model, sub-units still build and deliver services to their customers as they do today. The key difference is how and where they build those services. The use of a centralized, on-premise, multi-tenant resource pool, even though it's not as elastic as AWS, changes the game significantly in terms of how people think about IT roles and responsibilities. I submit that going to the cloud operations model can have more impact than the move to the public cloud:

• Data center-related purchasing shifts to a single group, who can better negotiate company-wide prices and discounts due to the necessary scale/volume for the resource pool.
• Data center management moves to a centralized team, who can focus on building the expertise and committing the time and energy to being great at it.
• IT people tasked with delivering applications and services can now do so without spending undue time on underlying infrastructure.
• Time reclaimed from reducing data center redundancies and time to deploy services can be redeployed to high-value IT activities that more directly enable business growth, such as researching emerging technologies and business process analysis.

Once this model really takes hold, having meaningful discussions about what, why, how, and when to move to the public cloud can become a lot easier. The business folks have gotten used to a certain decoupling of hardware and services, while the IT organization is better prepared to engage on business-related issues. Most importantly, everyone will have gained necessary experience in rethinking how technology is delivered and managed in preparation for future transformation.

 

How do you get to the cloud? First, get on the road.

I follow the clouderati\all list on Twitter to attempt to keep up with what's going on in cloud, especially now that I don't have specific responsibilities or projects in that area. It's generally stimulating, and given the rate of change in technology emergence and adoption, it's only a matter of time before such projects arise.

One running thread has been something along the lines of "Is private cloud really cloud?" Large enterprise infrastructure vendors want you to say, "Of course - it has cloud right there in the name!" while public cloud providers tell you, "Of course not - it fails the definition on any number of levels!" I tend to lean toward the viewpoint of people working in the public cloud - after all, elasticity is a key tenet and it's extremely difficult (if not impossible) to be elastic in one's own data center.

That said, I'm coming around more and more to the idea of using private cloud-like infrastructure as a "gateway drug" for people to eventually move to the public cloud, especially if it fulfills the goal of better aligning IT with what the business actually does. My organization is both large and decentralized, with IT departments at various levels from historical decisions and funding. As a result, we have what you would expect to find in such a place - many data centers and server rooms, lots of fragmentation in data storage and protection, and an abundance of service duplication.

For a number of reasons, the institution is not fully comfortable with moving its data to the public cloud; it would rather store its proprietary (and often heavily regulated) information on premises. At the same time, we (and presumably we're not alone) continually seek ways to both improve our economies of scale and reduce the risk of data and productivity loss for our internal customers. Establishing a multi-tenancy infrastructure in the institution's primary data center (i.e. private cloud) helps in both cases.

• The burden of infrastructure management shifts from many IT departments to one dedicated group, where they can concentrate expertise and gain higher server/staff ratios.
• The various IT departments, mostly free from hardware, storage, and backup maintenance, can use the gained time to engage with their customers and build/deploy services specific to their needs rather than simply "keep the lights on."
• Business leaders gain more bang for their IT buck, which is made visible through more rapid service deployment and productivity increases.

Once an organization reaches its steady state in a private multi-tenant infrastructure, it's natural to ask, "What's next?" And the answer increasingly will become, "Don't upgrade this system, migrate to the public cloud." IT will be able to show a story (with supporting data) of the benefits of moving from traditional infrastructure to private cloud, and then how those benefits can increase again with the move to public cloud. Though it may not be the most efficient way to get there, it may yield enough initial benefits to make a potentially scary migration more like a logical progression.

Being a manager - easy to describe, less easy to do

The NY Times ran an article a few weeks ago on Google's self-evaluation of its managers and what their employees prize in a manager. A common reaction was, "How could subject matter expertise be at the bottom?", which I can relate to. Another, and possibly more interesting, response, was a blog post essentially dismissing the eight points Google published as "just management, right?" This sentiment is unfortunately pervasive in our culture, going back at least a few decades. After all, everyone knows that the key tenets of modern-day management - results-orientation, communication, coaching, empowering, having vision - are both "not rocket science" and ambiguous enough to avoid any real consequences.

My first reaction was to want to refute such an argument, point by point. Having sat on this for a couple of weeks, I'm less interested in a back-and-forth of the minutiae of the language or even Google's intent in their self-study. I thought instead about what resonates with me as someone in a leader/manager role.

I was drawn instantly to point 7, though it's further down the list. Having a clear vision is not some pie-in-the-sky idea, nor is it the same as having a goal. A vision is a description of an improved future, with characteristics that are achieved through discrete goals attainment. Most people want to be part of something larger than themselves; in addition, people want to know their tasks, whether they enjoy them or not, are contributing to that larger context. Managers are responsible for providing vision and meaning to their team and aligning the team's work to that vision. As initial successes occur, reinforcing the vision helps motivate everyone on the team toward fulfillment.

Though vision is point 7, the six points above it all help support achieving the vision. Managers need to:

• Communicate the vision and reinforce its relevance to the daily work
• Guide the team's roadmap to align projects and operations with the vision
• Act as a mentor to team members and define/guide individual goals that support the vision
• Align individual goals and growth with both the vision and career development needs
• Set expectations, empower team members to act, and expect results that align with the vision
• Provide regular and targeted feedback to help people learn and grow
• Know your team members well enough to help them better understand the team vision and support their needs as they arise

Easy enough, right? And yet stories abound with examples of bad management, and with good reason. Management is a classic "easier said than done" case. It requires constant thought, consideration, and action, and a deep understanding of both oneself and every person on the team. And it may not work out in all cases; after all, understanding people's behavior and motives is imperfect at best, and gaffes are bound to happen. That said, watching a person or team attain a goal they previously thought out of reach, and knowing you helped them understand they could get there, is pretty darn great.

For reference, here are Google's eight points (via NY Times):

IT as a customer-satisfying service

I recently spent a few days in meetings with some of my colleagues and one of our enterprise vendors. The discussions themselves were very productive, and we spent a lot of time talking about "IT as a service." In most IT conversations, this concept tends to focus on delivering IT applications and resources to end-users in a manner that enables self-management, access from anywhere, and a consumption-based financial model. The public cloud, for instance, is emblematic of IT as a service - it addresses all three factors in a way that benefits customers and providers alike. In a decentralized enterprise, IT as a service tends more toward providing IT resources centrally and enabling downstream admins or end-users to build services on top of those resources (e.g. a private cloud).

This approach helps balance many organization's needs for economies of scale and support for specific business requirements, and makes a lot of sense to me. However, delivering technical functions is only part of providing a service. Too often time isn't spent on the things that ensure customer satisfaction:

• Responding quickly and personally to incoming requests
• Following up on initial response with the appropriate communication and action
• Setting expectations for resolution and following through on those expectations
• Ultimately addressing the request quickly and enabling the customer

It's not that people don't think these are important. Certainly, when any person is the customer in such an interaction, these become vital. Ever deal with an issue with your cable, Internet, or phone company? Then you probably can pinpoint when you've been disappointed and on which item(s). And stories abound in general about how terrible customer service is across industries, or at best, inconsistent.

So what makes these so hard to do from the provider side? Or more importantly, what makes these so hard to do consistently? Again, it's not that people don't think it's important. I've rarely met anyone who didn't want to provide at least good service, and most want to offer great service.

More often than not, what gets in the way of providing great service is attempting to provide great service. Stay with me here. For (a somewhat extreme) example, the team may work very hard to resolve an unplanned outage by hunkering down in the server room and getting things up and running again. But at the same time, customers are waiting anxiously for any word on when they can get back to work. If no information is making it to the customer, than is the team providing great service? If you're on that team, you tend to think you are - after all, you were tirelessly laboring on behalf of your customers. But the customer perceives the following:

1. Service is down! I'm going to get behind on my work and have to make that up!
2. What's going on? When can I get back to work?
3. Is anything actually being done?
4. Finally! We're back up! What took so long?

The result? Customers may not appreciate the effort the team went through to restore service, and the team may resent the under-appreciation. Generally speaking, this tends to happen when the team focuses on the first and last bullet points - respond quickly, then address and enable. In between are the equally critical and achievable tasks of communication and expectation-setting. Each person addresses these tasks a little differently, but I've noticed some common themes among people that excel in this area:

• Daily routines that enable communication - "Daily" is key here. At least once per day, emails need to be answered, calls need to be made, and task management systems need to be updated. This can be at any point in the day (beginning, middle, end), but it needs to be every day. A routine done 2-3 times a week is too easy to let slide in an area that requires a lot of discipline. Check out http://dailyroutines.typepad.com/ for some interesting examples of scheduling one's day and setting routines.
• A running to-do list that gets updated every day - You have to know what you're responsible for at any time, and keeping it in your head (and not in writing) usually leads to some amount of slippage. Having a master list, perhaps fed from your task management systems and emails, is very helpful for keeping track of open items. It also allows you to cross those items off the list when they're completed, so you know what you've done as well.
• Communication whenever possible - Typically, any day contains pockets of a few minutes where a quick check-in or update can be completed. You may be waiting for something to happen or be ready to transition from one big task to the next. Use some of these times to update yourself on inbound requests or information, and update your customers and colleagues so they can better manage their own expectations.
• Continual evaluation of one's own service to customers and colleagues - Despite the measures above, it's still possible that something is slipping through the cracks. After all, things do happen throughout the day that are seemingly aimed at undermining schedules and planned tasks. Regular 5-10 minute recaps of your day or week can help you remember anything that wasn't accounted for. 

These items don't make up a perfect solution, but it can help reduce the incidence rate of saying, "I'm not sure where that's at. Let me get back to you." The people around you notice and appreciate the effort of your knowing what's going on and making sure they are also up to date on any given situation. Over time, these tasks become faster to complete and require less effort, allowing you to both manage the technology and enable the customer. In the end, customers are more satisfied with their service and those providing the service are more satisfied with their work and the value they add to their organization.

Companies like Nordstrom, Enterprise, and Rackspace build their business strategies around differentiating on customer service; the question is, shouldn't everyone?

Leading change, starting with yourself

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?

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.

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:

1. It should just work, all the time, without any issues.
2. 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.