Work-related

thoughts from the EDUCAUSE LTL volume 4

I didn’t get to write a post yesterday because I was exhausted.  Our teams do presentations on the 4th day, yesterday, that is meant to “make the case” for some proposal for a fictional institution.  We worked late into Wednesday night, I was rehearsing my section of the presentation even later than that (into Thursday morning), and then the presentation itself certainly was a high pressure situation.  We were all just very, very tired.

I’ll have a recap post at some point of the entire experience but, as was the case the first couple of days, a quick reflection is still important.

With all the work done to find our strengths so that we can apply them effectively, I have come to appreciate that strengths can actually be weaknesses themselves.  It’s all about context.  When working in a team where everyone is a highly-motivated, potential formal or informal leader, strengths such as being an Achiever (wanting to accomplish things), an Arranger (always understanding how things work together), and Input (wanting know more and more) can be a problem.  They can make me inpatient, they can make me potentially disruptive.  Considering the effort put in by my fellow teammates, I can only hope that I did a mildly effective job of keeping myself in check.  Perhaps most of the time.

This means that there is even greater nuance to dealing with strengths and weaknesses than I had realized.  Before, it was know your strengths, which helps you understand your weaknesses, then either address the weaknesses head on (out of your comfort zone) or find a complement.  But strengths themselves can be weaknesses.  My, this can get complicated.

One thing I saw during the building of our presentation was that all of us having to just buckle down and get the thing done allowed our “executor” strengths to come through, and then our other strengths could rise above that.  It was almost like a base or “safe space” for us to start opening up.  I felt a lot more comfortable knowing we all had this common goal that included a timeline, where we really knew we had to just get down to it.  But even so, no one stopped indicating those existing strengths.  I found this fascinating and I truly enjoyed just turning to others and saying “I’m not good at this, someone please help me.”  Others rose up, gave me ideas, and things came together.

Considering that “leading from where you are” is a fundamental part of leadership in general but also key for those of us that are parts of larger organizations, this was pretty cool to watch.

I want to thank all of those at LTL 13, and to my teammates on team 5 in particular for an amazing experience.

thoughts from educause LTL volume 3

So..I’m really tired, and this is going to be short, to be honest.

Last night my team worked on finishing the presentation we will make today to the “senior administrative leaders” that the LTL faculty will be “playing.”  We are to pitch a specific idea, with implementation, budget, etc., that will address a strategic concern of a college.

Until last night, I have to admit that I haven’t felt completely at ease with our group.  This is not a statement about the people, much less about any one person in particular.  It’s about trying to form a team made up of people that have all come to a workshop designed to build leadership.  This is a group here to become better leaders.  Putting us in groups is going to cause some unease.

But there is nothing like a project, trying to make something concrete, to bring people together.  As we worked together, our skills and strengths emerged naturally.  Even more impressively, the way we offered to help just flowed.  Someone would ask for help (I know I did several times) and others would start working on solutions.  One person made headway, and ideas were thrown about, and we ended up with a great product.  When we did a run-through, we all gave feedback equitably and fairly, and we have, I think, a solid product.

I don’t know what today’s reflection piece will be, but I know that last night’s collaborative experience will be the sticking point for me for the day.

thoughts from the EDUCAUSE LTL, volume 2

I a still at the Learning Technology Leadership program from the Educause Institute, and the latest reflection piece we’ve had is on leadership.  Unlike the first assignment, this one was done in the morning, before getting on with the day.  So it’s shorter.

We were asked to discuss how the first day’s discussion may have changed our views on leadership.  My response follows, and additional commentary past the jump.

While the concept of leading from within a group (rather than at the forefront) is nothing new, the discussion that stemmed from the governance committee model at Northwestern still struck a chord. Even at a small institution such as mine, where working with anyone means working with everyone, maintaining a steady focus on communications and sharing the ownership of knowledge and understanding is a powerful tool.

Unfortunately, this also takes a lot of energy. I am inspired by the prospects of what such shared communication can provide. Yet I am also concerned about the sheer amount of effort required to sustain such a program.  At a larger institution, you not only have more resources in terms of number of people from your own organization to attend these meetings, but just more people in general.  At a small institution, at some point, these committees are all the same people, and you have to watch for burn-out, disillusionment, and perhaps even annoyance with the process.  That is completely counterproductive.

It will be a delicate balance and I will be adding “informal” to many of the names of these governance/communication groups, but it certainly has great impact, regardless of institution size. And that means it’s worth the effort, in almost any case.

(more…)

thoughts from the educause learning technologies leadership program volume 1

Day 1 of the Educause Institute for Learning Technology Leadership came to a close last night.  For just a half-day session, I am truly exhausted.  I am also excited that such a dynamic experience will span the next 3.5 days.  I’m sure I’ll get a lot out of it.

We are asked to reflect upon a specific topic each day.  Last night, we focused on the results of our StrengthsFinders surveys.  This tool, which I’ve used a few times now and find quite useful, tries to identify 5 strengths based on a big, long series of survey questions.  They are actually statements, and you have to choose which one better describes you.  For the most part, they are not opposed, which means it’s not easy to decide which one fits you best.  So you make a decision that is a combination of logic, thoughtfulness, and gut.

Below is a slightly-edited (just tightened up) version of what I wrote in our internal Yammer group.

(more…)

reversing the magnets

The post title is about friends becoming…more than friends (can you name the movie?), but this is NOT about that.  It is about the nature of a (professional) relationship changing due to a realization of significance.

I recently accepted a position to be CIO at Menlo College in Atherton, CA.  A post about that is in progress but discussions with people motivate me to write this one first.

I have always trusted, respected, and in many parts of my job admired my manager.  She is a professional above reproach who still invests herself personally in her projects.  She treats everyone fairly.  Most importantly, she has been a mentor to me (as much as a manager can ever be a true mentor).  She has helped me along from a  young, inexperienced (never been a manager before) but presumably filled-with-potential subordinate to someone that has, I think, proven to be an adaptable, strong-willed leader of a group that needed change and realignment.  This is no small task for me to have accomplished, and I could not have done it without her support and guidance.

However…when I applied for this new job, even though I respected my manager so much, the concept of trusting one’s direct supervisor to the extent of using her as a direct reference OR notifying her of your intent to apply for another job was foreign to me.  It’s still a bit weird, to be honest, but the concept literally did not compute or exist or…anything.

It’s very difficult to explain in writing, to be honest.  But I can offer my thought process as an example of how I honestly did not even conceive of this idea before.  To me, my instinct is that she is my manager, and therefore I don’t do anything until offer is in hand.  As a manager she will take my efforts as a sign of not being committed to my job, lack of loyalty, etc.  But perhaps that is too simplistic of a view.  In some cases, the layers above that basic reporting structure should be considered.  That step – taking time to consider the relationship as unique and distinct from a generic manager-subordinate one – just never happened.  It never entered into my thought process.

Looking back (a whopping 2 weeks ago) and having spoken to a few people at very high level executive positions at the school and university, I now realize that in some cases, such a relationship is possible.  One has to be careful, and I’m not sure I’ll ever have such a relationship again.  But I do feel that it is possible, and I will, in the future, consider these extra layers as I look forward in my career.

hm.

orchids and weeds. not your normal garden.

A number of years ago (7?), a colleague of mine at Stanford – Carlos Seligo – introduced the concept of “Orchids and Weeds.”  He meant it jokingly at the time, but it has stuck with me ever since.

Basically, there are two ends of the spectrum when it comes to technology, support, and adoption.  There are orchids, which are elegant, beautiful and perfectly aligned with needs but require an incredible amount of attention and resources to get running and properly supported.  It is unlikely that support will become more efficient over time.  Weeds, on the other hand, spring up organically and often as ancillary to something else.  They germinate quickly and soon adoption is very high and usage has proliferated.  Weeds might even be used in ways never originally intended.

An example of an orchid might be the Sakai Learning Management System, which has been developed by universities, for universities, but is quite a beast to implement and manage.  Perhaps even some of the major Microsoft products – Sharepoint comes to mind – would be orchids, too.  They can be ridiculously powerful if done right, but needs a lot of resources to get there.  The two “big” weeds would be e-mail and SMS text messaging. SMS is in particular is a great example.  Originally designed so that cell company employees could report coverage outages and other problems, it has become the primary way for many people to communicate (I send about 2000 texts a month and yet use fewer than 400 minutes).

It is important to note that there is nothing inherently bad about an orchid.  By definition, it is beautiful, elegant, and a perfect solution for the job.  It offers very high value and probably commands a high price (the amount of effort users are willing to expend to access the service).  But the cost is also extremely high.  So the overall value-cost gap (or V-C “wedge” as we’d say in my Capstone MBA course) is smaller than, say, text messaging.

But if the fundamental basis for maintaining a service portfolio is value, orchids are just fine.  You just have to pick and choose the right ones.  And that means a strong rubric for getting rid of the useless orchids (just pretty, but not the right fit) from the truly wonderful ones.

Basing services on value provision is pretty simple.  Well, actual “value” is hard to quantify, even in the business world where there is a number for everything.  But if you start with price – again, the expense of time/effort/distance traveled/hoops jumped through/etc that a user is willing to take on in order to use the service – then you can get an idea of value.  Value is always the same or higher than price (unless you have one seriously messed up measurement system).  If you put something somewhere (physical location of a high-end lab, a web service behind so many clicks of the mouse, etc) and people are still rushing in droves to use it, then the price is probably quite a bit lower than value.  Whether the price is too low is unclear, but it’s not like you’re going to disassemble that lab and move it farther away from the dorms or put even more clicks in front of the web service.  Bottom line – value is high, and it can be gauged if not measured exactly.

So once you have that, you just roll out services that are high value or high V-C.  The value could be high in an absolute sense, in which case cost is not an issue (striking a deal with a cloud-based backup company where the student pays and you get all the kudos but none of the liability).  Or it could be high in a relative sense (buying a bigger SAN for $75000 to do multiple redundant backups of faculty and staff data, on-site, in exchange for peace of mind to those users.  cost and value are high).  But if something is low in value, just don’t bother with it.  Because if it’s not of value to anyone, why are you wasting resources on it?  Worst case scenario, cost is HIGHER than value, and you’re just burning resources for nothing.

Ideally, you go low cast and high value – look for weeds.  Get as many of these as you can because they require low overhead but adoption will be high.  I’m not sure people will “value” it the same way they would with other things but they will surely use the service.  Align your staff to take advantage of these.  Have fewer staff managing more weeds – the ratio will be different.

Then go looking for orchids.  You will probably need project management staff just to test them, then a much lower staff:service ratio to maintain them.  But if you figure out the right potential orchids during testing, then deploy the best 2-5 or so and it’ll be worth it.

 

not reinventing the beeping noise

  • On our 2008 Honda CR-V, we have different beeping, alarm tones for leaving the key in ignition, headlights on, and parking brake on.  3 different tones.
  • On our 2005 Mazda 3, we have a single tone that is used for both the keys and lights.  No parking brake.
  • Of all cars, the 2004 Jeep Wrangler – bare bones vehicle, zip-up windows, etc – had a single warning signal for the lights, keys, and brake.

How is it possible that that three different cars utilize different methods for the simple task of notifying a driver that he or she has forgotten to do something, or left something behind?  The ones that are most similar – the Honda and the Jeep, are almost as far apart as possible in terms of types of car (well, if it was an Acura or something that would be farther…).  And somehow the Mazda can’t even bother with all three tones.  The features of the Jeep – a car WITH NO WINDOWS – are more user-friendly than those on our Mazda.

It’s not as if the beeping sound for the brake was first invented by Jeep, musth less copyrighted (which would be required in this scenario, since the Jeep is older than the Mazda).  Nor the idea of different tones being used in the Honda.  And it can’t possibly cost much in terms of Cost of Goods Sold (COGS), which affects margin, for there to be either three tones or three different tones.

If I had to fill out a form right now asking for features I’d like in a car, having tones (same tone okay, since I can never remember which tone is for which problem) for all of those items would be on that list.  These simple things.  Just take the simple things that others have done, and make sure that you have at least those same things.  Then innovate from there.

How is this at all relevant?  Simple – if you’re running a Help Desk, get the basics of support, time to resolution, quality of customer service, etc , to the standard that others schools with roughly the same resources and limitations have achieved.  If you have a small server farm – or a giant data center – look at what others have done and just flat out copy the best of breed basics.  I don’t mean the whole kit-and-kaboodle.  I don’t mean just copy every last detail.  But there have to be common denominators that have sound solutions, proven over time, that are easily replicated.

Just as Mazda should not spend much time deciding whether or not to put in 3 bells – which can, I think, be concluded is a better solution than just 2 bells – why not just start off with 3, and spend more time deciding if an auxiliary audio input should be put in or not? Or, a year later, when all Mazda 3’s had those inputs because basically all cars had them, how about making the front console more user-friendly or improving something else?  Innovating beyond the basics.

I’ll admit that we are not doing as good of a job at this as I’d like.  And hopefully as we’d like, either.  But once we can get everything to a baseline standard – and it is definitely feasible – then we can start to really mix things up.  Think of new things and build up an overall structure that is above and beyond.

So let’s get started on the foundation.

do more with more, more efficiently, in the same amount of time

I loathe the phrase “do more with less.”  I abhor it.  I loathe and abhor very, very few things in life, and I reserve those venomous verbs for rare occasions.  Yet I both loathe and abhor the phrase and the idea behind the notion of “doing more with less” as a management tool or concept.

The idea that any organization – whether it be an entire institution, a school, a department, or even a single project team – should be expected to provide, say, 125% output with less than 100% resources is utterly absurd.  When this is used during times of economic crisis – which is what we’re looking at right now in higher education – the philosophy can be something of a necessary evil.  When budgets are tight then almost any project will have less than 100% of funding.  When hiring freezes occur then existing staff are spread more thinly across projects.  Resources – both dollars and staff – must be at less than 100% in such a situation.  And at least for the short-term the same set of services must persist.  There simply isn’t enough time to retool an entire department, help desk, or other operation in the face of a sudden budget crunch.  Dollars per capita (DPC) goes down because it has to, at least for now.

But this cannot become standard, ongoing policy.  Service portfolios must be reviewed, staff must be rearranged, and overall operations must be reorganized to accommodate the new monetary restrictions.  Only those services that can be offered at the same, pre-crunch level should remain, and overall DPC should be restored.  This has to happen, or everything and everyone suffers.

So “more with less” cannot work as a long-term response to budgetary constraints.

As a general inspirational philosophy, however, it can have some kind of meaning.  “More” and “less” are relative terms.  Provided that there is not the expectation that we somehow work 125% time (in the perhaps utopian world where everyone works to capacity and capability, no one can work more than 100% of what he or she is capable), doing “more” simply means to provide some additional quality with the work we do.  For me, I use value to customer as the yardstick.  How much value are we offering to our students/staff/faculty (or some subset – residential students?  just the financial aid office?) with our services?  How can we provide “more” value by doing X instead of Y?  Or perhaps by doing a new version of X?

Similarly, “less” just means using a lower quantity of available resources.  It does not and should not mean that there are fewer resources, in an absolute sense, with which to provide the same value.  Just in a relative sense.  In other words, using “less” is all about efficiency.  How can we provide value in a manner that consume less time, less dollars, or both?

Ideally, how can we provide more value, more efficiently than we are doing now?

Taking the value concept further, it is quite possible that there are extremely high value products and/or services that are actually extremely costly in terms of resources.  In a perfect world we offer huge value at a low cost – a major streamlining of workflows for a specific office using open source software that is easy to install and maintain.  But if the value boost is high enough – providing a toolkit that makes Santa Clara Law students “twice” as useful to law firms than students from other schools – then cost becomes less of an issue.  Maybe that toolkit involves building multiple web-based software tools and purchasing, installing, and maintaining a very expensive piece of software that provides practical training.  Maybe it’s worth it.  Maybe not.  But it is a possibility one should consider.  The “more” value part should be the first consideration, with the “less” resources – efficiency – part coming next.  Hopefully if we offer this huge value, high cost solution, at least whatever resources we are expending are the absolute lowest amount required because we are very efficient.

Now – my preferred way of approaching this concept, the only way in which I am truly comfortable espousing anything along the lines of “more” and “less” is to:

“provide more value with more resources, using less resources and being more efficient, all within the same or less amount of time.”

Now, that’s awfully long-winded, but that’s also the history major in me.  It is, however, important that all of these points be included.

Provide more value:  covered above, but again the key thing is that we first want to provide value.  If the customers don’t get the value then we shouldn’t offer it.

With more resources: if I’m asking you to find a way to provide more value, then I’m going to give you a bigger pool of resources – staff and money – to help shape things.  To help form the project at the outset.  Start with loose reins, then bring them in when you are underway and need control.

Using less resources and being more efficient: Of course, it is not acceptable long-term to add services to our portfolio that consume resources disproportionate to the value being provided.  At the least, when pilot leads to production, the service should be streamlined and using fewer resources than all other alternatives.

All within the same or less amount of time: This is key.  We all work 100%.  For most people, that means 40 hours per week.  So what I want is for my staff to do all of this, develop new projects that provide more value, etc, all still within those 40 hours per week.

Of course, if you’re being efficient, then what is really happening is that whereas you provided X amount of value during those 40 hours, you are now providing, say, 1.5X or even 2X in the same amount of time.  The entire department is better at providing more value, and over time we do more with more while using less.

low on resources – what to do?

In my previous post, I discussed the importance of dollars per capita re: resource shortages rather than simply number of staff or absolute budget.  This may be something that all IT leaders have already discovered on their own, but to me, divorcing myself from thinking in terms of absolute budget (well, of course Santa Clara has a smaller budget than Stanford or a huge state school) or number of staff and thinking in relative terms really helped open my eyes.  Basically, the real issue at the university or even project level is how much funding is available per user/customer/student/etc.  It’s not about an absolute budget.  $10,000 for 1 customer is enough to buy a whole dedicated server plus a decent bit of enterprise software.  But the same budget for an entire project meant to serve 1000 students means sapping staff time and other resources from other projects and initiatives.  That actually provides poor DPC for the one project, and decreases DPC for the other one(s).

Of course, low DPC is a problem that plagues many organization, especially higher education.  Let’s face it – many corporate IT departments, for all their notoriety for being somewhat “faceless,” would still laugh at higher ed budgets in relation to goals.  When a for-profit company decides to do X, and doing so requires $Y, then they find the money (or they cease to exist as a company, I suppose).  That’s not the case in higher ed.  So how do we address low DPC?   (more…)

a platform for accountability

As I have been considering various changes in my approach to management, leadership, and IT in higher ed, I am reminded of the importance of accountability.  This is one of the most important parts of a successful team – it is part of the foundation upon which productivity and teamwork rests.  In fact, it is part of a critically important cycle that is self-reinforcing – each phase of the cycle helps strengthen the continuation of that process.  Accountability begets ownership.  Ownership leads to a sense of responsibility.  Feeling responsible results in a greater understanding of accountability.  And the cycle continues.

Accountability must be pervasive, as well.  It cannot be just to one’s supervisor or manager that one is accountable for his or her activities and performance.  Peers must feel that they are part of the success of each of their colleagues and the team in general.  Conversely, not only should managers be able to hold staff accountable, but peers should have the ability to “call out” those that are not helping meet overall expectations.

The thing about accountability as a departmental, top-bottom, bottom-top, side-side trait is that nothing is explicitly confrontational.  Even the most severe conversation becomes about team and goals, rather than personal slight.  Instead of “you are messing up my ability to get my job done,” one can say “we must rely on each other to get this project done to achieve a common, team goal.”  I realize, of course, that we do not live in a utopia and that the former statement will still occur even in the most collaborative of environments now and then.  The point is that co-dependency can become the foundation for discussion in a system that relies on accountability and shared ownership.

The question, therefore, is how to build what I call a “platform” for accountability.  Much in the way that Windows or Facebook is a platform for development of software, accountability can be the foundation upon which projects and communication is constructed.   (more…)