Higher Education IT

Being @ a Small College

I have often remarked to others that I value being at a small college, and identify as an advocate for such institutions. Heck, when I ran for the EDUCAUSE Board of Directors, which explicitly asks that one not speak only from one’s personal perspective but instead from and on behalf of the entire community, I “campaigned” partially on being able to look through the lens of a smaller institution. There are way more small institutions (sub 5000 FTE students) than large ones, so I was trying to speak to a lot of community members. But what does it really mean to be at a small institution? Well, a lot, actually.

There is scale, and economies thereof. In any department, be it IT, student affairs, marketing and communications, etc., there are simply fewer people doing the same number of jobs. In IT, for example, we have the same burden for information security and privacy as a much larger institution, yet we (at CalArts), do not have a full-time, in-house information security officer, much less an entire department dedicated to security. So we have to get creative and share the burden across multiple staff and use other resources such as “virtual” Chief Information Security Officer (vCISO) services from third party firms, share CISOs between institutions, and/or layer multiple services on top of each other for maximum protection.

We are also very thin in a lot of areas. I do not have the luxury of enough staff to run a 24/7 shop, even for our most critical of systems. We monitor them 24/7 and we act on the alerts we get, sure, but people do need to sleep, and sometimes I’m only 1 deep on a knowledge worker. Sometimes that alert isn’t seen for 8-10 hours, no matter how efficient we are at using instant communication tools. We mitigate this through efforts to shift to the cloud (so someone else is managing our systems), for example, but we’ve run into budget challenges there, to name just one obstacle. At larger institutions, you might have a whole team of people responsible for monitoring the data center, rather than just software (that can easily become out of date as systems change) that are there 24/7 to alert others of issues.

Similar challenges exist for other departments, of course. It’s not just us in IT working at a small institution. Many departments are 1 person deep at best, and several of those are in fact doing 1.5-2 jobs each. If even one person retires or resigns, the impact is disproportionate (many things keep me up at night, and staff retention is one of them, both because I want to know the team is happy, and because it’s so hard to weather the departure of any one of them).

A nice thing about a small college is that most people know each other. I joke that here at CalArts, someone need only say “George” in a sentence and I can figure out which person they mean based purely on context (which is actually only a slight exaggeration). But this can backfire, too. Support requests go to individuals instead of our ticketing system, for instance. Or “personal favors” are asked that break policy that we work so hard to develop and enforce. Sometimes it goes the other way – I find myself wanting to bend my own policy sometimes to help someone that I’ve come to know personally, too.

Another nice/not so nice thing is being involved in day to day operations. On the one hand, I feel I have a good pulse on what is going on in the department. I work hard not to micromanage so I don’t get into the weeds but I know what products we use for what, the general status of upgrades/updates to those solutions, etc. I can answer questions from others (esp. other VPs) effectively. Also, there are few things I haven’t seen before, and seen from the inner workings. I’m not saying I’ve seen it all and I’m definitely not saying that I addressed all those matters the right way the first (or even second) time around, but few things truly surprise me these days. That’s good. The downside is that every single day I get pulled into the tactical and away from the strategic. Sometimes it tires me out and I don’t even want to get into the strategic. I’m just worn out on the day-to-day struggle. Every fire we have to put out leaves me less able to figure out how to avoid ignition in the first place.

These are just some examples. I’m not trying to be comprehensive here. My original goal was to answer for myself the question “what does it mean to be from a small institution?” But then I should I’d share a bit. Would love to hear some other examples.

boosting retention vs. invasion of privacy

In a recent article, the Chronicle of Higher Education covered a product from Degree Analytics that looks at a lot of “big data” – specifically WiFi location activity – to aid in student retention. The article is also about the privacy concerns when one starts digging into such data. Just because most if not all systems at least passively collect location data on WiFi networks doesn’t mean it’s appropriate to be using that information. Students haven’t specifically given permission to have their data accessed that way. I’m willing to bet a lot of money, too, that they aren’t aware that their movements could lead to such analysis that somehow “predicts” their success at the institution.

I’m not going to get into Degree Analytics specifically. I will admit, though, that we gave them a legitimate look here at Muhlenberg. And that I was pretty torn about the matter of boosting retention vs. a potential invasion of privacy.

I realize that this post will get a few up in arms, including some that I consider close colleagues and even friends. I would expect that to be the case, though, considering the topic. Certainly there were some here at Muhlenberg that were up in arms at the mere notion of using data this way. But we did take a look; this is a polarizing topic to say the least.

But here’s my take, and my conflict.

Retention is a big issue today. The connection to student academic success is obvious (though there are many, many other aspects to “success” than just academics). There’s the altruistic aspect to this – we want students to succeed because it’s the right thing to want and pursue. That’s far and away the bigger side of the issue, and I won’t belabor why that is so important. But there’s also a business side to this, all the more important considering today’s higher education climate – every student we retain from year X to X+1 is a multitude fewer we have to enroll as a first-year, provides revenue at a lower discount rate (presuming discount rate goes up with each class, as it generally does), and improves our graduation rate (which affects rankings).

So if we can retain even one more student for all the above reasons, altruistic and business…is that bad? Is it even…good? Good enough? How much is enough to justify using data however we want?

Let’s look at the other side of the coin, which is a doozy. First, students don’t realize that this kind of data on campus whereabouts based on WiFi connections is even collected. They certainly wouldn’t think we’d use it to literally track them, then draw conclusions about their “success” and intervene when we fear that “success” is in jeopardy. Second, just because we collect something doesn’t mean we should use it at all, much less in this way. By the way – at Muhlenberg at least we don’t “monitor” people through whatever data we do collect. Yes, our WiFi logs go back 90 days (but not farther, for any reason whatsoever), but we don’t comb through them pro-actively. We only use them if we get a DMCA complaint and we have to figure out who was connected to what IP address at a particular time. But that’s pretty darn specific. Degree Analytics is very, very broad.

So this is a pretty big invasion of privacy. A massive one, to many.

We didn’t do Degree Analytics here, but probably 30/70 cost vs. privacy. It wasn’t all privacy concerns. And I was among those torn about it. Because we do have to worry about retention. And maybe, just maybe, this is a way to improve and get all the benefits, to us and students, that better retention entails. But it’s a dangerous path that we’d be starting down, without question.

Governance for the New Guy

We spun up 3 major projects almost right off the bat following my arrival here at Muhlenberg. We were to replace the Student Information System (SIS) with an Enterprise Resource Planning (ERP) solution, the email system, and our Learning Management System (LMS). All 3 are pretty big, and any one would make for a busy year (the ERP in particular is a really huge, multi-year effort).

One of the first challenges I faced was how to build proper governance on these projects. Governance is a two-way street. It keeps people involved, it keeps the community informed, but it also asks the community for input, and is a way for the project to respond to such information and adjust. While I could certainly be such a conduit myself and I could use our existing faculty-based College Committee for Technology and Digital Learning (CCTDL), I did not feel this was the best approach so soon after starting here. I definitely wasn’t going to make any executive decisions or recommendations without a great deal of input, either. Who was I to say I “knew” what the college needed? That such and such product was the “right” one for Muhlenberg (I say this in general – that was I so new I was still getting lost on campus compounded the fact).

So I created committees. Lots of them.

For the LMS and email projects, they each had a committee that included staff from multiple different departments and faculty. The LMS one was, not surprisingly, a bit more heavy on the faculty side and there was an emphasis on instructional technologists from the staff population. The email project had a broader cross-section of the community. The former was chaired by a faculty member, and the latter by our Library Director, who had been involved in a similar project at another institution. CCTDL members sat on both committees.

I formed 3 separate committees for the ERP project alone. The Selection Committee was a small, 7-person group of key operational staff that could move quickly through the process of gathering requirements, developing a Request for Information (RFI), schedule demos and interact with the vendors. This group included representatives from Advancement, Admissions, the Registrar’s Office, the Office of Residential Services, the Library and the Controller’s Office, headed up by a project manager from OIT.

A Steering Committee “governed” the Selection Committee. Departmental directors and other key management staff made up this group. VP of HR, the Registrar, the Controller, the Director of Financial Aid, Athletic Director, Director of Campus Safety, and the AVP for Advancement were among those included in this group. It was much larger – 17 total members. A member of CCTDL was the faculty representative and the Dean of our Wescoe School chaired it.

The Steering Committee was charged with both making sure the Selection Committee was doing what was needed/headed in the right directions as well as making sure they would be successful. If a group was slow in getting requirements back to the Selection Committee, then the Steering Committee had the responsibility to get things back on track. At the same time, it was ultimately the responsibility of the Steering Committee to write up the final recommendation.

Finally, the Executive Committee was made up of the college Senior Staff (those that report to the President). This group held the ultimate decision-making authority. As part of the Executive Committee, I worked with other members to help push down various initiatives as well as make certain high level decisions. We concluded, for instance, that we would go with an “off the shelf” and “plain vanilla” installation, adapting our business processes to the product, rather than pursuing customization. We also discussed policy on cloud hosting and SaaS delivery options, for instance. It was critically important to have this kind of executive sponsorship – the entire senior staff.

With the exception of the Executive Committee for the ERP project, I have stepped completely away from all the other committees. I didn’t attend meetings, I didn’t ask for notes or report-ins, and I only occasionally checked-in on progress for general reasons, not to keep tabs. With the LMS and email committees, I met with them at least once for general guidelines. I did join in on a couple of joint Selection/Steering Committee meetings for the ERP project. But overall I’ve kept my distance. I think it was very important that I let the committees do their work.

While we haven’t completed everything yet (I used the past tense just to keep things consistent, but the ERP project in particular is still ongoing), the LMS launch has already gone well, and email is closing in with the start of the new year. ERP will be another 1-2 years. But what I’ve discovered is that, through judicious use of committees, you can get involvement of the community in ways that are impossible as an individual. It’s also brought legitimacy to the process in ways that I hadn’t even expected.

the great unbundling

There has been a lot of discussion on “unbundling” of traditionally single-vendor, monolithic systems, especially the Learning Management System (LMS) and the Enterprise Resource Planning (ERP) solutions.Essentially, rather than relying on a single solution that does 100 things, why not break out the functions into perhaps 20 products that are all efficiently and seamlessly tied together? Those 20 would be chosen because they meet operational needs better than that single solution could.

This is different than a straight “Best of Breed” approach. Gartner handles it pretty well in their discussion on the “post-modern ERP.” Best of Breed is focused on selecting products that are best in industry, in any given field. Being purposely black and white, it’s the best of that type of application, and that’s what we’re going to use. A post-modern ERP approach is based on business processes. The results might be the same – the best product in the field might be the one that fits your business processes the best. But one institution might do something very differently than another, and while both might be looking for “best fit,” the result might be two completely different products. Perhaps a subtle difference, but one that I think is important.

Unbundling an ERP, especially in higher education, is pretty straightforward. Perhaps the admissions module that came with the ERP isn’t an effective CRM. Let’s go out and find one, and spend our time integrating the two systems. We might see similar decisions with Advancement and its CRM needs, or perhaps analytics and data visualization.

At first ,the ERP would be the hub with other systems attached to it. Over time, the ERP is completely broken up, and all the systems revolve around a data warehouse. Energy is spent on governing the data integrity of that warehouse and on maintenance of the flow of data. The ERP (which by this point is probably just a Student Information System) is actually attached to the data warehouse, rather than fueling it. The great thing about using the data warehouse as the hub is that all reporting stays consistent from group to group.

This isn’t remotely my idea, by the way. I can’t seem to find the trail but I know I first heard of it from Theresa Rowe (@oucio) who was in fact retweeting someone else. I’ll provide the reference if someone can send it my way. Also, all you (what, 2 readers?) should note that I’m in the middle of a comprehensive ERP roll-out right now. Just because I get the idea of the unbundled ERP doesn’t mean it’s the right time for me to pursue it for my specific institution.

The data warehouse could be the center for the components that make up an LMS, too. I get the idea – find the right assessment tool for the learning outcomes your institution has chosen and integrate that, rather than using one that came from a vendor. Do the same with e-portfolios, quizzes, cloud storage integration, just about anything. If student data is all managed effectively in that warehouse, and all the systems are connected properly, you could have a pretty powerful solution.

My concern, however, is that whereas an unbundled ERP likely won’t lead to a lot of user confusion, an unbundled LMS could. The finance office uses its software and Admissions uses theirs, and rarely shall the twain meet. But students all use the LMS components, and this could lead to confusion. Sure, we can implement single sign-on so at least it’s one portal and one login, but how do we manage this user experience?

This remains to be answered. I’m eager to see what comes of all this unbundling.

the other end of the Personal API

A lot has gone on lately about the “Personal API.” Getting information on it gets to be a bit meta, with one link leading to another article to a blog post then all the way back around to the first reference but start off with a great post from Jim Groom that in turn links to an article by Tim Klapdor that really captures the key ideas, then check out some talk on the Indie Ed Tech discussion from 

A massive oversimplification of an idea as expansive as a personal API is that it’s a way for the user to control how his or her own data is being used and accessed. An API in the software world is a defined interface for accessing data from a system like Twitter or Facebook. A personal API, therefore, is about controlling how personal data is accessed. It puts the power back into the hands of the individual, rather than the system. This discussion is taking place in higher ed, so the practical example would be a student deciding when personal data such as a phone number is available, rather than the institution controlling that information through access into, say, the Student Information System (this is the example Kelly Flanagan, the CIO at BYU, provides).

This is an amazing idea, and one worth pursuing regardless of your type of institution. It’s worth rethinking how you approach everything from digital learning in general to the LMS specifically. But it also has a flip-side challenge that is non-trivial.

Earlier this week, I was in a demo from an SIS vendor where we talked about ways to access data in the system. Not surprisingly, they discourage direct SQL database access, so the options were to either use reports (e.g. – giant Excel file, which requires more work to use) or build hooks into their APIs. The latter is preferred since it would inherently include getting the data into the right format for whatever the intended use, plus it would be more secure. The vendor was touting how they have well-documented and extensive APIs so that we can do what we wish in terms of software development.

APIs – whether for a Student Information System or a person – are great and indeed quite powerful. It’s like an extended hand in a way, but one that carries with it all the information about how high up the hand is from the floor, how far away it is from the body, whether it’s the right or left hand, etc. Taking this metaphor a bit further, the key is that the person extending the hand – the student in the personal API example – gets to decide all of those variables. The angle of the hand, the distance extended, etc. What data is included or excluded, and exactly how a secure exchange should take place.

However, having an API isn’t a complete solution. The problem with an API is that it’s only half of a two-part process. The hand is extended, but someone does indeed have to walk up, take hold, and offer that firm handshake. It’s great to offer access to data, and it’s even better to give control over that process to the individual, but it still takes two to tango.

Now, BYU and some schools involved in projects related to digital identity (see Domain of One’s Own – another Jim Groom brainchild – for a good starting point on this topic) are already or will soon be investing time and resources into the other half of this relationship. And this is undeniably something that every institution should explore as we find ways to empower students and create the Next Generation Digital Learning Environment, but there is part of me – the cynical half? – that keeps wondering about the resources needed. Looking with blinders on only at our department at Muhlenberg, I don’t see us being able to engage in a meaningful way for some time. We’ll take advantage of tools that others build, sure (and of course there is nothing wrong with that IMO). But as far as us being the other end of the handshake, building our own tools? I don’t know. Can we disaggregate the LMS on our own? Not likely in the near future.

Absolutely worth it, without a doubt, to work to find a way to get involved. But it will take work to get to a meaningful outcome with the personal API.

startups and higher ed IT

When we bought our house 4 years ago, we invested in some improvements. One was to lease a solar panels for our roof, from a quasi-startup that worked specifically in cities with sizable solar rebates.. At the time, the notion of leasing panels rather than buying and installing outright was pretty controversial. You didn’t own them, you didn’t get the rebate, and you are dependent on another company for maintenance, etc. The way I saw it, at the time, was that since I didn’t have $30,000 lying around for an install, not getting the rebate was moot. We would get a significant energy savings, so it seemed like a win-win. One of those situations where a solution that is sub-optimal to many was actually pretty okay for us.

I’ve had to revisit this decision recently, and it occurred to me that it’s not unlike the times I’ve worked with startups while here at Menlo. At face value, it seems really dangerous to work with a company that has 10 employees and is a year old. These companies can go through ups and downs. The obvious one is going out of business, but there can be severe changes in direction due to market forces, abrupt adjustments to planned features quarter by quarter, and a seeming rotating pool of sales folks (if they have a sales force at all). Ironically, the one consistent thing has been negotiating pricing – these companies want to get into the higher education market, so they are usually willing to talk until we find something mutually beneficial not only now but also for at least a few years down the road. I can’t exactly adopt something now at an affordable price then pay ten times that amount in year two.

At the same time, all institutions should be looking to take advantage of new technologies and solutions and especially here in Silicon Valley there are many options around if one has an open mind. We can do some really interesting things with security, management, and monitoring based just on some recent agreements that we’ve made. And not so long ago, when I was still at Santa Clara Law School, I was working with “start ups” like Box, which is definitely a lot more than a fledgling company now.

There are many reasons to pursue partnerships with startups. One of course is that we’re a small college, and they are flexible on terms because they want to get into our market. These are companies that are hungry and of course must create compelling solutions to problems. They are there to be a David to the existing Goliath, and to aim that sling-shot with great accuracy. We have come upon some truly stunning products from these companies that have greatly enhanced our abilities. Of course we have been careful in the solutions we’ve pursued. We need to consider the benefit from multiple angles (will this provide not only superior results and features, but also at a reduced management load?) and of course the risks. Sometimes we have to look at what stage of venture capital funding they are at and the valuation established by investors along with the technology itself.

In the end, though,what has mattered is having the open mind to consider such solutions and the organizational ability to take advantage of them. We must be open to the idea that, perhaps because of certain aspects unique to Menlo College, taking a calculated risk makes sense. Just as how leasing those panels, at that time, made sense for us in our particular situation. While we missed out on $10,000 in rebates, we never could have gotten them anyway, and we’re still getting an energy savings every month that far exceeds the lease payment we have to make. In the case of start-ups at Menlo, we may not get the benefits of working with a larger company with its substantial infrastructure, but we get at times a better (or better-fitting) solution with fewer strings attached.  Even if a company goes in a different direction with some tool we’ve adopted, as long as we’ve gotten what we need out of it and haven’t entangled our operations with the solution such that it’s a chore to undo, it’s probably been worth it. And we’ve shown again that we as an organization are agile enough to take a calculated risk here and there. In many ways I value that agility that we’ve developed and the mindset that propels it more than anything else.

In the long run, this agility plays out in more traditional ways. Some new next-generation security option comes up, and we’re able to act on it faster than one might expect. There might be a new technology that is actually quite hard to master, but because we have placed an emphasis on the ability to adapt and learn, we can go through that adoption process sooner than others and perhaps get ahead of the curve. We’ll make our mistakes, but perhaps we can rebound from those, too, without as much pain because we’re accustomed to such changes from taken risks. Or perhaps we’re just going through a “normal” infrastructure refresh that involves servers, storage, and our virtualization layer. Perhaps we’re able to handle that kind of stress better, too. No matter what, agility and a mindset that appreciates that flexibility is invaluable.

I’m not saying that I’m going to be reaching out to start-ups and taking risks – calculated or otherwise – at Muhlenberg. But I do hope we can achieve the kind of agility that we’ve found here at Menlo. And if we are able to buck a trend here and there and do something new and impressive, then that certainly wouldn’t hurt.

thinking about frameworks and “best practices…”

As I prepare for my move to Muhlenberg College as their CIO, I have been doing a great deal of thinking about adapting to new situations. I have been keeping a completely open mind about Muhlenberg and the Office of IT themselves – I must learn the environment and culture and absolutely cannot make any judgments before arriving. But I have been thinking a lot about how transitions go in general. I’ve been reading the books, talking to mentors, and just tossing around ideas. I have allocated much time to considering the myriad of ways to handle a transition, both personally and to those with whom you interact. And a big part of a transition is what set of values will drive the organization.

One way to develop values that has come up quite a bit surrounds using “best practices” and various frameworks for managing IT organizations. I speak specifically about ITIL and Lean IT. The former is a non-prescriptive approach to managing organizations of almost any kind, with discussions about defining a service vs. a process, how to catalog and therefore understand those items, and determining “owners” for the sake of accountability and communication (massive oversimplification of a powerful set of tools). When applies specifically to the world of IT, the acronym ITSM is commonly used – IT Service Management. So the processes become the Help Desk, and the service might be repairing a printer or building a new wireless network. Owners become specifically the Help Desk Managers or the Networking Administrators, for example.

Lean also comes from outside IT – its origins are with manufacturing. Pioneered by Toyota, the idea is to eliminate wasteful, non-value-adding processes and utilizing “demand management” to create a pull-based flow of procedures and practices. The end user pulls in pursuit of valuable service, which better defines what resources and methods are truly needed to deliver that value. Whereas Toyota was talking about helping eliminate waste in their car manufacturing plants, Lean IT isn’t really that different. The wasteful process might be handling password resets, and demand management might be a lot different (I could read a thousand books and I’d still have no clue how to manage the demands of faculty to create the same kind of “pull”), but the ideas are the same. Identify processes that don’t add value to the end user and eliminate them, find a way to look at the end of the “value stream” and build your operations to fill those values, rather than deliver products because that’s just what comes out the other end.

This post started out as a discussion about the role of ITIL and Lean in higher education, about the pros and cons of going about them in different ways. However, as I wrote, I realized something more fundamental was afoot.

Both frameworks talk about “value.” In ITIL, it’s all based on whether your process or service provides value in the eye of the customer. In Lean, you work hard to get rid of non-value adding work. While I personally define value broadly, it is easy to start thinking of “value” as “flashy and new.” Investing in value means enhancements that gain attention. Value comes from high profile services. Also, there is a trap of thinking that something that is a relative commodity, such as a Help Desk, where services can be documented and are repeatable, is by definition not actively adding value to an organization. They should, therefore, be eliminated or at least receive less investment.

The problem with this viewpoint is that it presumes that value is either mutually exclusive from or trumps importance. A reliable Help Desk is critically important to the organization, and provides a service that is extremely and fundamentally valuable to the larger institution. Yes, procedures can be boiled  down to documented, repeatable models. In fact, at a Help Desk in particular services should be commoditized as much as possible, such that virtually everything is based on a prescribed set of steps that lead to consistently repeatable results. One should make the Help Desk as “dull and reliable” as possible, as compared to “flashy and new.” But sometimes commodities are dull, yet they add a ton of value. I do not think anyone would claim that a Help Desk does not add to the overall value of an IT organization to the institution. A lot of investment should in fact be made into documenting and commoditizing those services. This investment can take the form of new knowledge base systems, ticketing protocols, and even staff. Bottom line – something that is easily codified isn’t necessarily unimportant nor non-value adding. It is very possible for such services to be incredibly valuable because they are so important.

 

choosing to take the back seat

Last summer, I attended one of the EDUCAUSE Leadership Institutes.  I attended two different ones but I’m choosing not to identify which one this particular post pertains to.

One exercise that seems common among the various leadership programs from EDUCAUSE is that we write a card to ourselves.  Stuff we want to remind ourselves to do afterwards, or perhaps an important lesson we might forget that we need a reminder on.  One thing I did last time, for instance, was to design a staff retreat using certain principles we had learned.

In one of the two institutes I attended, we also had to write a card to the person sitting to our left.  Which meant that, 6 months later, I got a card with a suggestion from someone else, who had observed me during the week.  To paraphrase, this card said that I had

lots of great ideas and energy, but need to slow down and ask others for their opinions before speaking up.  You need to include others.  Only then would I be successful

To be honest, at first this was rather hard to take.  I felt a bit insulted and hurt; I wouldn’t be successful until I changed something?.  Of course, I soon realized that the person didn’t intend it in mean-spirited way at all, and that, in fact, he was right.  I do tend to let my enthusiasm and energy overwhelm the need to be thoughtful and inclusive.  Oddly enough, I also tend to be inclusive overall, wanting to keep everyone involved.  The two forces conflict, and the energy one sometimes wins out, such in this case.  This particular institute, I found myself on the minority of ideas a lot, and therefore caused some tension now and then.  I was frustrated by my group, overall, and even apologized to them in the end.  So yes, the part of me that gets overly excited to the point of excluding others became an issue.  This card reminded me of that.

Here I am today, at the EDUCAUSE Leading Change Institute, and I’m working hard at asking others for their opinions and letting others do the talking and presenting.  I’m not saying I’m doing a good job of it – but I am definitely letting others talk.  And I have to admit that it’s been really tough.  I want to say every idea I have, and I want to be the one to present it to the attendees.  I want everyone to know that I’m a presenter, comfortable talking with people, affable and funny.  I feel this especially at an event like this because I don’t know the other attendees very well.

But I know I need to let go, and I need to trust in others.  I have been trying really hard, with mixed success (as I was writing this sentence, I interrupted someone just out of enthusiasm.  Definitely still working on it).

It will be a good thing in the long run and I still have a ways to go.  I am determined to reel myself in for the rest of the week, and ask others for opinions and actively listen as much as possible.  I want to be thoughtful.

Not easy, but an important skill, without doubt.

embracing ignorance

I have been working on this post forever – well over a month.  My apologies.

Back in November, I was returning from a conference and was on the shuttle ride with two women from the UK.  They were here on business and had only 1.5 days to see San Francisco.  I gave some tips about what major sites to visit or, if they preferred the less crowded spots, some ways to finding the more hole-in-the-wall restaurants, etc.  Overall a good conversation.

At one point, though, I demonstrated a remarkable level of american-centric ignorance.  I mentioned how, at the conference, I was at the snack area between sessions and ran into someone from the UK who was confused about why there was honey available by the tea selection.  Showing some poor judgment, I presumed that while sugar and milk were staples of tea in the UK, honey must not be used at all.  I commented to my two shuttle-mates that this was a great example of differences in culture, even down to how we drink our tea.  I thought I was being pretty intelligent and insightful.

Of course, I was immediately informed that many, many British tea drinkers use honey, and that I just happened to be speaking with someone from a family that did not.  I felt rather foolish.  Why would everyone in the UK drink tea exactly the same way?  Why would I make such a presumption?  How could I let my ignorance rear its head so dramatically and embarrassingly?

As I slowly let myself off the hook for this, I realized that this was an important lesson and reminder about dealing with one’s ignorance.  In a social setting, one probably wants to avoid looking so poorly.  Best to know your stuff before opening your mouth.  But in a professional setting, where one is managing a disparate array of services, you have to embrace the fact that you will be relatively ignorant of at least some of those areas.  You have to push past that and still ask the questions that need to be asked, even if you look like an idiot.

As I’ve embarked on a few new projects lately, it’s become clear that I am really short on detailed knowledge ins some areas.  I’m not a systems person in general, have never managed anything beyond Windows Server 2000 in my life, and am a completely blank slate when it comes to networking.  It would be easy for me to either shy away from these topics or, at a bare minimum effort, just delegate it out to others and be hands-off.

The first scenario isn’t an option.  These are important topics (especially since networking goes out into security) and they cannot be ignored.  The second option – just letting others take care of things with a form of blind faith – is a truly bad idea because it involves completely detaching myself from potentially core operations (which, in turn, affect long-term strategy).

I have no desire to manage our network, but I’m going to ask questions.  I don’t want to know which Cisco switch is the right one, but I want to know why we want this feature vs. another.  And perhaps why we shouldn’t consider a different brand altogether.  I’m going to propose alternatives, even if those ideas are completely ludicrous and excellent examples of my lack of knowledge in the area.

I have to embrace my ignorance on these topics.  I have to embrace ignorance on a lot of topics.  At some point, if one continues to move up in an organization, he or she will be overseeing some area that is not within one’s expertise.  Ideally, you rely on your team to be the experts.  But our team is very small, and we honestly have no true networking staff available.  Even if we did have more staff, it would be unwise to completely disconnect merely because I don’t know the language.  Trust your team, but stay engaged.  Continue to ask others to explain concepts “as if you were a 4 year old.”  Read that article in the tech magazine and ask whether the big flash advertisement for some new product means anything.

We’re all basically ignorant about some topics.  At a dinner party, I’m not going to talk about firewalls and 802.11AC wireless (for more reasons than just my lack of networking knowledge…).  But at work, I’ll be the first to ask.  And the second, and the third, until someone has taken the time to explain to me to the level that I need to know.  I don’t need to know everything, but I can’t remain ignorant, either.

out with the old, in with the old

As a leader and manager, there are few times as trying on one’s…patience and personal confidence as when a project designed to improve operations is well planned, coordinated, and apparently implemented…and fails.  When one has taken a problem area, identified a solution, yet finds the institution in the same exact undesirable situation again and again.  I recently had this happen, and it has left me questioning everything from my core abilities to, at times, my sanity, it seemed.

I think that everyone hopes that, with a new year (in this case a new academic year), a new page will be turned, old problems will subside, and we will be faced only with new challenges.

I am certain that the 4-5 people that will read this are already laughing cynically at that statement.  We all wish this.  We never seem to get it.  And it’s not always that the problems are the same ones – sometimes it’s just the nature of the problem. Sadly, sometimes it is literally the exact same problem as a  year ago, with the exact same cause, and the exact same limitations in why we cannot find a better solution.  Budget constraints mean we can’t implement a new solution.  Staff issues (office politics?) stand in the way of change.  There simply isn’t a better way to get something done, within the nature of the current environment.

But occasionally there is an opportunity.  And hopefully that comes about because of good planning, strategic thinking, and months and months of wise decision-making, well-considered pros and cons, and decisive leadership (exaggeration added).  We do the right things over the summer (or even just “since the last time that process broke”).  We analyze the issues, suggest changes, get bids, and put in place a “fix.”  We use best practices.  We use proper project planning. And things still go awry.

These can be the times that are the most trying.  There are few things that can wear down someone involved in a project, from planner to implementer (and sometimes those are the same person…), than going through all the “right” steps only to have things unravel just like before.  To see an elegant fix turn out to be just another sub-optimal solution with as many problems as before. We all have our stories.  Perhaps one day we can all share them.

My next post, coming shortly, discusses the trials of trying to be a good communicator during such situations.  That’s part of good management and leadership, too.  Being present, visible, and taking responsibility.  But sometimes that means putting one’s self in the line of a lot of fire and flak just to keep a face to the organization, and that is certainly wearying, too.