January 2000

Volume 15
Number 10

Just Say No

At the IT Faculty Support Group=s weekly staff meeting, the group=s manager describes a request from the faculty for a new service. AWhat do you think?@ she asks.

AOh no! Just what we need; one more new service to provide. As if we weren=t busy enough already!@ AI don=t see how we can handle that with our existing staff. Have you tried to hire programmers lately? Technical professionals are almost impossible to find and who can afford them?@ AIs this something our group should do? We=ve never done this kind of thing before and it doesn=t conform to our mission statement.@ ADo you know who asked for this? Professor Enark! He is just impossible to work with. Nothing we ever do makes him happy. And if we do this for him, we=ll have to do it for everyone!@ AYou don=t think we should take this on, do you? These things might look simple at first, but you know that once we commit and get started then, wow, we=re in up to our eyeballs forever.@

And so it usually goes. Our first impulse is to just say no. The best technical minds at this meeting do their best to find reasons to kill this new suggestion before it takes its first breath. The truth is, though, it is always very easy to say no. What=s hard to do is to find some way to say yes despite the obstacles. How often can we just say no to our users before they all go away? Not as long as we seem to think.

Unless it is illegal, immoral, impossible, or detrimental to the university, our users, or ourselves, we ought to try to say yes. Our users don=t ask for something unless they have some problem.

While it is essential that we determine what their problem really is before we dash off to solve it, once we determine the real need we should always try to fill it.

If you are one of those people from the meeting above I can already hear your first objections: AWe have finite resources. We can=t be all things to all people. If we said yes to every request that fell on our laps we=d never get anything done. You know, we don=t have time to do everything that anyone asks.@ We say, Ano, no, no.@ We never tire of maintaining the status quo. But IT is a service organization and needs to be a group that always says yes, unless it absolutely can=t. Our justice system demands that a person is innocent until proven guilty, and we should take the same approach: our IT organization must insist that the answer to a user request is yes, until we can prove that a no is justified. Usually we do this the other way around.

Given that it is so much easier (and so much more fun) to destroy a suggestion than to implement it, how do we get a group to switch from no to yes? The answer of course lies in good leadership. The person presenting the idea should exercise good leadership skills by not just opening the floor for discussion, but by first making the case for implementing the idea and supporting it. It is quite different when your leader says, AHere=s an idea. What do you think?@ then when he or she says, AHere=s a great idea that I think will do wonderful things for the university and will bring happiness to our faculty and staff. How do you think we should go about getting this done?@ The important question is not, Awhat do you think?@ or Ashould we do it?@ It is, Ahow can we provide this service to our users?@ Once we understand what that will take, we can look at the tradeoffs for doing it.

Getting to yes
Realistically, of course, there may be reasons not to do it. Although those reasons are easier to come up with than the reasons we should do itCand how we will actually get it doneCwe need to collect all the pros and cons about this suggestion. Write them all down with the name of the person who made the comment next to them. Do this on a flip chart or on a blackboard. Let everyone see those ideas and their owners during the discussion. Get the pros and cons discussed. Watch how much of the carping and negativism disappears when you write on the flip chart AOh no! Just what we need; another new service to provideCMary@ and ask Mary if she means we should never provide another new service.

But although nothing makes it more obvious that something is silly than giving it lots of exposure, the most important reason to write things down is to keep the meeting focused and to give participants ownership of the solution. Ownership should be followed up with rewards for ideas that end up being used and appreciation for those that are not. Rewards can be as simple as public acknowledgment of a valuable contribution.

A real objection that is bound to be raised is that there is not enough time to take on the new thing given the load that is already being carried. Have you ever heard someone say something like, AI don=t have time to look at your report today.@? They don=t really mean that they don=t have time today. Everyone gets 24 hours of time each day. What they mean is that looking at your report is lower priority than the other things they are doing today. Don=t allow objections based on resources to deter you from doing a project. Turn, Ano, we don=t have the time, or money, or people, or whatever@ into a question of priorities. To do this new thing what would we have to give up doing? Is there anything of lower priority than this that we could give up to do it? This makes the answer yes, with an understanding of what it will cost to do it.

New ideas
At a design meeting for a new system, Tom, a member of the design team, suggests an unusual solution to a complex database problem.

ATom, you always come up with the goofiest ideas. Can we get this meeting back on track? Don=t interrupt unless you have something constructive to suggest.@ AWe=ve never done things like that. It is so unnatural and unintuitive! That is not the Euphoric State way. Furthermore, I don=t think it is even possible to do it your way.@ AThe user will never sign off on this and it will take twice as long to do.@ AOur users don=t need the new features you propose, Tom. Users have gotten along without something like that since computers were invented. They certainly don=t need it now. It is just an unnecessary frill.@

Although we know that every new idea starts out in a minority of one, it is a wonder that any make it past the people who just say no. How did we ever accept the telephone? Weren=t there people who knew we had gotten along without it for centuries? Why would people want to talk into a box? It is just so unnatural and unintuitive!

While the leadership techniques in the previous case all apply here, beating down the naysayers in a technical discussion takes some extra effort. Don=t let someone say something is not good without having him or her offer an alternative they believe is better. If A is not good and there is no alternative, then A is the best there is and you=ll have to use it. As Winston Churchill pointed out, ADemocracy is the worst form of government, save all other forms@; we=ll always use the worse solution if there is none better.

We only keep doing things the same way for efficiency. New and innovative stuff takes longer to do and carries the risk of failure. If a group knows that failure is not an option, then no one will be willing to take risks and nothing innovative will ever get done. It needs to be understood in a technical meeting (and enforced and encouraged by the leader) that no idea is silly, no question is dumb, and that history, inertia, and unsubstantiated speculations are not good enough reasons to say no.

Write down and discuss every idea. Demand more than one approach to each problem. If you only have one approach to a problem how do you know it is the best and not the worst? With two approaches you can at least decide which of the two is better. Forcing at least two approaches will often make people think a different way about the problem. Once the problem is looked at in a different way and people feel freer about suggesting even their Acraziest@ ideas, then you=ll be on the verge of seeing the really good solutions flow. Even Acrazy@ ideas have a way of spawning solid solutions.

It=s not my job...
A user stops by the multimedia design laboratory to extract some digital images from a VHS videotape. While there, she asks for some pointers on searching the Web.

AWe don=t provide help on searching the web. We are a media design laboratory.@ ATry the help desk, ask your peers, or read Web Searching for Dummies, but we aren=t the place that can help you.@

Sometimes our mission statements and job descriptions make it seem that it is our duty to just say no. If we didn=t, after all, we=d be breaking the rules. But there are often worse things than breaking the rules. Telling a user to go away is one of them; especially if it is an important user. And what user isn=t important? Even a few burned users will give your group a bad reputation that will survive long after you=ve solved the problem. If we need to break some rules to say yes, we should at least consider doing so. Don=t forget, however, that we=ve never done that before; and that is not the way we do things here; and if I do it for you it will set a bad precedent are not rules. They are excuses for not providing the best service we can.

Here are some rules for when it is probably ok to break the rules. But, of course, there are times to ignore these rules too. In the end, you=ll just have to exercise good judgment, which no set of rules can supply you with under all circumstances.

If you are asked to do something that would help a user or colleague but breaks the rules, ask the following questions: Is it illegal, immoral, impossible, or detrimental to the university, our users, or us? Is this beyond my ability or my group=s ability to do? Will it prevent us from meeting other obligations or commitments? If we don=t do it, will the user be able to get it done quickly and easily some other way? Will it be expensive in time or money to do? Is there some obvious liability or danger in doing it? If your boss or your boss= boss asked you to justify what you had done, would you feel uncomfortable doing so?

If the answer to all these questions is no, then you should probably ignore the rules and provide the help. Don=t forget that doing something is usually better than doing nothing. In the case above, if the user wanted days of instruction on searching the Web, which might have been impossible due to other commitments from the media design lab, it might have been enough to spend 15 minutes teaching Web searching and then point the user to specific ways to learn more about the subject or to other people that can help. If there really are no good ways to get a user=s problem solved, the IT organization needs to address this shortcoming.

Good news, bad news
At a conference, Susan comments on how good some of the presentations are, while others, she says, are awful. ANo presentation from my group would ever be less than wonderful,@ says Irene. AI have my staff listen to every presentation and critique them until they are outstanding.@

AOff the record, Irene, I know many members of your staff,@ says Susan, Aand they say the critiques just don=t work. You have people critiquing the talks of their managers and they are afraid to say anything bad about them. That=s why you always only hear such good things.@ ANo way. My staff isn=t afraid of being open and honest,@ shoots back Irene. AThis scheme really works. You should try it.@

It is very difficult for anyone to give anyone else bad news. Most times people are too afraid or too nice to tell you. It may be even more difficult to deal with bad news when you are lucky enough to get it. But getting bad news is a rare and wonderful opportunity that allows us to improve things we might otherwise be blind toCunless we just say no and deny it.

What has your IT organization done to encourage users and colleagues to give you bad news? If you=ve done nothing, chances are you won=t get it. Do you have a suggestion box that is really anonymous? Are there rewards for suggestions that improve the way things are done across the university? Do you encourage folks to report problems that they see, even when those problems are the responsibility of another group? Does your staff individually feel some pride and responsibility for all IT services offered at your university? Once you learn about a problem, do you ensure it gets the appropriate attention? Do you kill the messenger? Maybe even more important, does the messenger believe that he or she will be killed? Bad news does not mean you have bad people. All people make mistakes and everything we do can be improved.

Finding the truth
A university added a computer component to all of its creative writing courses. During and after the first semester this was tried, a questionnaire was sent out to all students asking them if they liked the addition. The results were very positive. Everyone welcomed the opportunity to Alearn more about computing than I thought I would ever know@ as one student replied. But someone in the IT group thought a group outside of IT should interview the students independently just to be sure there was no bias in the survey.

ANo. Don=t you trust us to do a simple questionnaire?@ AWhat more could an outside group tell us than we already know? How could we be biased?@ AWe have already spent all the time and resources on this than we should. Let=s extend this program to all other university courses.@ AWe are the professionals who built this system and the results are wonderful. Why are you always so negative?@

Usually that would be the end of it. But in this caseCtaken from a real universityCan outside group ran filmed focus groups of students who all agreed that they liked the computer component. But a common thread that was totally missed was that the students felt that: AThe computer stuff was great, but it took almost a third of the time that I should have spent doing creative writing. I feel I really missed a lot of what this course was supposed to be so that I could learn about computers. How am I ever going to make up for the stuff I missed?@

There=s a serious problem here that needs to be addressed, but it will never be seen it if we just say no. More often than we might be willing to admit, we need an outside opinion for what we are doing.

Just say no to no
These are just a few examples of how IT people sometimes say no. They say it because it so easy to say, but it is a great detriment to their users and to themselves. It stifles creativity, locks them in the past, and limits their vision to the end of their nose.

Your users expect a cutting edge IT group. Saying yes means figuring out how to do something new and innovative. That may be a prospect that causes butterflies in your stomach, but to grow and prosper you must learn to say yes. If the urge to say no remains irresistible, just say no to saying no. 

Howard Strauss is manager of advanced applications at Princeton University and a frequent contributor to this publication.

Top of article

The Edutech Report is a monthly publication of Magna Publications

The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President:William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.