Confronting our fears on empowerment

I've been writing cover letters lately and the word "empower" keeps coming to mind (I'm doing my best to not use the word more than once per letter). Leadership articles have been talking about the need to empower employees seemingly forever, and yet we still struggle to make that a reality. Why?

To be sure, any number of leaders, when asked, will say they empower their employees. At the same time, employees seem to often lack two key aspects of empowerment:

1. Clarity of decision-making rights -- "do I get to decide what to do or do I have to escalate?"
2. Flow of information -- "do I have access to the information I need to make a decision?"

Not so coincidentally, these are also the top two characteristics found in companies that excel in strategy execution. After all, empowered employees should be implementing the corporate strategy and realizing its goals, right?

So why are we as leaders getting in the way of truly empowering our employees? It seems to come down to fear in multiple forms:

1. Fear of failure -- As leaders, our performance is linked to our employees' performance. If they fail, we fail. So we try to avoid failure by stepping in at what we may think are crucial, but infrequent, intervals to "steer the ship" in the right direction.
2. Fear of losing control -- Related to the previous point, our employees are doing most of the work on which we'll be appraised. What if they do that work differently than we might have when we held their jobs?
3. Fear of not being perfect -- When our employees define and do the work, they may not do it as well as we did when we had that job, and the results might make us look bad to our bosses because it's not as buttoned-up as we might have done.

These fears can be palpable and employees pick up on them from our behavior. Even something as innocuous as "I'd like to review your work before you deliver it to [client|boss]" can convey the message that you don't trust the employee to do the job well. More heavy-handed examples include, "Run that decision by me next time before you act," and, "Loop me in whenever something new comes up." All of these can indicate that we as leaders are afraid, or at least unwilling, to empower employees.

And the impact? At first, a team paralyzed by fear we caused and employees who never learn to take initiative or make a decision. More importantly, an organization dependent on its leadership to make all decision, with everything being escalated. When that happens, the organization can move only at the speed and strength of a handful of people rather than at the speed and strength of everyone.

Moving past this doesn't mean letting go of those fears. Rather, we must recognize that they exist, that we have them, and that they need conscious action to work through them. Those actions might include:

• Being open with your team and colleagues about it. Acknowledge you need their help to call you out when your behavior reflects your fears.
• Defining and sticking to new behaviors that change the dynamic. For example, I've struggled with overly wordsmithing documents and communications to the point where my "track changes" are an inside joke. So I started to hold back on "track changes" and focused on using comments to ask questions instead.
• Push your employees to make decisions. Sure, they can come to you; when they do, don't give them the answers! Ask questions that make them work out the best answer for them. By doing it in front of you, you can also assuage your own fears about whether their decision aligns with your thinking. 
• Share information, even if you think it's over-sharing. Yes, information is power, and shouldn't your team be powerful? It also builds trust and confidence, minimizing the risk of sensitive information being inappropriately disclosed.

Over time (usually less than you think), your employees will consistently and confidently make the right call because they learned how to do it and were given the information and space they need for learning. As that solidifies, your team will take care of running things so you can focus on the work only you can do.

---

More information: Empowerment in the Workplace: Definition and Best Practices (Smarp)

Being new again

I just started a new job as a nonprofit institution's CIO, leaving my last employer after almost six years. I'm excited for many of the usual reasons, but one of the biggest short-term drivers of my enthusiasm is that I get to be "the new person" for a while. It's one of my favorite roles to play in an organization, for several reasons:

1. New people are more likely to get time to learn.

Being at work usually means, well, getting things done. There are tasks to complete, deadlines to meet, meetings to attend, emails to answer, and so on. The day-to-day grind can keep a person so focused on the immediate matter or locked into the Pavlovian call-and-response of the email client that taking time to learn (or even think) simply falls off. It's not inherently bad, but needs to be acknowledged.

New people don't yet have all those things to fill your calendar. Instead, they have a lot of information to take in and parse. The organization is new, and perhaps the industry is as well. Colleagues need to be identified and met; history needs to be articulated and contextualized. This all takes time, and the first days/weeks/months are the most likely time to get considerable time to devote to this.

2. New people can ask all kinds of questions.

Organizational culture usually includes a certain amount of jargon and shared information specific to that entity. With that comes an expectation that each person understands why things are done the way they are. After all, each person is part of the organization, right?

New people fall outside this model, to their (and the organization's) benefit. New people can ask, "why is [thing] done this way?" and challenge conventions through honest inquiry. In the best-case scenario, this yields affirmation of well-working practices and thoughtful conversation and follow-up on practices in need of change. The new person can even help make an immediate impact by being part of those changes, during which they can demonstrate the capabilities and experience for which they were hired in the first place.

3. New people can determine their story.

Joining a new organization is significantly different than taking a new position in the same one. In the latter case, the social network and institutional knowledge are already in place, and colleagues are more likely to already know you and your story. After a while, this can sometimes be a hindrance: a person ascending to a leadership role may have to deal with perceptions formed far earlier in their career.

New people have virtually no story on arrival. At most, there are impressions from the interview process and any announcements made organization-wide. There certainly isn't the unabridged history from the previous organization(s). As a result, new people get to decide their story and how to reveal it over time. Maybe great achievements need to be adopted or lessons from past experiments need to be learned. Maybe a particular mindset needs to be set or affirmed, reinforced by past examples. A person has great influence over their professional identity, and this is most true in that early period with an organization.

4. Newness is fleeting, but it's great while it lasts.

Of course, one can't be new forever. Work has to get done, after all. How long newness lasts depends on the culture -- sometimes it's measured in weeks, while other times years can go by to still be new. No matter the duration, it's a thrilling time to learn everything, ask good questions that foster conversation, and get established in the best possible way.

---

Much of my thinking on this topic comes from Damon Phillips' class on network structures when I was at Chicago Booth. I took this class in my first quarter, and have gone back to it in each of the four organizational moves I've made in the past ten years.

Taking the leap

It's been too long.

The primary reason for the long gap in posting is the focus of this post. Back in May 2011, I posted on the cloud operations model, building on excellent discussions among the Clouderati. At the time, I provided a few possible outcomes of moving to this model, including:

• 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.

At the time, I was just starting to think about how these might work in my workplace. As a large, distributed enterprise, the cloud operations model seems to make a lot of sense. At the same time, it's not a familiar framework and would require a lot of work and some success to get going. So for the past several months, off we went:

1. Build an initial community: More or less by definition, a cloud-based model requires multiple parties to participate. That meant someone to actually run the cloud and tenants to use it. Thankfully, others had similar thoughts and from there, an internal group started discussing what we wanted to achieve and how we go about showing others this whole cloud thing was for real.
2. Get a cloud, any cloud: For reasons previously discussed here, going directly to the public cloud is not an option. However, we already had the components of a small private cloud, using a minimum of available hardware and software. This allowed our small team to both try out the technology aspects and start identifying the "ground rules" for a more scalable version. During this proof of concept, we also found our community strengthened through shared goals and effort. More to come on this in a future post.
3. Reorient the IT team: Having the cloud is an enabler, not the end-goal. Achieving the second and third bullet points requires change to the organization and reorientation of mission, values, and roles. The last four months have seen a lot of time spent on the question: How can IT deliver high-impact outcomes to the mission of our organization? Historically, we'd spent most of our energy on ensuring basic productivity, which was (and continues to be) core to our mission. But now we can use our move to cloud to start refocusing our time on identifying, articulating, and analyzing organizational needs, and then connecting those needs with existing or new services in our environment or in the marketplace.

So what's next? We just started on items 2 and 3, and though there's a lot of enthusiasm, we need to convert that to staying power. The IT team needs to train on new skills, from systems/applications administration in a cloud setting to business analysis and consulting. We need to spend time with our customers to show them the benefits of the new model and create some successes. Our systems management needs to be simplified to match our needs. These are all reasonable to achieve, and well worth the effort on our way to establishing IT as an enabler for our organization.

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.

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.