Saying No

clip_image002What do your users have in common with your children and your pets? Sometimes, they have to be told “no” in an effort to help them learn to be more self-sufficient. OK, if your pets include cats, telling them “no” and expecting them to learn is a fool’s errand, but I think you understand my point. In addition to the need to be told no, users, children and (some) pets have ways of making it difficult for us to say that word. There are lots of reasons we don’t want to say no, but the big three are:

  1. We want to be liked.
  2. We genuinely want to do what they ask, or let them do what makes them happy.
  3. It’s often easier to do something for them than it is to teach them how to do that thing for themselves.

If you were to ask the users in our company, they would probably tell you that my approach to technical support would indicate that I don’t care about being liked. That’s not entirely true, being liked is nice, but I get paid for being effective. In order for IT to be effective, we have to strike a balance between providing technical support and helping people grow in their understanding, adoption and their own effective use of the technology we provide. This has always been the case; there has always been a fine line between support and coddling on the one hand and encouragement and indifference on the other; walking those lines has never been easy. SharePoint, at least our SharePoint installation makes walking those lines even harder, because the lines are moving. Maybe that’s the whole point of the SharePoint Maturity Model, but I’ll leave that discussion for others. The simple observation is that the further we extend SharePoint beyond the ability of our users to understand it, the more it becomes an IT product.

In trying halt the progression described in the last sentence, I can honestly say that I’m not prone to coddling my users. I might not actually say “no” to people asking for help, but I am becoming a fan of saying: “…here, let me show you how to do that.” The distinction is a finer line than you might imagine. Someone who simply wants a problem to be solved considers that approach to be the equivalent of my saying “no.” But even if we (IT) did everything for them, our SharePoint implementation would ultimately fail. SharePoint growth is fed by the dual inputs of response and insinuation. Most of the progress we have made to this point has been the later; people have asked for help, and we have declared that “that would be a good use of SharePoint.” Far less progress has come in response to people asking if we could change, extend or create a new SharePoint solution. That we do get some of those requests is heartening, but we have to work to keep them in the mix. As our SharePoint solutions become more complex, more aggressive, more dynamic and more useful, people have to understand more about what is going on behind the scenes.

A recent example surfaced as we were demonstrating the management dashboard that I wrote about here. The dashboard highlights individual items and aggregate results that are necessary for managing a process. Most of the results on display are linked to a detail view that better illustrates that aspect of the process – Reports by Engineer for example. As we were demonstrating some of these views, people started suggesting changes. Many of their suggestions just involved altering the sort or filter parameters of the view. We took the opportunity to remind them (demonstrate) that they can dynamically introduce those changes in ANY view, at ANY time. It is very important to remind people that even once a solution has been “developed”, that the results are still in SharePoint and all of SharePoint’s inherent functionality remains available to them. We (practitioners) know this, but people who are not as familiar with SharePoint as we are, may not recognize that a view is a view is a view. In addition, many of them are not adventurous enough to take the approach of saying “let me just try this…” Our history of building and delivering “systems” has conditioned people to thinking that what they get from IT is what they have to work with. This perception will change as we incorporate personalization features into our next generation desktop systems, but right now, SharePoint is leading the way toward the consumerization of IT at our company. I also recognize that they have their own job to do, and that I am asking them to extend their domain to include parts of ours. Like I said, it’s a fine line.

3 thoughts on “Saying No

  1. "Probably the most common mistake we make in our automatic thinking is overgeneralization."I really like what you say, how users have been conditioned to work with what they get. But not all users are created equal. Instead of trying to educate "the users" in general, I find it more efficient to deal with a few chosen ones who will champion changes and then educate their peers.

  2. Christophe – I only noticed this comment recently. Thanks for reading. You make a great point about not all users being equal. Focusing on the ones who can help you in the education effort is a sound approach.

Comments are closed.