I was chatting with a colleague about the new EDUCAUSE slogan, “Uncommon Thinking for the Common Good” when I realized that the saying encapsulates one way to think of my work as an I.T. Architect. “Uncommon Thinking for the Common Good” is what I try to foster in the teams that I work with. I’ll explain this in two parts “Uncommon Thinking” and “for the Common Good”.
I try to break people out of their daily routine and their comfort zone. For instance, I have sat in meetings where a team is supposed to develop a new user interface (UI) for a new application. I’ve watched as team redraw the UI for the old application, that they use day-in and day-out, as the solution for the new system. I’ve also seen teams “re-think” how a business process could be done. The end result was an automated version of the current process. The new implementation of the old solution substituted emails for people running around with paper. They are following the same steps, replicating the same authorizations and sending the same forms often without asking “why this form” or “why this person” or even “is this necessary at all”. My job is to get them to question their old ways of doing things.
People like what they know. They understand what they use daily. But advancement comes when we change and disrupt routines, not when we replicate them into a new technology. You have a telephone book at home with White Pages for people and Yellow Pages for businesses. Changing that into two Word files you can print doesn’t bring great advancement. It might be easier to carry only the pages you need but that doesn’t really improve the process. Search capabilities are a big improvement. Rethinking how you use the information, such as mapping businesses onto maps so you can find restaurants near your hotel, that brings advancement. The routine of grabbing a book and looking something up is thrown out. The new routine is to grab a laptop, look for wireless and Search.
I often introduce myself to new teams saying that my job will make them uncomfortable because I will ask them to throw out what they know and what they are comfortable with. I tell them I will challenge their assumptions. I say this not because their assumptions are wrong but to make sure their assumptions are correct and we accept them for the right reasons.
I love the fact that the Web 2.0 explosion is going on. There are so many examples of “other ways to do things”. I bring these examples and ask, “why can’t we do this instead?” I show them Netvibes and ask, “can we make our pages this flexible?” I show them Etsy’s Find By Color page and ask, “can we make creative ways to search like this?” I show them The Northface catalog and ask, “should we have filters to help people search like these?”
It’s not that I think we should have a UI that looks like any of these sites but I want to break the team’s mindset and get them to start thinking about all of the rich possibilities. I want them to work with a blank canvas and a rich palette of colors. I want them to really get imaginative in their solutions to the problems.
I had a watercolor instructor that I worked with at UC Santa Cruz. We were painting in the woods one day. Everything I produced came out flat, boring and uninteresting. They were awful, actually. I was having a terrible time. He came by, had a look and asked how it was going. I grunted out my disgust. He said, “Give me three paintings, but you can’t use any browns or greens at all. No earth-tones.” I’m sitting in a forrest of browns and greens. I was forced to paint purple and blue trees and red ferns. At first it was very uncomfortable and I was very hesitant. The first attempts were also awful. But then, it became fun and playful and the paintings improved. I was forced to let go of “how it is” and instead I had to play with “how it could be”.
That is the uncommon thinking of the Architecture practice. Letting go of the how it is and thinking about how it could be when we start with a blank canvas and rich palette.
For the Common Good:
The other aspect that I deal with on teams is the narrow focus of their solution. Often, the solutions that are put forth solve the very local needs of the group of people sitting around the table. My work is to ask, “how does this fit with the broader issues that the people deal with daily?” “What does this solutions do to actually help people?” “What impact will this have on them?” Not all solutions should be broadened and generalized to solve a larger issue but we should consider their larger impact.
Every application must fit into an already rich application environment. No application is truly a silo-application anymore. Someone has to use it. That someone already has a username and password if not several. That someone already has a day that is full of tasks and applications. That someone has things that don’t work so well, things that they are comfortable with and things that they cherish dearly.
The impact assessment of a new solutions should consider all of those people that the solution will effect. If the new process changes their lives from reading paper documents to reading email, the users might not consider it an improvement. What if reading the paper documents is what they do on the train in the morning? Then your solution is a step backwards for them. What seemed like a good idea to the team, reduce paper and use electronic delivery, actually was negative impact to the user and to overall productivity. The user did that work before they got to the office as part of their daily routine.
This is part one of the “For the Common Good” part of my job. The solution that is delivered needs to take into consideration all those that will be impacted and it needs to fit into their lives and, ideally, change their lives for the better.
The second part comes into play during information gathering and sharing about the solution. The new application or solution needs to be described in terms of the business value and the overall positive value of the change. If you are going to add work to busy departmental staff, then it better be for something more than “your system”. It better be for something like improving the enrollment process for students. It better be for some larger good than simply benefitting the group developing the solution. You need to gather the business process improvements that the new solution will provide and then use those improvements to describe why the solution is important.
The final part has to do with scope. Often, issues in one group are problems in another group too. Finding co-sponsors is a way of expanding the positive gain for the new processes or solution. I spend time looking for others who I can bring into the discussion. I look to see if the problem can be solved once for several constituents. The broader solution will require collaboration and compromise but it can bring greater value and reduce the chaos of one-off solutions. If the problem is solved once for many groups, then there is only one solution to maintain and there are many people who can provide input and expertise.
For me, “for the common good” means considering the broad impact, looking for the greatest value and delivering a solution for the largest constituency.
Uncommon Thinking for the Common Good:
Bringing this all together provides one view on what I do as an I.T. Architect. I get people to think broadly about a solution. I get them to use a blank canvas and a rich palette of ideas when thinking of how we should solve a problem. I also get them to think about how that solution fits in the larger environment, who it will help and who it will impact and finally who else should be brought into the discussion so we can deliver a far-reaching solution.
If I do my job well, then we get truly creative and expansive solutions that fit into the organization, improve peoples lives and help the greatest number of users.
Technorati Tags: EDUCAUSE, IT Architecture, Jim Phelps, Leadership