Thinking in bits (not atoms)

During a break at EMWCon, I participated in a conversation with several people about the relative advantages and disadvantages of requiring people to use wikitext markup in MediaWiki (instead of providing them a visual editor). During the conversation, Lex brought up examples of documents with their content locked up as binary files compared to wiki pages with the text readily available and accessible. I mentioned the idea of “thinking in bits” as part of the conversation.

Reflecting on the conversation later, I realized that I have written here and there about the concept, but don’t really have anything pulling all the thoughts together. So here you go.

I first came across the idea of thinking in bits in Nicholas Negroponte‘s 1995 book Being digital. In the book, Negroponte talks about the limitations, the cost, of moving information around as atoms – paper books, CDs, DVDs, snail mail, you get the idea – and how information would soon be converted from atoms to bits. The immediately obvious implication is that it now becomes essentially free to move and share information as bits.

The less obvious, but much more important, implication is that bits change the way you can think about the information. How you can manipulate and repurpose the information. How you can do things that were impossible with the information locked up in atoms. The obvious applications have come to fruition. Email instead of snail mail. Music downloads instead of CDs, and now streaming instead of downloads. The same with video.

And yet…

And yet, the way this digitized information, these bits, is handled is still in many ways tied to the way atoms were handled. Some of this, such as in the music and movie industries, is purely for commercial reasons. Digital rights management systems are deployed so that the company can benefit from the freedom (as in beer) of distributing their content while at the same time restricting the freedom (as in speech) of the consumers of that content. They are shipping in bits, but they are not thinking in bits.

Even from a creative perspective, as opposed to the commercial, this thinking in atoms prevents them from seeing new possibilities for providing engaging and individual experiences to their customers. For example, consider how labels distribute music, how they release the same tracks in the same order on both CD and on services like iTunes or Google Play. This is thinking in atoms at its finest (worst?).

Imagine if they were thinking in bits instead. They could offer an “album” that includes songs from the setlist the band played in your town, or edit the songs at the disc-breaks so they didn’t fade out / fade in. Along those lines, for the individual song downloads they could edit the track so you didn’t catch the introduction to the next song at the end of the song you’re listening too.

The same is true, albeit for different reasons, inside many organizations. Yes, nearly everything is in bits, stored on shared drives, in Sharepoint or email, or whatever system your orginzation uses to “manage” documents.

And yet….

And yet most of these bits are locked up in digital representations of atoms. We are using bits, but again we are not thinking in bits.

Part of the challenge, of course, is a need to accommodate the lowest common denominator. In the case of many corporate processes that lcd is the requirement to print. So, the templates and processes are designed based on what is expected in the final, printed outcome. Of course, once something is printed, there isn’t a whole lot you can do with it except read it and manually extract the info you need. If you have the digital file that was printed, you can at least search the content. But this is really just a faster way of “reading” the document to get to the “good part”.

What if, on the other hand, the document (whatever it might be) was designed and created based on the expectation that it would be used primarily in a digital format, with the printed product a secondary feature. Or that you don’t even know what the final format needs to be.

As an example (since I was inspired to write this by a conversation at EMWCon), creating your contract proposals as semantic wiki entries. The proposal can be collaboratively developed and reviewed and when ready can be exported into the end format that you need. This will likely be some sort of MS Office or .pdf file that can be easily sent to the potential client, but it could just as easily be shared with them as bits and negotiations conducted against that.

I say “just as easily”. This isn’t to say that work wouldn’t be involved, there would be a lot of work required. Designing, implementing, transitioning, executing. Cultural challenges galore. But, as Lex explained in his story about bikes, cars, and messenger services, the marginal cost of making this change can be far exceeded by the benefits you can gain from the change.

 

Meetings in the age of working out loud

Working out loud is typically looked at from the point of view of the person doing the work out loud, with tips and ideas on how to work out loud more effectively. But it is also important for those who are “consuming” this out loud work to understand the process and how they can leverage it in their own work. No one has more to gain, and probably more to learn, from working out loud than the managers of those doing the work. Consider, for example, meetings.

meetings500

Meetings, in general, assume that the process of work is hidden and that the only thing that matters are the results or, in many cases, the current state of the work. So managers will call meetings, or even worse schedule recurring meetings on a regular basis. These meetings are often set for an hour, because that is the default in Outlook and generally the time blocks by which conference rooms are scheduled.

What other factors do you take into account when you plan / schedule a meeting? Some items might include:

  • Agenda

Actually, if you don’t count the availability of a conference room, the only real consideration in the scheduling of most meetings is the agenda, even though it is more likely than not that the agenda is more an outline or a “let’s go around the room so everyone can fill everyone else in on what they have been working on”.  The “this is what we’re going to talk about” gets a lot of attention, the “what do we want to achieve” gets a bit less, and the “how does this contribute to our work” gets barely any attention at all.

When, of course, the most important aspect of meetings, the easiest to measure, and the most overlooked – dare I say ignored – is the bottom line. The value of the meeting. (Not just the cost, but the return you get on paying that cost.)

From the book ReWork:

When you think about it, the true cost of meetings is staggering. Let’s say you’re going to schedule a meeting that lasts one hour, and you invite ten people to attend. That’s actually a ten-hour meeting, not a one-hour meeting. Your trading ten hours of productivity for one hour of meeting time. And it’s probably more like fifteen hours, because there are mental switching costs that come with stopping what you’re doing, going somewhere else to meet, and then resuming what you were doing beforehand.

Which doesn’t take into account the productivity loss for the time required to prepare for the meeting, type up and distribute notes, etc….

When it is possible to work out loud, however, the work is not (need not be) hidden and the current state of work, along with all of the context that goes with it, is readily available to all who may need to see it. Including managers. But this requires a change in how managers approach management, and how they interact with the people who report to them.

Instead of asking to be “kept in the loop” through individual emails or by scheduling meetings, it becomes incumbent on the manager to ensure that their employees are working out loud and that they, the manager, keep themselves in the loop.

Thinking in bits isn’t just about changing the way we design forms to collect information or using fancy techniques to push customized content to our users. It also has far reaching implications and potential in how we design our work and the organizations in which we perform that work.