Technology and Organizations
Yesterday was Reid-Hillview Airport Community Day. One of the activities was a tour of the Control Tower. Great experience. Thank you to Vincent and Spencer for taking the time to explain the process that keeps hundreds of flights going in and out safely. Thank you to the rest of the team for letting us observe you at work.
I was surprised by how physical the process is, versus my high tech expectations. Yes, they have access to radar and a huge portion of the work involves radio communication with the pilots going in and out of the airport. But they also make heavy use of those big windows and a unique physical tracking system. They track planes by type, tail number, and request for inbound or outbound route -- by writing the information on plastic "pucks" with a grease pencil, and then physically sorting that puck onto the taxi and runway slots.
We weren't allowed to take pictures, so I'm showing a similar process below using wooden blocks.
When I asked about the process, using the plastic pucks versus keeping track on a computer, I was told that sometimes "elegant is best." Great point! The solution is elegant in that the physical blocks trigger sensemaking (in my words) more than a screen version might. They can push a puck slightly out of its track to highlight that more action is necessary. All the members of the team can immediately step in to provide relief given their common understanding of the system. Elegant, green (no need for power or paper), easily visible to all in the room -- good for team visualization. Beautiful approach to a complex problem. Sometimes systems savvy means using elegant, but less high tech systems. Comments appreciated describing other examples.
... and those you want to join your network. My elder niece came home from pre-school one day talking very seriously about making "good choices." Apparently a little boy in her class had not been making good choices and was sent to a different room. Making good choices becomes more difficult the more choices you have. I'm struggling with making good choices about my own knowledge sharing.
I generally share my knowledge via (in order of formality and timeliness): Twitter, Business Exchange, this blog, class, and my academic publishing (pdf of my vita). Each of these channels ties me to a different network. The networks overlap to a small degree. Below I present five dimensions to help my clients (and me) make good choices about sharing knowledge with their networks.
This is another topic related to how we all are becoming systems designers -- we all need to make good choices about how we share our knowledge so that we get the knowledge to the people who need it, when they need it, in a form they can use, and in a way that doesn't overburden them.
These are decisions based on technology, organizational practice, and people: part of TOP Management. Formality and timeliness are two dimensions I've already mentioned. For example, I don't tend to post to Twitter about past research unless some new and hopefully interesting thought strikes me. On the other hand, I don't necessarily expect academic readers to be interested in this week's current event given that the article won't be out for over a year. To do otherwise would be to ignore my audience's perspective. Content interest is another dimension to consider as you share your knowledge. I assume that my networks are interested in gaining benefit from managing technology and organizational practice, and innovation more broadly, or they wouldn't be following me on my Twitter/Business Exchange/blog/class/academic networks.
That said, I do toss in a sailing or golf reference from time to time because it provides context about who I am. I like knowing a few details about my own knowledge providers gives me background for interpreting their content. It also gives us more of a social connection if we have the chance to meet face to face. Kind of like the beer effect without the beer. I'm told :) that detail and depth are issues I should consider as I share knowledge. References (e.g., Barley, 1986; Weick 1979), as part of the sentence are not as interesting to most people as they are to academics. (Really, they are interesting to us!)
Each of my channels provides the opportunity for more and less detail and depth -- either by technological limitation (e.g., Twitter and 140 characters), human preference (e.g., my blog audience's interest), or organizational requirement (e.g., the APA Style Manual). Signaling is my final dimension, so far. Signaling is how you let your networks know that there has been a new contribution. Some of the technologies have their own signaling capabilities. A few examples:
- Twitter: Network members can decide whether they want email or SMS notification of new posts from specific network members.
- Business Exchange: Network members can follow specific topics or specific people. Business Exchange then summarizes new activity on the user's homepage.
- Blogs: Network members can opt in to to automatically receive new contributions via RSS reader or email.
Ideally, some contributions on one network will be of interest to members of other networks. Often I post announcements of new blog posts to Twitter, my LinkedIn account (the short message area on the bottom left), and my Facebook account. I give enough information so the people on that network will know if it's worth it to click through or not. My blog is also tied to LinkedIn's Blog Link and NetworkedBlogs on Facebook. As long as these networks have limited joint membership, this crossover signaling is ok. The more interconnected your networks become, the more careful you have to be about duplication.
Duplication is akin to spam. We all have multiple opportunities to provide original knowledge contributions (a blog post, and comment to a blog) and/or to share valuable links. I've provided these dimensions:
Do you have other dimensions that will help us all make good choices?
Bruce Nussbaum recently asked via Twitter whether design thinking was the new liberal arts. He describes design thinking as "the integrative solvent that brings together the programs through a powerful methodology that solves a myriad of problems." He says we should be moving away from the MBA and on to the MBD (Masters of Business Design). I agree with the importance of "design thinking," but will focus my thoughts here on systems design.
Systems design more clearly, for me, includes all of technical, organizational, and people systems than does the term "design thinking." I'd also push ahead and say not just "liberal arts," but "general education." Basically, I think Mr. Nussbaum and I are both saying that systems savvy and design skills are critical for all of us, and need to be included in broad-based educational offerings.
Universities are getting on-board (and I hope high schools are as well -- do you have any links to share?). Atwater, Kannan, & Stephens published a 2008 study of the extent that Business Schools teach "systemic thinking." While the definitions varied, the majority of the top 63 graduate schools of business were teaching aspects systemic thinking, and 74% of the respondents agreed that the topic was essential in graduate education.
How do we teach systems design skills to people without a technical systems design background?
A simple translation of the basics of systems analysis provides a start. I've translated Hoffer, George, and Valacich’s information systems analysis concepts to a more general work systems form with the acronym: BUILDER. The idea is that the first skill you need is how to map where you hope to go with your systems design, and the context that you must deal with to get there.
- Business objectives: These are the basic motivations for what you're trying to do. You may not think of them as "business objectives," but it will certainly help you get organizational support if you do. For more personal systems design, just ask, what do I hope to gain from this new tool (e.g., iPhone upgrade) or practice (e.g., telecommuting)?
- Universe: Context and history are valuable both so you can learn from past efforts, and to help you begin to understand the other stakeholders' interests. Understanding these interests are critical to any future "negotiated implementation."
- Information needs: Who needs what information, and in what form? For example, in team performance, Transactive memory: Knowing who knows what, who needs what information, and how to coordinate given that knowledge is a key predictor of success.
- Laws: Policies, required procedures, regulations, and the like are an important backdrop to any design. Perhaps you don't want these to limit your initial thinking, but they ultimately have to be considered, even if just to attempt to change them. For example, financial firms may have federal regulations regarding the archiving of communication. In those settings you must conform to regulations even in the use of social media.
- Dynamics: The time frame and sequencing of stakeholder interactions and build order (Do I have to delete an existing application before I can install the new one?) are the basics of this aspect of the mapping. For any major information technology design it should have "full backup" as a first step.
- Events: By what milestones should the design and implementation be judged? How will you know if you are progressing in the way you hoped? What metrics can you use to track the process. Tracking is critical as otherwise you can't know if you need to make adjustments.
- Reach: What is the magnitude of this project in terms of people, money, number of other systems touched? Reach also helps you consider the ROI. How much investment in the process is wise or supported given the reach?
I see BUILDER as providing a set of mapping topics to prepare for the design process. I look forward to taking the next steps: What is design thinking in the context of work systems design? What do all of us need to know? How do we evaluate our TOP (Technology - Organization - People) design skills? Do we need everyone on the team to have these skills, or is it enough if just one of us does?