Friday, July 6, 2018

Why not be the "IT person"?

I was recently asked why I shy away from being labeled as the “IT person” when talking about my role or career path. I had an answer at the time but it wasn’t fully thought out. So here goes...

(I fully recognize this has been covered by many people. I appreciate your bearing with me as I attempt to make sense of it as well.)

I’ve been in IT for twenty years, and my path has taking me from support through systems infrastructure to management and leadership roles. Throughout this time, the industry’s notion of what IT is to an organization has evolved, but the emphasis has always been on the idea of technology as a strategic asset or partner to the business. Magazines and websites publish plenty of case studies on success stories along these lines. 

However, I’ve mostly found that an organization's notion of what IT is has more to do with keeping the lights on than on helping the organization propel itself forward. Computers need to be fixed, servers need to be running, and applications need to be available. And these are important, indeed critical, to a business functioning. They also tend to be static and can even inhibit necessary transformation as the business (or industry) evolves. The impact of IT stasis is twofold:
  1. IT loses its ability to explore and innovate, instead staying in the comfortable rut of maintenance.
  2. Non-IT folks stop thinking of IT as a team that can help solve their bigger problems, instead deciding to go it alone and “make it work."
These are both exacerbated by the reality that IT is no longer needed to stand up the basic technologies needed to run a business. It’s even easier now for IT to retreat into its cocoon and non-IT to find what they need and bring it into the workplace, increasing the divide. So being the “IT person” becomes being forgotten or uninvolved at times when their expertise is most needed, and then resentful when new services or systems are dropped on them (even though the situation is partly of IT’s making). It’s a truly vicious circle, resulting in a culture that doesn’t even think about IT when a need arises. 

Okay, so that’s all depressing if you work in or are responsible for IT. What can be done about it?

The IT leadership literature has long asked questions like, “how does IT reach across to the business?” and, “how do CIOs show their CEO and peers that they’re business-focused?” These are aimed at proving IT is ready to be at the table, which is important. A CIO/CTO needs to demonstrate and be seen as at least “IT leader, plus business”, if not “business leader, plus IT” by their CEO, peers, and colleagues to be effective.

But it’s not enough. For example, ideas are generated and decisions are made in day-to-day conversations in hallways and doorways (or the virtual versions of those), not in the big meetings. The IT leader needs to be in those as well, which is a combination of being invited and asking to join. The level of agency varies by situation, so each IT leader needs to determine the right balance for their organization. Otherwise, the leader and IT department will be relegated to the sidelines, called on only when needed for a specific task.

IT leaders also need to make a compelling case to define clear lines of priority and accountability for projects they champion, and avoid having a project classified as an "IT thing." "IT things" often drop to the bottom of everyone else’s priority list, which can make them difficult to complete due to lack of business partner availability. Security, policy compliance, and process improvements often arise from IT, and easily slide into the “IT thing” category. It’s on us to contextualize those projects and build the necessary partnerships to make them both relevant and successful. 

The opportunity is usually there for the CIO/CTO. But it’s never easy and it always, ALWAYS requires more time and energy than you’d think.  

Saturday, August 26, 2017

It's 2017 - why are we still spreading FUD about data security in the cloud?

I was looking into document management options to build upon Google Drive earlier this week. A quick search of document management with google drive yielded, among other results, a post called Google Drive is No Substitute for Document Management. Reading this took me back to conversations years ago about how you can't trust the cloud for your sensitive information and how having your own servers is more secure for your data.

(The post was written in February 2016, so I understand if the post doesn't account for service advancements since then. However, leaving this as is, especially given its high page rank, isn't doing readers a service.)

There are certainly reasons to not rely on Google Drive (or Dropbox, Box, or other cloud file sharing options) for workflow-driven, automation-aided document management, which is discussed in the post. But the first two reasons are just plain inaccurate, and taken at face value, can inhibit organizations who have complex needs and limited resources from taking advantage of commonly used cloud offerings.

Let's start with reason #1 ("Google Drive is Difficult to Administrate"). The basic premise here is that IT administrators don't have the control over folder and file access that they do in more centrally controlled systems, and that control is exceedingly important to maintaining data security. While that sounds bad, let's consider that once someone has access to download a file or folder, they can then share it with whomever they want via email, some other file sharing mechanism, or by printing it out. Further, people are more likely than ever to find the best tools for their work, especially if IT is clinging to admin-centric rather than user-centric services. Data protection and security, absent an environment that is so restrictive that it allows only the most basic functionality at all, is often a combination of technical capabilities, corporate policies, and user training to provide a secure and productive environment.

The roles of policy and training in protecting an organization's data cannot be emphasized highly enough (but here's a few links for your reading pleasure):
Seeing a viewpoint represented by a statement like the one below not only frustrates me, but also indicates policy and training aren't being considered:
For example, your HR employees need to store sensitive information like social security numbers, names, birthdates, and direct deposit banking information. If they store this information in Google Drive, there is a good chance that other employees can see it, too. Obviously, that’s not a good idea.
Storing this data in a spreadsheet in any location is ill-advised and no technology is going to fully protect against it happening. In a security-aware culture, though, the data steward would more likely consult with IT on the best way to store that data and prevent inappropriate disclosures.

On to reason #2 ("Google Drive Only Uses SSL Encryption"). When considering your data security, it's certainly crucial to consider data at rest as well as data in motion. This post asserts that data stored in Google Drive are encrypted in motion, but not at rest, linking to an article that says the same thing. That would be disconcerting and likely put people off using G-Suite. However, Google is fairly upfront about their encryption, making a topic-specific whitepaper available for public view. It articulates how data are encrypted at rest and in motion, as well as how encryption keys are managed. The short version is that with the possible exception of video files, data uploaded to or created in Google Drive/Docs/Slides/Sheets are encrypted. It's also one part of Google's overall security approach. Dropbox and Box have similar information available about their security and encryption approaches.

When considering cloud storage for your organization, security and risk management should be right alongside usability and collaboration in your priority list, and doing your research is important to making a sound decision. The major cloud service providers get it, and have embraced data security and protection as cornerstones of their storage services. Saying otherwise is outdated and unhelpful.

Monday, June 20, 2016

The CEO-CIO Connect

My social media feed recently included an article from Maven Wave Partners' Fusion Blog titled, "CIO vs. CEO: Finding Middle Ground." (note: I used to work at Maven Wave several years ago.) As it was my former employer and I'm a new CIO, I had to read it. And it was thought-provoking indeed -- I didn't necessarily agree with many of the premises, the primary conclusion was spot-on:

"When the CEO and CIO can find middle ground and work together as true partners, the enterprise will achieve true competitive advantage..."

Within the article, the points that stood out to me were (1) the disconnect between the CEO and CIO, and (2) the CIO as a business commodity. Each deserves further consideration, especially at at time where fewer people want to be a CIO.

The disconnect between the CEO and CIO

The article states, "Clearly, the CIO and CEO have roles with notably contrasting job responsibilities... The CEO often understands the core business and customer demands better than the CIO." I'm not going to disagree with these on principle, and it's easy to see this as the world as is. At the same time, we in IT leadership have been told again and again that we must, MUST understand the business in which we operate in order to be a strategic partner and not a business commodity. Virtually every CIO success story I've read can be summarized as follows:
  1. CIO meets CxO
  2. CIO and CxO form partnership around common cause
  3. CIO and CxO make big initiative happen, increasing visibility for both
One of the reasons I was attracted to my current position is the shared idea that the CIO and CEO in fact have roles with notably comparable job responsibilities. Yes, we do different things for the organization (and I'm still figuring out mine). But we share the broad responsibility of both taking the "across the organization" strategic view and enabling ongoing operations. This dual responsibility distinguishes the CIO from a director of IT, who focuses more on operational excellence and continuous improvement within the technology function.

CEOs and CIOs both have the responsibility and opportunity to span the organization.
CIO as a business commodity

So what about the CIO being a business commodity? This is certainly one way to be perceived, especially if the CIO presents as tactical rather than strategic. It's tempting to create an IT strategy, but that helps separate technology from the business. IT strategy also tends to focus on things IT thinks is important, which rarely match what the CEO is trying to do and gives the impression IT isn't part of the team. 

Instead, the CIO's goal should be to ensure technology is part of each facet of the corporate strategy. Ideally, meeting this goal involves the CIO having candid, business-focused conversations with the CEO and being at the strategic table, and doesn't involve the intricacies of platform as a service or network segmentation. However, the world is far from ideal, and the CIO may have to work hard and long to get to that point, possibly exerting influence less directly to get to the table.

This all sounds great in theory.

Doesn't it? That doesn't mean it's an impossibility in practice. Where a CIO begins has everything to do with context -- not every CEO is ready to integrate technology into their everyday thinking. But they don't have to, at least not in detail. If the CEO is willing to consider technology in terms of the same goals as everything else -- help the top line, help the bottom line, and mitigate risks -- then perhaps the conversation can get underway.

Sunday, May 29, 2016

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.

Friday, October 3, 2014

What could be the point?

I recently gave a presentation at the EDUCAUSE annual conference with colleagues from Brown, Johns Hopkins, and UNC-Charlotte on supporting digital scholarship services. The presentation itself was a rewarding experience, and I really appreciate the opportunity to have worked with such knowledgeable and driven colleagues. As someone who mostly advocates for such services rather than provide them directly, I needed to learn a lot to catch up in this area.

Some hours after the event, A colleague from another Big Ten university who had attended our session wrote to me, and he said possibly the most intriguing thing I heard during the conference. Like me, he heads technology services for a college within the larger university, and has been working every effectively to shift scalable commodity services to the central IT organization. He said (I'm paraphrasing), "What if digital scholarship was the primary idea of what we do at the college level, rather than a component of our services?" We talked about it briefly the next day, though we were both mostly trying to wake up, it being 6:30am according to our Central time zone-adjusted selves.

The idea has certainly set my mind going on this. We've shed a lot of our hardware-based infrastructure, and are already considering ways to reduce even our virtual servers to a minimum number as we adopt cloud services for file sync/sharing, virtual desktops, and applications of all kinds. So what if we mostly abandoned the traditional IT philosophy of a standard service catalog and adopted digital scholarship as the focus? Our organizing principle then becomes about supporting as many edge cases as possible, knowing each faculty member or lab represents an edge case. Underneath, we need a set of sustainable platforms to ensure deep technical expertise on our part and increased longevity for the projects built on those platforms. We need to continue to foster partnerships with other groups in this space, like central IT and the University Library, and build ever stronger relationships with our faculty and students. We need to learn quite a lot about digital scholarship and the disciplines we enable. Perhaps most importantly, we need to embrace the primacy of the end-user experience as our focal point rather than consider it the lowest rung of our services and capabilities.

I'm not yet sure how this could work. In fact, this seems like a pretty scary proposition - we've never done anything like this and don't have the skills and experiences already built into the team fabric. But the potential for transformation seems so high that we have to at least try it on and see how it fits. More to come.

Saturday, April 27, 2013

Why try to collaborate?

As mentioned in About, I work in higher education, which can be (at least somewhat) justifiably described as highly decentralized when it comes to both business processes and technology service delivery. Efforts to coordinate or centralize either meet with challenges as well-intentioned working groups attempt to reconcile the many disparities among distributed units' processes and practices that have organically grown over several (or many) years. The results can include efforts that start but don't go anywhere, endless meetings about the same conversation, and relatively little change from the end-user's viewpoint.

Sounds pretty grim, right?

Despite the dour description, positive outcomes do arise from all these attempts at collaboration.
  1. People get to know one another. Sounds obvious, but in a large (or even) small organization that has multiple silos of information and process, this is not necessarily the case. I have been in any number of meetings where people who should know each other don't. If we can't get this done, it's that much more difficult to get anything else done.
  2. People start getting comfortable with the value and costs of collaboration. Again, obvious. But it's much easier to be effective in one's own sphere than to be part of reaching across barriers and making something happen in a larger context.
  3. The first two enable repeat attempts to share and collaborate. Even if a particular attempt fails to bear fruit, the relationships and increased comfort level allows the parties to say, "Maybe next time we'll have the right problem to solve/opportunity to succeed."
In technology, the need to collaborate and share is especially important, verging on critical to success. Pressures to compete with great user experiences in the consumer world, keep up with exploding demand, and enable people to seamlessly cross information silos require IT not as a set of discrete systems and services, but as an ecosystem of loosely coupled (and often interacting) applications and data. Getting in the same room isn't the solution, but it's a start.

Sunday, February 26, 2012

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.