STEWART MADER AND SHARING SYSTEMS SAVVY
/
Don't let the words get in your way
Using systems savvy in organizations often means helping others develop this capability for seeing both technical and organizational opportunities, and then finding powerful ways to weave them together for a better, faster, smoother work design. I've had the pleasure of highlighting the experiences of a variety of leaders in prior posts (compilation here). Each of these leader's stories shows the value of helping others develop systems savvy through hands-on effort rather than by direction. That's the way most of us learned systems-savvy and it turns out to be a fine way to help others in their own development.
Today I'm adding another of these stories. Stewart Mader, Director, Enterprise Client Services at Social Media Group and Founder and Editor of Future Changes helped me see the value of a new, but parallel theme: Don't let the words get in your way. That is, don't let the terms (e.g., wiki, open innovation) put a barrier between you and the people you're helping to understand systems savvy.
Focus on the work
Stewart focuses on the work in his Wikipatterns book (my review) where he talks of project and community support that happens to use a wiki. For example, in thinking about how technology tools and meeting practice might work together:
Instead of emailing the agenda, put it on a wiki page and email people a link to that page. If changes need to be made, anyone can do so and everyone will have immediate access to the same, up-to-date version. Then, record minutes on the wiki so all information pertinent to the meeting is in one place. The further advantage here is that the responsiblity to take minutes doesn't have to rest with just one person. No matter how carefully one person listens and takes notes, it's really difficult for one person to accurately capture everything that happens during the course of a meeting. One person may pick up on a certain detail that another person misses, so using the wiki can give everyone a place to contribute, resulting in a more comprehensive account of the meeting. Keeping meeting agendas and minutes on the wiki can be the perfect foundation for project and task management. As various topics and items from a meeting are discussed and need further action, new wikipages can spawn from the agenda or minutes and be used to manage them. (p. 31)
His description isn't about a specific technology or philosophy, it's about getting the work done. He describes how to integrate the technology and the organizational practice, but the focus is on the work outcomes rather than the trendiness of the approach or talking through the differences between a wiki or a blog.
Stewart highlighted in a recent conversation the importance of helping people realize, technology or not, that they're interdependent with others. If they don't think about this interconnectedness, then they're less likely to provide an electronic, or any other kind, of agenda. He noted that people can spend too much time debating what the terms should be (e.g., Enterprise 2.0) and that bad terminology (I gave the example "socio-technical systems") can distort peoples' views. For example, "cyber security... negative: cyber bullying, terrorism, Hal [from 2001]." Regarding Enterprise 2.0:
People are so caught up in ideological arguments around what it should be called. All are weak. When I go into an organization I help them find the best content that people write internally and then amplify that using their social media. I help people structure their job responsibilities, line them up to their personal goals -- measured the same way as any other job. Making sure the internal organization is properly equipped in terms of [technology tools, organizational practice, people skills] to support that work -- it doesn't need a term applied to it becuase it's part and parcel of their work. Makes it as efficient as possible.
What I find useless about whole [Enterprise 2.0 terminology] discussion is that when you create a new term for something you create a distinction that makes the casual observer think it's totally different. For example: Blogger vs. Journalist... There are some variations in research, ethics, pay, but functionally they're the same.. When people get caught up in the terminology, they lose focus on the part that's the same... Slows down implementation as they think it's about adoption. But in reality in an organization, you want people to get work done, first and foremost. If you create a divide, Enterprise 1.0, 1.5... you have people thinking that they need to do additional work to drive adoption of each "new" thing.
This creates a false conflict between "management mandate" and "grassroots effort" when in reality all you need to do is find the best examples of strong, coordinated team work and help them become standards throughout the organization.
Experts often use jargon to signal their expertise
That is a great way to set yourself apart -- but is that your goal when you are trying to share systems savvy? That's not the approach I heard in my conversation with Stewart: T: When you first talk to a group about an engagement. What words do you use?
Barn Raising is often the first term I use to describe a session designed to help a group structure their collaborative efforts. It sounds nothing like a technology jargon term because it originated in farming communities in the mid-1800s. People would get together to pool efforts and build each farmer's barn in time for the harvest. By working together, barns were constructed in less time, and the best construction techniques made their way into more structures than if people worked individually.
It's not about the words, it's about the work. Help people see the value of systems savvy from the perspective of their work. Don't lose the part that's "the same" while demonstrating the part that's different.
