My house is filling with beautiful sound emanating from my living room speakers. It is a single tape loop playing and it has been playing for the last 45 minutes. At first I was entranced by it, then lulled into meditation, and now fully contemplating its relevance to my current thoughts. The loop is slowing and mutating with each pass. It is dying. Tones stretch across time and then are lost, their absence resulting in a shift of rhythm. Sometimes their dying crackle calls out and stays with me long after they are gone. The music is d|p 1.1 from William Basinsky’s Disintegration Loops I.
This series of recordings was created from the last breaths of a collection of old tape loops that Basinsky found and was transferring to digital. As the tapes played, they disintegrated and he continued to run the transfer until they were gone. What results is a melancholic symphony to the inevitable decay into nothingness in one sense, and an incredible spiritual of hope in another. The powerful work is far greater than the slight loops that nourished it. It now lives and inspires, has transcended the mechanical intent of transcription and warmly resonates with my emotions and finds connections within my thoughts. It strikes me as the perfect illustration of the strained metaphor that I’ve based this series of posts on: the idea that a true culture of Innovation is sustained by feeding off of the corpses of its failures.
The Liquid Network Illustrated
Remarkably, I didn’t realize the connection when I stopped on Basinsky’s name on my ipod and, in a split second, decided that this was what I was in the mood to wash dishes to. As I settled in front of my computer later to stare blankly at the page of notes I have been carrying around for weeks with the intent to write this post, I let myself be absorbed by the music and suddenly found a connection. I don’t mean to imply that this very connection should be considered Innovative. The work itself is Innovative. I have just been inspired by it.
In Part II of this series, I presented our plan to build what has been referred to as a “Liquid Network” to support a Culture of Innovation within our workplace, providing just enough structure to enable Innovation without deadening it. In looking at Basinsky’s example, the structure strikes this delicate balance and provided what was needed to enable the Innovation. There was a structure inherent in his process to carry out his intent of transferring the tapes (he didn’t just let the tapes disintegrate in a box alone, which could be seen as analogous to ideas in a “Gaseous Network”), but this process only got the tape loops rolling and a recording started. He didn’t have a process in place to try and control the end result. Any planning to control the final output (analogous to the “solid network”) would have stifled Innovation: nothing new can enter the system, as you have defined all the outcomes. He pressed play and record and let his ideas and Nature collide into beauty.
The Liquid Network In ACA
In our office, v2 of our structure was introduced and, to the team’s credit, most everyone jumped in, coming together for bi-weekly meetings to discuss the projects and converse about Innovation.
The meetings were broken out into two parts, the first to discuss the work being done on projects, and the second a structured forum to promote discussion around UCD and any other topics that seemed relevant. In our first meeting, we broke into small groups to discuss what each of us was passionate about in our field or in our work and project ideas that reflected these passions. We came back together to share our ideas, posted these project ideas, and self-selected into project teams. The teams then decided what their next steps would be in the 2 weeks until the next meeting.
While this might seem like a rigid structure for a Liquid Network (meetings make people scream), the structure simply serves to promote communication and interaction between individuals and ideas. Additionally, no structure dictates how the project teams do their work: they get to decide how and when when to move forward or to stop progress on a project. Teams and individuals can switch projects at any point and if progress is not being made on a project, its documentation goes into the project archive where it is available for other teams/individuals to continue or to build upon.
To support our Culture of Innovation between the larger meetings, it was established and reiterated that any individual, no matter what project they were working on, was invited to contribute to another project team’s work and discussions. The expectation was set that all team meeting notes, project specs and other working documentation would be linked off of our Innovation wiki page to aid in transparency. Lowering the bar for non-team members to enter into the discussion, one channel (#Innovation) was dedicated in our chat client that all the teams used for project communication and a public Google Calendar was created for project teams to post their meetings.
As you can see from the diagram created to explain our Innovation process, we made it very clear that the final goal of these projects was not implementation, but a spec or other final documentation submitted to our product backlog. This backlog is a living archive available for project teams to scour for inspiration and, if so inclined, to carry forward through implementation in their Innovation time. Our Director also has access to the backlog and can create an official project team and charter, removing the project from the Innovation backlog and turning it into an official UW-IT project.
Is it Working?
Quickly, it became apparent that we were seeing some real success represented in:
- Broader understanding that 20% Innovation time is an ingrained and protected part of our culture
- Continued and regular progress on a wide variety of projects that are all of obvious benefit to the UW community
- Far more people participating regularly, including individuals joining us from other groups in UW-IT
- Project teams that represent a rich diversity of perspectives all focused on the same goals
- Active, cross-team communication and collaboration around projects and process
- Transparency around project decisions, progress, ideas, and expectations
- While this may be a combination of different variables, we have also seen far more cross-team, cross-discipline discussion, experimentation and collaboration bleeding into our regular project work than was evidenced prior to v2.
- Dedicate and protect time and effort for Innovation
- Get explicit Administrative buy-in and backing
- Leave it to individuals to manage their own time w/in the explicit limit (ours is 20% time)
- Regularly remind everyone that they should be using this time (ex: we include Innovation as a regular impediment to project sprint work)
- Establish a rhythm
- Regular, all-team meetings are crucial to keeping people informed and engaged
- Reporting of progress on projects
- Discuss project goals for next 2 weeks
- Think of it as a support group for Innovation
- Regular, all-team meetings are crucial to keeping people informed and engaged
- Establish expectations and common understanding around:
- project documentation
- the communal nature of projects and ideas
- the goal of getting projects documented in the Product Backlog
- when and how projects go into an implementation phase
- Enable cross-team collaboration and communication
- Ensure that communication channels lend themselves to pubic and not team-specific discourse (ex: having one #Innovation channel that all teams used; invite sharing and discussion in the all-team meetings)
- Someone in the organization needs to own the Innovation process.
- Act as Innovation evangelist
- Set meetings and agendas
- Constantly iterate on the process and structure to tune it for your organization
- Learn from failures
- Keep all-team agenda simple: The all-team meeting agenda was initially bloated. We have since pared down the meeting’s structure to the bare minimum to get reporting and conversation flowing.
- Lower bar for cross-team collaboration: Need to rethink how teams can open their meetings to non-team members. Google Calendar was totally outside of most of our normal workflows.
- Eliminate barriers to participation that still exist: Investigate why some people are still not participating and, if they have a desire to participate, see if there are some adjustments that can be made to support their needs.
- Accept that Innovation may not be for everyone: Be comfortable with the fact that some people will choose not to participate.