GAINING VALUE FROM BLUE & WHITE COLLAR SYSTEMS SAVVY - BEN KEPES

I had the great pleasure of meeting Ben Kepes to talk about systems savvy - peoples' capability for seeing and weaving together technical and organizational opportunities. This was a perfect first meeting: quick understanding of the basics and then exciting new extensions as we talked about how people in different roles may have very different forms of savvy, and the impact this can have in the organization. Ben is the principal and founder of Diversity Analysis, a consulting company helping companies work with the cloud and business strategy. He works as an industry analyst, consultant, and journalist. I had seen Ben's Change the System, Not the Technology post and was thrilled to see he was in San Francisco for SuiteCloud2010. A few emails and tweets later, we were talking in the lobby of his hotel. I asked Ben about his experience with technology, organizations, and people; how these three dimensions are woven together in organizational settings. He talked about the common problem of an organization trying to implement "some whiz bang technology, but it doesn't work, or the culture doesn't accept it." We've all seen this silver bullet approach and know it doesn't work. Our conversation turned to how the situation could be improved. Ben gave me an example that made a lightbulb go off:
One of my businesses is a manufacturing company. White collar and blue collar. Slowly we've been implementing some collaboration technology. Really simple tools: email, calendar, manufacturing planning. It's interesting to watch our facility managers (blue collar) grasp the stuff. The technology doesn't work the way they think.
My initial interpretation of Ben's comment was that the technology doesn't work the way the blue collar folks think it does, versus, what Ben was actually saying, that the particular technology doesn't work the way the blue collar folks think! The mental models held by people in the two roles are different. One is not better or more sophisticated than the other, but they are different.
White collar [management] deploys a tool that they [believe] is entirely obvious. Unfortunately that's not the way it works for the [blue collar] workers. Difficulty [for the people supporting the implementation] -- is there is a blanacing act. To a certain extent the blue collar folks need to use the tools, but you have to balance between requiring them to use and the underlying the cultural aspects.
I asked what would happen if the implementation support team didn't understand this balancing act: "Huge disconnect, blue collar workers would feel alienated; people deploying the tools, really concerned." The problems could span the organization even to disenfranchising the people making the purchasing decisions as they see the investment causing conflict. Ben suggests two solutions:
  1. Focus groups -- though groupthink could be a problem if the focus groups give the answers that they think you want to hear.
  2. Better is to build transorganization groups from lots of different departments from the beginning. "You need some idea about the problem we're trying to solve. We're trying to ensure that communication and collaboration can happen across disparate geographical teams. Let's get them in a room and watch them work toward the goal. Goal driven rather than tool."
Version 2 seems to me to highlight an understanding that the members of the different departments and organizational roles (blue collar/white collar) will have different ways of understanding the technology tools and organizational practices in play. How these groups think differs by their context and goals. By working together on the task the teams can learn who knows what, learn who needs to know what, and learn how to coordinate in the given setting, with the given tools. (Experts on groups would call this a great way of developing transactive memory, a valuable group capability.) The different roles have different types of savvy, ways of thinking, that lead them to these different perspectives. Their practical understanding, their wisdom, is set in different contexts. Even if they all have systems savvy around the connections between technology and organizational practice, their systems savvy will be set in their unique context. Only by working together to create a common context, as Ben suggests in the transorganizational group approach, can they gain value from their diverse perspectives and build a system of technology tools and organizational practices that adds value for all. I haven't talked about the importance of context in systems savvy and I thank Ben for this enlightening example. I expect to push on this idea more with a focus on how to integrate high, but different, systems savvy capabilities. Looking forward to Ben's insights on this and other topics.