Cisco Blogs

Collaboration with Scrap Lumber & Bailing Wire

January 30, 2012 - 0 Comments

I’ve always worked in creative environments with a lot of interdependent roles and processes – and big, unyielding deadlines. Twenty years ago (did I just type that?!), it was editors, writers, designers, artists, production teams, salespeople, prepress film houses, printers, and all of the rest involved in producing magazines. My role was at the intersection of the creative work and technical production. Sometimes it all happened as a meeting in one room, other aspects involved sneakernet, sending disks and film back and forth via couriers. Missing a print date cost big dollars. You didn’t miss the dates. Ever. 

Where's my sweater?Being a bit of a geek with a logical streak of an engineer’s daughter, I was always looking for ways to add structure and streamline processes. (This is not unlike trying to put a wet cat in a sweater.) I developed a successful, but perhaps unhealthy relationship with spreadsheets that I used to hold information – deadlines, story details, status, page counts, art files, page ratios. I dutifully maintained my trusty grids and could answer any question about any bit or piece along the way. But hand anyone else a printout and their eyes would cross and roll before they simply restated the question. The spreadsheets held data; I was the mechanism for sharing data – the user interface, so to speak.

In another role and another decade, technology had progressed quite a bit. Instead of stalking people in hallways, I now spent a freakish amount of time sending e-mails to ask various people for status on project elements — asking again when the e-mail got “lost” — then collecting that information and throwing it into a mental blender. Every week. Although they’d become more complex, spreadsheets were still the primary information vault.

At the end of the process, I could pour out a PowerPoint smoothie of consolidated information detailing the overall project status, danger zones, and prioritized next steps. We’d meet weekly, when I’d share the information and we’d review status, collect more information, modify priorities, and march forward until the next week when we’d shift this way and that according to what happened in the previous week.

Small projects weren’t too bad. But my projects weren’t generally very small. Take the website component of a major product launch: 40 new pages and 50 updates, 65 photographs, 7 videos, 15 writers, 3 marketing communications managers, 4 editors, 6 web developers, and any number of marketing people interested in the well-being of their particular products and pages.

Some people expected that, as the project lead, I had insight into the minds and inboxes of the individuals on the project, no matter what state, county, or time zone they inhabited. As many Psychic Friends Network commercials as I saw during late-night TV, the skill never took hold. Answering a status question took work because of so many interdependencies. We weren’t even approaching the idea of “real-time.”

As people started getting used to the concept of shared folders on servers, I started posting a simple deadline and status spreadsheet so anyone could access it – at any time. I still collected and synthesized the data, but now I had a new way to distribute the information. As much as I appreciate a friendly phone call at 4:45p on a Friday, I don’t usually like it when a “gotta have it now” action item is attached.

The project team got used to receiving a link to a spreadsheet as a response to update requests instead of “Billy Bob will have the content to Janie Sue for editing on Tuesday.” Then they started bookmarking the link instead of sending me questions.

That was the first step in my nefarious plan. The next was to ask people to update information in the shared file. Sometimes a passive-aggressive approach worked best: When they saw blank spaces on the grid, they’d fill them out themselves. Or when items suddenly turned bold red, they’d move them higher on their own priority lists.

As with any new process, some people were quite comfortable in the armchair of “we’ve always done it that way.” But even a few people doing their own updates made a difference – for everyone.

As people realized that going to the server for information and files was easier than chasing e-mails, more of them put their toes in the water of “the new way.” Another benefit – mitigating the problem of a single point of failure (me) in the event I won the lottery and disappeared. All the project information was accessible, even when I wasn’t.

As much as I can put all of this in past-tense verbs, I realize that not everyone can. I happen to work in an environment where finding ways to use and share information more effectively is a priority. The armchair of “we’ve always done it that way” isn’t very comfortable here, probably because of the rocks under the cushion.

Compared to actual collaboration tools like Cisco Quad, my spreadsheets and shared folders were chewing gum, bailing wire, and scrap lumber. They were a rudimentary prototype for the tools we have access to today. They worked to hold information, but weren’t designed for collaboration.

The main difference now is that we’re moving from a practice of sharing information to one of conversation, shared activity, working together — collaborating.

Now there are many tools specifically designed not just to hold or create information, but to share information and support collaboration. Whether it’s a shared workspace or web conferencing, anything that lets you interact more effectively can improve collaboration. And more effective collaboration means better results, faster. And faster results means more time to go buy lottery tickets.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.