Traction User Group 2010 - Brian Tullis Presentation

Editor's Notes

• #5: These are some of the many wonderful thinkers and practitioners out there that helped us directly and indirectly, and whose ideas we have used and remixed. Thank you.
• #8: We have the perhaps not unique situation of working for a company that grew by acquisition, leading to a complex hairball of legacy business processes and accompanying IT platforms. We work in a highly matrixed environment. Most of us have at least two bosses; some of us more - although I don't think any of us have 8 bosses like Peter Gibbons in Office Space. We are a public company, so we have Sarbanes-Oxley to worry about. On our team, we have a charter to deliver common IT-enabled solutions across dozens of locations, each of which is evaluated by a stand-alone P&L. The people we work for are highly focused on manufacturing and engineering, rather than the black box of IT. We are always looking for ways to improve ourselves and our team’s performance. We cannot change the world, but there are some things squarely within our control. Our challenge is to figure out how to structure our team and our processes to meet our mission. We see Observable Work as a key enabler to our mission.
• #9: We start from a point of view that says that there is something fundamentally broken about the way that knowledge work gets done in most organizations. Basically, everything Jim said. It was in ours, and in some ways still is, but we are taking specific steps to address that. Here is a cross section of issues and concerns that we have. How can we: Share what might be half-baked ideas that would benefit from outside input, but that we don’t share openly for fear of being shot down? Document and share lessons learned on projects/audits/operational failures so that we don’t repeat the same mistakes again? Narrate our work so that we don’t have to drag each other into status meetings and waste our collective time reporting what we did instead of letting status emerge naturally from our visible work? Make our electronic documents come alive and be linked across an organization instead of going to die in networked file shares and content silos? Describe exactly the heck it is we are talking about when it comes to social media being used to get work done without calling it “Wikipedia for the workplace” or “Facebook for the enterprise”? Ultimately what we are trying to bring about is a basic transparency to what are traditionally black-box knowledge work processes. And we are in IT – IT is the deepest, darkest, most obscure of the black boxes that exist in most organizations. We mean transparency in the sense of getting as few as two people that work for the same company on the same project to be able to see and to understand explicitly what each other is doing…so that together they can create a better outcome for the organization. And if we’re lucky, add-on benefits of in-the-flow communication, strategic alignment, and knowledge re-use all emerge from this first principle of helping teams get work done. Perhaps this doesn’t seem like a big deal. But my experience is that in most organizations, it is, and we don’t like to talk about it.
• #11: In using the term silos I am thinking at all levels of organization - roles within a department, across departments, locations, business units, between companies. As much as I would like to, I don't want to seem naive and say that silos are 'bad' and that they must be smashed. I think that we can try to make them permeable . In fact, I believe that managers have a responsibility to make their own silo as permeable as possible. The real underpinning of the first four principles is trust. No one is going to feel comfortable working across silos, outside of their normal chain of command and comfort zone, without it. I don't have a formula for that, but it takes time, and you can lose it in an instant. We are social where required, but it's not something that we dwell on. The social aspect deserves a little more discussion. A pure focus on Information and Process Flows tends to ignore the social dimension of how we live and work as human beings. Our ability to be effective will suffer greatly if we neglect this. Being IT guys, and introverts at heart, remembering this is not always easy - but we try to get a little better at it every day – although I don’t think that we will ever groom each other like the chimps in that slide. We seek simple solutions to business problems, fighting a tendency to over engineer just because it is possible. What we do and how we work is highly interdependent with the rest of our organization. Finding and leveraging these links adds value and relevance. Surfacing these links and finding the relevancy of each individual action makes work more rewarding for everyone involved. The point about status is subtle, but important. We believe that working this way can reduce overhead and administration, allowing everyone to focus on doing work, not reporting on it. Joe will touch on that in his case study
• #12: This slide is an attempt to show you how we have broken down the Observable Work concept. People: Organizational, cultural, psycho-social, and management elements that enable an Observable Work environment. Process: Techniques or business processes that put observable work concepts into practice Technology: Underlying technology that supports implementation of the processes. Here, the idea is that through a combination of the right people, using the right underlying technology, you can implement processes that will make you and your team more effective. We struggled with how to categorize the patterns. Also, we do not pretend to have an exhaustive list. The individual patterns are mutually reinforcing and related – it’s a little messy to try to segregate them
• #13: The title of my track at Enterprise 2.0 Santa Clara is “Community Development and Management”. I will say that for the longest time, I discounted the need for any consideration of this softer stuff. I typically started with a vague notion of process, jumped into enabling technology, and then perhaps we would do a little organizational or stakeholder analysis as some minor change management task. So far I am concluding that the People patterns are most important; however, they are the hardest to define and replicate widely because they are so dependent upon specific organizational contexts. We are going to give it a shot. For the sake of time today, I am actually going to skip these because they are the hardest to condense into a few slides. I will skip straight to the Process and Technology patterns for some meaty examples from our TeamPage server. I hope to explore the people patterns more during the workshop on Thursday morning, and I will have slides and full speaker notes for all of the patterns available for you.
• #14: Strong ties to start Existing “in the flow” work processes – meeting notes, project status, or, well, grooming. Starting with strong ties, we can build positive feedback loops spread to more use cases, and hopefully more teams (eventually leveraging weak ties) So what does this really mean? Take an existing team or organization, defined in a traditional organization chart, formed around specific projects, or ad hoc This team is held accountable collectively for deliverables; strong ties; there is an innate sense of “we” that they bring to their work. In our case, where we started was “AFS Information Services”. We are an IS/IT organization within one business unit of Communities of trust usually have existing work processes that can transition to an Owork method, and use cases do not have to be invented. This can speed adoption. Start small, because everything is political. Within smaller groups you can build positive feedback loops around Owork experiences. There is a very important concept of building these communities in the flow of work. The only way we have found to align individual interests and motivations with those of the group is to start in the flow of work and give individuals benefit from using various tools and techniques. Then and only then can you extend to small communities, large communities, and the entire company. That’s our experience at least. As they join other teams and groups, they bring an Owork philosophy with them.
• #15: Discuss AFS IT example of multiple locations. IT guys working all over the place. Multiple bosses. Finding use cases around small teams, building up with strategy, etc. Simplified example shows potential starting points. There are others… The extent to which you need to think about this depends on your organization’s complexity and culture. This simplified chart taken from our own experience shows hundreds of potential communities built around the corporation, business units, functions, project teams, and various subject areas. We have found that you really have to start somewhere and solve problems in an existing community, before building something galactic in scale that solves everyone’s problems.
• #16: Leader, servant, sociologist, emergineer Bridge communities of trust, leverage weak ties within and particularly across communities. Every group needs one. Needs multiple. This is not one person, or a few people. There really needs to be one on each team. Embedded in Owork processes, lead by example.
• #17: Beyond ice cream, we need to share our questions, concerns, problems, answers, work products. It is more critical than ever that we do this today in our siloed organizations - within a departments, across departments, locations, business units, between companies. As much as I would like to, I don't want to seem naive and say that silos are 'bad' and that they must be smashed. I think that we can try to make them permeable . In fact, I believe that managers have a responsibility to make their own silo as permeable as possible. This is difficult even within communities of trust, enabled by competent community managers. Some cultures are just not receptive to this. This is just hard. To quote a fellow 2.0 Adoption Council member, “We can't talk our way out of a culture  we behaviored our way into...we must behavior our  way out." There is an important point to make about innovation as well. We are coming to learn that innovation is something that happens on the edges. It is already hard enough to do anything remotely innovative inside of large companies. If we are not sharing what we do, then I think that we are missing the point. We talk later about the concept of narrating your work. It doesn’t make much of a point to narrate if you’re not sharing with anyone. As an example, approximately 40,000 of my colleagues can view every project deliverable, blog post, strategic communication, procedure/process documentation, audit report, and compliance test done on my team. It is something that I would like to see spread.
• #18: What we do and how we work is highly interdependent with the rest of our organization. Finding and leveraging these links adds value and relevance. Surfacing these links and finding the relevancy of each individual action makes work more rewarding for everyone involved. If we wait until we are “finished” before we “post” something or store it for public consumption in the content management system, then something gets lost. Context. The “how” of knowledge work products. Unfinished business from days or weeks or months ago that can be picked up and finished later by someone else. Snippets can be remixed into something bigger and better. [quote Patrice Livingston via Paula Thornton – “infrastructure for synchronicity” here] “ I knew at an instinctive level that what we were doing — all the unstructured communication, all the relationship building and stuff that our team was doing — was much more valuable than the work we were doing in written reports and meetings and minutes, which is what consumed the body of our time. See context for knowledge work products. Tolerance for things unfinished but that are available and can be finished later. Not only does this facilitate problem solving, but it also promotes innovation because these unfinished bits can be fuel for future innovation (narrated, in-process, and shared – it’s all related).
• #19: Process patterns are specific techniques that you can use.
• #20: Dave Winer coined the phrase “Narrate Your Work”, or at least popularized it. I can share what it means for us. It may well mean other things for you. In our environment, we struggle with knowing what is going on – where ARE we on this project / task / issue etc. What was the thinking behind a certain strategic decision? Why was a certain document updated, what exactly changed, and what does it mean? We have to keep working files. We have to track action items. We have to take notes. We have to record our thoughts somewhere. The more visible we can make those thoughts in the form of narrated work, we can unlock a lot of value that we never knew existed. Assuming that we have in place a culture receptive to “in Process” information, enabled by community managers operating within communities of trust, then narrating your work can be a fairly simple solution to the “where are we, what’s the context, and why did we do this” questions. This concept goes well beyond semi-official status-type information. If we are narrating what we do, we get extra information that can be useful not only to the project and task at hand, but for other, currently unknown uses down the road.
• #21: A real world example. We have an IT project that involved the migration of a large number of distributed applications to our data center. The article contains some basic instructions at the top that explains to the reader that what they are see is an Excel file that is updated live inside of the browser, and every time progress is made on the project, or anything fundamentally changes, or if the project resources make any kind of progress, they make a comment to the article. When we took this screenshot there were 168 comments to the article. If you want to know what is going on in the project, chances are that you are going to find it here. This is not brain surgery, folks. Our colleagues have to track their complex work somewhere, and in my case, it’s in my company’s best interest to set up a culture and give them a platform where they can do that so that it’s effectively shared with everyone else.
• #22: Status from visible work is a special case of Narrating Your Work. Here, the explicit purpose of narrating your work is that you can eliminate non-value added status calls/meetings/emails through making available your work through an activity stream related to your project/issue/task. Activity streams are a topic we’ll touch on later in Technology patterns. This is not to say that we do not write status reports per se. It means that when we do meet, we can focus on real issues, conflicts, and escalations, rather than telling everyone exactly what we did last week. A brief status report that points to narrated work fixes that problem. We will focus more on this in our project management case study.
• #23: What’s the status of the Customer Returns Test Scenarios? By reading this article, we can find out – Is the scenario complete? What were questions from the customers? How did we react to those questions and change the article? Are we complete with the end to end process? Has everyone approved it? This example is a test scenario for a customer return process, part of a major system upgrade. The business analyst who created this article had some simple goals: describe the business process that needs to be tested within the software get feedback and approval from colleagues in Customer Service, Quality, and Finance Notice the paragraph-level comments by Customer Service and Quality - there is a threaded discussion in the middle of this test scenario. At the bottom of the article, there are "I approve" comments from everyone time and date stamped, with links back to their profiles. A key takeaway is that we invent lightweight processes as required using text, tags, and comments. We did not trade emails to collaborate and we did not use a structured workflow or business process management system to accomplish the approvals. We strive to create and share all of our work products just like this – for projects, strategy, compliance, documentation, budget, etc. Approximately 30,000 of my colleagues can read that hypertext article if they need to see it, and 2,500 can comment on it. If we need to show them, or pull them in for collaboration, we can. Over to Joe.
• #24: The example we have chosen to illustrate building links between silos is 2010 Global IT strategy wiki article. It is important to note that even within a single functional area like “IT”, you can have content silos and process silos that keep content and information segregated from each other. In our world, that would be Strategy documents and articles, blog posts, regular communications updates, compliance procedures and tests, projects, and various person and location profiles. This really has nothing to do with having things available and open. It means actually taken the step to build links between pieces of content and most importantly, between traditionally siloed processes. As a simple example, there’s a really simple way to show that some of our major projects are aligned with our strategy – they are directly referenced and linked. We also believe that there is a direct benefit to increasing employee engagement in this particular scenario. This comes through people seeing how their work supports the larger strategic goals of the organization.
• #25: Within the technology patterns we will show a few examples of
• #28: We will not win any design awards with our Spartan activity streams and news pages. We extend the concept of activity streams deeply into our platform. We heavily use functionality which allows the construction of search widgets called “Sections” to be placed inside of any individual article, allowing us to pre-build searches for our users. This is really important in a world where you are narrating your work. There are rules to respect when it comes to article titles and tagging, but we can transparently enforce those through the use of “Add” buttons which automatically apply the proper tags.
• #30: We thought that an interesting technology pattern to discuss would be “Living files”. This technology pattern is closely related to the People Pattern “Responsibility to Share” and the Process Pattern of “Narrate Your Work”. This is really where the rubber meats the road in Observable Work. We have a complicated relationship with all of these electronic files that we have created over time. Can’t find it. Don’t know how it relates to other files, within and outside of its current silo. If you can find it, you only have a final version of it. It’s not searchable by the enterprise. Maybe you find a copy that is called version 10, but you might really need version 4 because that is what your customer or supplier is referencing at the time. Someone updated the project plan, but the only thing you really know is that the “last modified date” changed and it’s now 4 kilobytes bigger – but SO WHAT?! A living file is any electronic file – usually Excel, Word, or Powerpoint equivalents (with MS Project, Mind maps, PDF or other file types thrown in). A living file exists IN CONTEXT with its environment. Many times, there is active collaboration happening around and within the file. We strongly believe that in cases where you might have used MS Word you can make it a wiki entry, so history and version tracking are built in. If it must be a specific file type, you need a hypertext parent article, with associated comments, that are linkable and discoverable to the rest of the enterprise that needs to see it. A living file evolves over time, and its changes are narrated by the authors and editors. Good practices are to say what changed from one significant version or revision to another, and WHY. The why is perhaps more important than you think. Because of volume of electronic information that we create, if the why is not known at the time of creation or change, it is perhaps lost forever. While I think it is important to capture WHY for your colleagues – it helps you yourself to remember what the heck you were thinking when you did something. The Narrate Your Work Process pattern example from earlier illustrates this well. I will show it again here – it’s an Excel file scorecard, displayed in a web page, that gets a comment any time there is any significant change.
• #31: Here is the scorecard again. I hate to use the same example, but it’s a good illustration that I can show publicly. The matrix in the middle is a live Excel spreadsheet. Here, we are pointing out the number of comments – 168 total. Each of the applications in the first column gets its own comment group in the threaded discussion. SPC Proficy has 24 comments. We have also used this technique with various Powerpoint presentations, documentation in Word or PDF, and other Excel files. The more important and strategic the file, the more we try to do this. Obviously, you can’t do this with every single file you create. Or you could, and maybe if we did that, we’d create fewer files!.
• #32: What we tried to demonstrate today was the concept of Observable Work and how we have implemented it on our team. I hope that we have succeeded in that. It is a journey, not a destination. The most compelling value proposition we have found is the elimination of waste processes in project management and other non-value ‘status’ situations. If you have a supporting culture with able community managers, shepherding your community through these techniques can be a very rewarding process. Your mileage certainly will vary. We have purposefully stayed from a discussion of vendors and platforms. There are a number of solid platforms available today that allow an Owork philosophy to flourish, although it is likely going to be pretty rough going if your only tools are email and networked file sharing. We do not want to leave you with the impression that we have found the holy grail of productivity and collaboration and the application of social software to work. We have a set of principles and underlying technical solutions that work for us. Going forward, we want to continue to learn first, and teach second. We are not sure that this approach scales up and out, but our approach is to start small and build out. As this technology space evolves, it will have implications for us. We can only hope that the principles we have identified can be implemented in any platform, regardless of vendor or underlying technology. Otherwise, we are too busy getting work done to worry too much about it.
• #33: Thank you for your time. Thanks to my colleagues as well. All of the examples you saw here are just their "Observable Work" in action. You can connect with us on Twitter or LinkedIn. You should get a copy of this presentation through participation in the conference. There are a few slides in the appendix with more examples as well as some statistics about our platform and other technical details.
• #35: We are a leading fastener manufacturer, supplying both the aerospace and heavy industrial markets. If you have ever flown on an airplane, our parts helped get you to your destination. The context is an IT organization serving a global manufacturing company. Our case study shows a bit about how that works in practice.
• #37: Please see Jon Udell's article. As best I can tell, he invented the term Observable Work. There's lots of good stuff here. From time to time, Joe and I will continue this discussion online in our blog, where we talk about productivity, collaboration, and project management. We would love to see your feedback there.