Monday, June 27, 2016


One life lesson I carry with me is to reach out and say "Hello" to someone I don't know. That follows from the "Four I's" of building relationships:
  1. Initiate
  2. Inquire
  3. Invest
  4. Inspire

You start a new relationship with Initiate (for example, "Hi there!") and Inquire (such as "My name is —. What's your name?"). Over time, you Invest in the relationship. When you have built up enough currency in your relationship, you can Inspire your new friend to raise the bar or to help you out. This fourth "I" is sometimes called "Influence."

I have made a point of learning how to say "Hello" in different languages. This was a helpful skill when I worked in higher education and regularly met with students, including international students. Outside that setting, I find being able to greet someone in their own language helps to break down barriers, so I can reach out to someone I don't know. Something as simple as "Hello" can create an instant connection.

I can say "Hello" in several languages:
  1. Buenos días ("Good morning") or Hola ("Hello," Spanish)
  2. Bonjour (French)
  3. Ni Hao (Chinese: 你好)
  4. Guten Morgen ("Good morning") or Hallo ("Hello," German)
  5. Aloha (Hawai'ian)
  6. Ya'at'eeh (Navajo)
  7. Buongiorno ("Good morning") or Ciao ("Hello," Italian)
  8. Kon'nichiwa (Japanese: こんにちは)
  9. Yeoboseyo (Korean: 여보세요)
  10. Zdravstvuyte (Russian: Здравствуйте)
  11. Marhabaan ("Hello," Arabic: مرحبا)
  12. As-salaamu 'alaykum (literally "Peace be unto you," Arabic: السلام عليكم‎‎) and the response: Wa'alaykumu s-salaam ("and upon you, Peace")

There is also "nuqneH" (in Klingon) but I don't get many occasions to use that one.

In how many languages can you greet someone? Even if you conduct business in English (BELF, or "Business English as Lingua Franca") you'll find value in saying "Hello" in a different language.
image: Wikimedia: "Hello my name is" sticker

Monday, June 20, 2016

IT organizations must adapt or die

I reviewed an IT status update earlier this week, and it gave me pause. The update mentioned several applications that we are currently replacing or updating. One, I noted, was first implemented in 1998. That's a very long time ago. It's effectively forever in "IT time."

Think about how much things have changed since that application first went live in 1998. Back then, most of us used desktops. Laptops were available, but in the company where I worked, only the CEO and CIO used laptops. They were too expensive for the rest of us. Cell phones were common, but they were big, blocky affairs that only made phone calls.

And of course, we had Windows 98.

Technology is always changing. You don't have to go back very far to see how quickly technology evolves. Ask yourself how things will be different a few years from now.

IT organizations must adapt to constant change, or they will die. Don't be the next CIO who might have brought change. Be the CIO who embraces change.

To be adaptive and responsive, I see three major trends in future IT organizations:

Business partnership is critical
Relationships with the rest of the organization must be intentional and structural. This means processes and roles. IT is the translation point between business needs and technology. CIOs who maintain strong relationships will be able to connect business needs to technology.
Workforce skills must evolve
As technology changes, we need to continually invest in our staff. Shifting from internally-developed and -developed appliations to commodity off-the-shelf systems requires IT to move focus from development to integration. Vendor management must be intentional.
IT must be a leader
The business relies on the CIO to set a direction for technology. Be that leader. IT is uniquely positioned to see across departments and technologies, and can be proactive in recommending solutions and strategies. We may not be able to predict the future of technology, but we can describe the general shape it will take. Provide a roadmap, keep it updated, and tie it to business objectives.

Monday, June 13, 2016

Words to avoid

As part of any manager's role is writing documentation. As a line manager, you might write procedures or standards. As a director you might write directives or vision goals. At the CIO level, I write a lot of executive briefings for other leaders or for our Board.

Over my career, I have learned a few things about effective communication. For example, use active voice. "Passive voice should never be used by you." So I was interested to read "15 words to eliminate from your vocabulary to sound smarter" from Business Insider. As the title implies, these are 15 words to avoid in any communication, written or spoken:

  1. That
  2. Went
  3. Honestly
  4. Absolutely
  5. Very
  6. Really
  7. Amazing
  8. Always
  9. Never
  10. Literally
  11. Just
  12. Maybe
  13. Stuff
  14. Things
  15. Irregardless

Several of these words lessen your credibility. One example is "Honestly." A colleague outside of work uses "Honestly" in his emails. I am sure he means to use it as a kind of "break" in his writing, or perhaps to lend emphasis to his next statement. But I find it often negates what he just said. If you are only now being honest with me, should I ignore what you wrote previously?

Consider what words you use in your communication. A few word replacements can add impact and raise awareness.

Monday, June 6, 2016

About governance

IT can be organized differently, depending on the business. At one end, IT might be the business (think Google). In these organizations, IT is tightly coupled with the business, it is inseparable. Or IT might be autonomous, distributed throughout the organization, where every business unit has independent control over technology. At the other end of the spectrum, IT might be federated, either loosely or tightly, to account for different decision-making. Federated means that a core IT unit coordinates with business units, which may have limited control over specific technology. Or IT can be completely centralized, a service unit that the business treats like any other provider or vendor (I worked at a company owned by a law firm, which treated IT in this way).

No matter how IT is organized, you must always consider how IT is governed. How do you ensure that IT is meeting the needs of the business?

Putting aside the obvious case of "IT is the business," IT requires a method of governance. This governance can be formal or informal depending on the relative maturity of the business and of IT. But at some point, IT needs help to "vet" IT decisions to best serve the needs of the business.

How do you organize your IT governance? Governance can take on many forms, but the general process is that someone listens to business needs, and a governance group prioritizes requests and creates projects to execute them. A simple diagram might look like this:

intake coordinator
work groups

Of course, this is a simple process flow. Other IT governance models might need to account for different inputs, such as executive levels, customers, faculty, business units, and other governance bodies. And the model might have several output paths to assign work, such as different IT units or vendors and partners.

business units
other governance
IT unitsvendorspartners

Your governance model depends on what role IT plays in your organization. Is IT the driving force of the business, or is IT a business partner, or is IT merely a "vendor" for technology services? The governance model also depends on the other groups in your organization. Are you decentralized, or highly structured? What is the maturity level of the business and of the IT unit? These factors will help inform your governance model.

Monday, May 30, 2016

Understanding risk

Throughout my career, I have tried to take a risk-based approach to actions and decision-making. This has become more important to me as a CIO. Understanding risk is an important part of driving change. If you understand the risks, you can decide which risks you can accept and which you cannot. In doing so, you avoid "analysis paralysis" where you continually evaluate options without actually choosing a direction. By taking a risk-based approach, some options become obvious.

I find I turn to a few simple models to understand and evaluate risk. My standard model is based on Likelihood and Impact. I often go to this model when considering system risk. Which are your riskiest systems? Consider these dimensions:

How likely will this system experience a problem?

As an example, consider a computer system that is supported by only one server, under someone's desk, running on building power, and without a backup—that system has a High Likelihood for failure. If you find a server like this in your organization, you should be very nervous about when it will fall over, because its failure is a matter of when, not if.

In contrast, if you have a computer system that is supported by multiple servers in parallel, running in different data centers, using redundant power and cooling, with multiple levels of backups—that system has a Low Likelihood of failure. I usually don't worry about these systems.
If the system does fail, what's the impact to the organization? This might depend on what the system does, taking into account exposed private data or the reputation of the organization.

Let's say you had a database that tracked when public benches were last repainted. Maybe your facilities department uses this information to know when to schedule a touch-up job or a complete repaint of the bench. If you lost this data, the organization isn't impacted that much. The facilities folks would have to re-evaluate the benches. For many benches, this will take a while, but the organization will continue otherwise uninterrupted from this failure.

On the other hand, if your HR database of employees and salaries was irretrievably lost, your organization would be severely impacted. Someone in HR might be able to reconstitute the data from other sources, but it wouldn't be perfect. And depending on your industry, this is probably private data. Your organization could face damages and fines for the loss of salary information.

The Likelihood and Impact feed into a risk matrix. I prefer to color code the matrix with red as the highest risk, yellow as moderate risk, and green as the lowest risk:


For other risk scenarios, you might also include a "critical" risk, such as when loss of life is possible:

I use a similar risk matrix when I need to understand the risk of making a change. Not all changes carry the same risk. I know from my early career as a systems administrator that you can make certain changes to a running system without worrying too much. But other changes require more attention. Again, consider the Likelihood that a system change will result in a problem, and the Impact that problem would have to the business.

Have a backout plan
Consider timing
Remediation plan
Consider carefully
Have management support!
Probably a standard change
Just do it
Lowest risk
Talk to others
Evaluate the timing
Consider knockdown effects

But when considering the risk of business applications, you might need a different risk matrix. Should you continue to run that business application? Does it really provide value? Is it reliable? These questions feed into a different matrix that helps you decide what to do with business systems.

Business value

At every level in an organization, you need to understand risk. Without a method to evaluate risk and make risk-based decisions, you can quickly move to a decision. Some options are obvious, others will require careful consideration and coordination with others.

Consider leading an exercise to explore the risk in your organization. I find it is helpful to start with common definitions. Jot down some examples of what defines high/moderate/low Impact, and high/moderate/low Likelihood. Define what you mean by "high business value" or "low stability." Get buy-in on these definitions from the key stakeholders, then work with them to place applications or systems in each box. Don't worry about relative placement within the box. If you find yourself saying "This is a Moderate Likelihood, but it's on the high end of Moderate," then just put it in "Moderate" and move on. The most important factor isn't that the Likelihood is "Moderate" but what you do afterwards to reduce the risk.

What can you do to reduce the risk of your systems? Technologists usually start with Likelihood. What can you do at a system level to reduce the Likelihood of a failure? Moving systems into a data center is one way to do this. Also add redundancy where possible, such as redundant power supplies on different power feeds backed by different uninterruptible power supplies, or move important data off single disks to a RAID or a SAN.

At the same time that you address Likelihood, also consider the Impact. How can you reduce the impact of a failure? For example, do you really need to store all that data on that system? Is the extra data increasing your risk unnecessarily? If you can remove unneeded data from a system, you might reduce your Impact.

Over time, you should repeat this exercise, and you should be able to demonstrate your organization reducing its risks. In the Likelihood-Impact chart, your applications and systems should move from red to yellow, and from yellow to green.
image: "decisions" Impact Hub/Flickr (cc by-sa)

Monday, May 23, 2016

Five phrases

A great article at Fast Company discusses the words we use at work, and how those words impact our influence and relationships.

You've probably experienced poor word choice by others. In a meeting or in a discussion, you may have observed someone really flub a point by using wrong language. Maybe it comes off as too forceful, or too autocratic. And that changes the tone of the discussion. Poor word choice can turn a conversation's focus from "collaborate" to "dictate."

In the Fast Company article, Bernard Roth of Stanford University's discusses the 5 Words And Phrases That Can Transform Your Work Life. Quoting from the article:

"But" is probably the most limiting word in our vocabulary. The use of "but" closes off the conversation space, while ‘and’ opens it up. When you open up the dialogue with "and," your brain gets to consider how it can deal with both parts of the sentence.
Needing to complete work is one of the most common situations in which we say we "have to" do something. By saying you "have to" take it, you set up a situation as a burden. By simply swapping out "have to" with "want to," you will more readily make it seem like less of a burden, and indeed, more of something to look forward to.
When we say we "can’t" do something, that is almost always not actually the case. By exchanging "can’t" for "won’t," we realize that an inability to currently do something is a choice, not a physical impossibility. The simple change of ‘can’t’ to ‘won’t’ is often empowering. "Can’t" implies helplessness; "won’t" signifies volition and choice.
"I’m afraid to" is about the most blocking phrase there is. It acknowledges the person’s fear instead of their desire. Phrasing your want as "I’d like to" acknowledges your desire, and desire is usually associated with positive, pleasant thoughts.
The word "help" is often associated with "helplessness" in our minds. Helplessness implies someone is incapable of achieving something without someone else stepping in to do it for them. However, when we swap "help" with "assist," we set ourselves up to see that we are an important and capable part of the solution.

Monday, May 16, 2016

Meeting with customers

Relationships are an important part of getting things done in any organization. Whether you work in IT or some other unit, who you know can sometimes be just as important as what you are trying to accomplish. If you have connections with business partners inside the organization, you can leverage these relationships to help you meet goals and drive innovation.

But relationships aren't just for getting things done. You can't just build relationships for the sake of driving work. You also need to have business relationships with your customers.

IDG Enterprise discussed this topic in their editorial article Why it pays to meet your customers. They identify the benefits through numbers:

You could argue that, outside of sales and marketing, IT is the business division for which it is most important to meet with external customers. To further put some numbers around why it is so beneficial for IT to meet with customers, consider this: Of the 2016 State of the CIO survey respondents who said that they regularly meet with customers, 57% report directly to the CEO, versus 46% of all survey respondents. Additionally, 41% of CIOs who have regular contact with customers spend their time on highly strategic activities, such as driving innovation, developing new go-to-market strategies and technologies, and studying market trends for commercial opportunities. In contrast, just 19% of CIOs who seldom or never meet with customers engage in strategic activities such as those.

In IDG's view, meeting with customers is the best way for CIOs to stay focused on strategic needs of the organization.

I agree. The CIO needs to stay connected with the organization and its customers. The IDG article makes the case that the CIO should meet with the external customers—the people paying for services. But what if your organization is like higher ed or government, where you don't have "paying customers" in the traditional sense? In my view, it doesn't matter.

It's still important for the CIO to meet with the units served directly by the IT department. In higher ed, I regularly set aside time to meet with division chairs and unit directors. Twice each year, I also arranged formal IT input cycles, where I led discussions around the future IT needs of the institution.

I've only been in local government for a short time (three and a half months, if you're counting) but even so, I recognize the need to meet with the units I serve so I can stay connected. I've arranged meet-and-greets with several groups within the County, and I look forward to meeting more of my colleagues. By staying connected and building these relationships, IT will be a partner to our customers, rather than a mere service provider.

I believe so strongly in the need to stay connected with customers that I am creating a new, expanded "IS Liaison" position. We are a large county—at over half a million people, we are the second most-populous county in the state. So it's not feasible for me to meet individually with each of my customers. I need some help to get that done. The Liaison position will become the primary contact point for our customers.

The Liaison won't replace my need to meet with customers, but the position will allow me to stay connected while focusing on the strategic needs of the county. The Liaison will meet with our customers in an ongoing basis, likely twice each year, to discuss IT needs and to preview what's coming up with each of our customers. Let's set the clock ahead by six months or twelve months, and ask "What's happening in your unit over that time?"

I hope the Liaison will hear about projects with IT needs: "We're looking to purchase X system, and we'll need IT to help us with that." But the Liaison will also look for projects that have hidden or unrecognized IT roles: "We're going to be moving to a new building in ten months, but we don't think IT will need to do anything with that." (What about network, phones, computer moves? Let's partner with you on your move so the IT stuff gets dealt with.)

Over time, I hope the Liaison will become an integrated partner with our customers, providing a focus point for questions and issues, and serving as a mechanism to get "stuck" items moving again.
image: reynermedia/Flickr (cc-by)