While the post-it (or sticky note, if you‘d like to avoid the 3M trademark) is a useful tool in a physical office, it‘s virtual cousin is a skeuomorphic crux to be left behind.

They suffer the same draw-backs (lack of context, lack of coherence, lack of accountability and a general illusion of having written a finished thought) but without the main argument for using one (they‘re sticky and thus actually useful in a physical setting).

So, one thing I‘ve been trying to do is ditching the virtual post-it and instead embrace notes, scribbles, screenshots, and snippets. Let‘s see where this goes.

From Alexandra Deschamps-Sonsinos Creating a Culture of Innovation (2020):

I introduced this in the studio as I feel they inspire a behaviour that isn’t conducive to risk taking or thinking with rigour. Someone will write the word ‘data’on a post-it note and days later that note sits there, without context and becomes meaningless. It lets us off the hook from ever having to think through ideas and concepts in detail. They’re a lazy illusion of thinking. Instead we have whiteboards in the studio so we can stand together as a team and use written and visual forms.

They become constellations of words, illustrations, code, images of interfaces. You can amend them and it slows you down to properly communicate with someone. There’s an immediate need to do something with those ideas as the whiteboard feels more temporary. Post-its tempts you believe they work well as repository for thinking. So people delude themselves into thinking you’ll come back to a collection of Post-its.

They also create an artificial barrier between the facilitator or designer and the impact you can have by doing work. Services are not made of post-it notes, they’re made of data, interfaces and people. It also gives designers the illusion of control over a process of brainstorm but again, that’s not action. That’s not what a designer is capable of. There are other processes we can take, other ways to do things.

Don’t bring a post-it to a database fight¹

Summary for quick reference. Relevant in the context of decision-making and uncertainty.

When you prioritize easily measured data points over more elusive information when making decisions, you might fall victim to the McNamara fallacy.

The first step is to measure whatever can be easily measured. This is OK as far as it goes. The second step is to disregard that which can’t be easily measured or to give it an arbitrary quantitative value. This is artificial and misleading. The third step is to presume that what can’t be measured easily really isn’t important. This is blindness. The fourth step is to say that what can’t be easily measured really doesn’t exist. This is suicide.

 —  Daniel Yankelovich, “Corporate Priorities: A continuing study of the new demands on business” (1972).¹

Tips for Critique & Feedback

A collection of notes for quick reference.

Asking for Feedback

• Ask for feedback before you finish something. In my experience the best moment is when you reached 80% of the work done.
• Always start by explaining the goal and context of the project.
• Be clear about the kind of feedback your looking for (editing? visuals? structure?) and for which parts of the project and what is excluded from feedback.
• Never attempt to solve a problem in the meeting. Take the feedback back to your desk and do the work there.

Giving Feedback

• The best feedback comes from being invested in the goal of the project and trying to earnestly help someone achieve that goal.
• Try to understand the purpose of an element before giving feedback. What’s the goal and does it fullfill that goal? Talk about things that work and don’t work and why.
• Focus on the outcomes not the process of a person.
• Be as precise and concrete as possible in your feedback.
• Always ask first before giving subjective feedback (the stuff you “like” or “don’t like”).
• Give pointers (“you could explore X”) but don’t attempt to solve a problem in a meeting. (Follow-ups exist for a reason.)

Modern Internal Communication Practices

A couple of notes on internal communication tools and practices for organizations that are either distributed, or working in a hybrid model, or are in need of structured ways of sharing information.

1. The problem with hybrid or distributed work
2. The curious case of Automattic
3. Why is Microsoft moving in the opposite direction?
4. Practices
   1. Agile Communication
   2. Amazon‘s six pager
   3. Living docs
5. Tools
6. Related Articles from other smart people

The problem with hybrid or distributed work

One problem of distributed/remote/hybrid work is the missing bandwidth of face-to-face communication or as a study of 60,000 Microsoft employees found

Our results show that firm-wide remote work caused the collaboration network of workers to become more static and siloed, with fewer bridges between disparate parts. Furthermore, there was a decrease in synchronous communication and an increase in asynchronous communication. Together, these effects may make it harder for employees to acquire and share new information across the network.

A 2020 study by Atlassian aptly titled “Reworking Work” arrived at similar conclusions.

• Meetings in a distributed environment became more formalized and structured. Unstructured, free-floating communication almost vanished completely and with it the exchange of topics, information, and ideas not tied to the work at hand.
• The collaboration in teams got better up thanks to this formalized approach but suffered across team or department borders.
• Individual workers fear their work might become invisible and thus their careers may suffer without the ability to show off projects or network with higher-ups and peers. (This problem is especially pronounced for new higher of young workers.)
• “work time” in a distributed and remote team tends to fracture even with workers located within the same timezone, country of even city. Housework, children, private tasks and even hobbies tend to collide with the time allocated to work — without impacting productivity but availability.

The curious case of Automattic

Automattic, the company behind WordPress is an interesting case study. It employs 1.700 people across multiple continents and time zones since 2005 and has an interesting work culture.

1. Asynchronous — there are no meetings, e-mail, or PowerPoint presentations. Everything happens via written communication.
2. Transparency — this written communication is (with exceptions) open for every employee to read, comment, and share internally.
3. Document everything  — obviously. (Meeting notes, project updates, new hires, etc.)

To accomplish this the company uses a custom version of WordPress called P2 as an internal forum/intranet/task-managment/documentation-tool: “P2 or it didn‘t happen.“

In conclusion: if a company wants to work as a distributed/hybrid organization, in the long run, it might have to rethink its communication infrastructure and adopt one that is:

• open for every employee to contribute to
• transparent
• and most importantly: written

Why is Microsoft moving in the opposite direction?

Microsoft has dominated offices around the globe with its software, lately bolstered through “Microsoft Teams” a chat/video-call tool build for communication inside teams and organizations. But its features and internal logic are not built to ideally support a written communication culture.

• subgroups (also called “teams“) are often slow to navigate.
• content can not be easily shared across such groups. (Thus they tend to create and reinforce silos within an organization)
• these subgroups are often hard to find without either an invitation or a detailed name since they often exist to represent either actual teams, projects, or open forums without distinction.
• users are often highly restricted in their use of teams by their managers. (For example: if they‘re not allowed to edit their own title or which part of the organization they belong to, the company as a whole become unreadable and impossible to navigate after some time)

And of course:

• The editor of Teams is not built for longer written texts. In fact, it‘s pretty bare-bones without features such as tagging, drafts, or pre-planned publishing of content.

Microsoft has lately also been more focused not on solving these issues but instead working on the video components of the software and even integrating its version of the “Metaverse” (formerly called “3D” or “VR“) in the form of virtual spaces.

Microsoft seems more interested in creating a skeuomorphic digital office than actually helping people do good work in a distributed team. (And you can guess which tool the 60,000 Microsoft employees most likely used from the study at the top.)

Honestly, Microsoft… just force people to add agendas to their meetings. It would make a bigger difference than starring at the feet-less avatars of my colleagues.

Practices

Okay, let‘s talk about some interesting practices that fit the mold of asynchronous and written communication.

Agile Communication

While not explicitly written for distributed teams, “agile communication” is a great way to structure communication inside companies.

Your comms strategy should simply be “Show the thing. Be clear. Be brief.” Any time you spend trying to come up with something that says broadly the same thing, only using many more words, is probably wasted time.

It argues in favor of blogging at the speed of work with a heavy focus on quick, short posts, showing the artifacts of work, and building up a archive of posts.

The practice is described in a great piece on the Gov.uk blog as well as in the book of the same name by Giles Turnbull.

Amazon‘s six pager

According to myth: Amazon banned PowerPoint presentations in 2004 and instead installed a culture of written memos.

Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the innerconnectedness of ideas.

One format that caught on is the “six pager”. A narrative document used to develop and pitch ideas, product, and project. And yes, it should be six pages long.

The main goal of authoring this kind of document is to craft the entire thing as a narrative. That doesn‘t mean it needs to be an entertaining story. It merely means there are no bullet-point lists, no graphics, and no fluff in the document‘s core 6-pages.

Meetings thus consist mainly in the form of reading circles in which these documents a read, critiqued, and discussed.

You are usually given 20–25 minutes at the beginning of a 60-minute meeting to read the doc from beginning to end. Most people write down questions or feedback directly on the printout since using a computer during this time is frowned upon.

All print outs are handed back to you at the end of the meeting. The rest of the time consists of everyone in the room challenging your position, questioning your tactics, and digging through the data to make sure it is valid. It‘s incredibly stressful, and when the meeting is over, it‘s your responsibility to update and recirculate the document to everyone as a final version. There is no ideation or brainstorming during these kinds of meetings.

These documents are interesting because:

• They force a team to spell out their thoughts and ideas on paper.
• The use of a speculative press release gives them the chance to develop a common vision of the future of said project.
• Because narrative and hard facts are at the forefront of any new project, it forces teams to be precise and agree on the same base truths.

Living docs

I already have a short note on living docs in this garden, so I won‘t repeat myself too much here.

In short: living docs are shared multiplayer-edited documents (think: Google Docs) that work as growing documentation of every project. Instead of having dozens of different documents, everything gets sorted into one big one.

You‘ll find research, contact information, to-dos, etc. in there.

Tools

Some tools and platforms I find currently interesting:

• Pulse — similar to P2 but with a (in my opinion) nicer design
• Notion — slow but still the go-to if you want to build a wiki for your team
• Coda — focussed on documents, this one is pretty much “living docs, the tool“
• Abstract Notebooks — focussed on distributed design teams.
• Axios HQ — Axios writing style but as a B2B SAAS platform.
• Twist — Work communication as threaded discussions organized around channels. (“Long-form slack“)

Related Articles from other smart people

• Filtered for… writing inside organizations by Tom Critchlow 
• Work & Learn Out Loud by Patrick Tanguay

Understanding Culture

A couple of loose notes on the cultural gaps of publishers vs. newsrooms vs. innovation teams.

1. Failure to Launch: Competing Institutional Logics, Intrapreneurship, and the Case of Chatbots
2. Competing worldviews: User vs. Human
3. The Language Barrier

Failure to Launch: Competing Institutional Logics, Intrapreneurship, and the Case of Chatbots

This paper by Valerie Belair-Gagnon, Seth C. Lewis and Colin Agur hits some interesting beats when examining the work of innovation teams inside publishers in the case of chatbots.

The failures of chatbots as a “technology” aside, the authors make some interesting observations:

Journalists, intrapreneurs and managers are all governed by their own “institutional logic”, referring to the ways, rules and norms people observe and follow when operating in a given social environment. (i.e. newsrooms, innovation teams & publishers)

Institutional logics are socially constructed from historical patterns of material practices, assumptions, values, beliefs, and rules. These logics provide meaning for the production and reproduction of action and social reality across time and space

(…)

A core assumption of institutional logics is embedded agency, referring to the ways that interests, identity, values, and agents‘ assumptions are embedded in prevailing institutional orientations. Decisions and outcomes thus are the result of the interplay between agency and institutional structure, which both enable and constrain individual and organizational actors

(…)

The embedded agency of actors suggests that individual and institutional agents seeking to trigger technological change and innovation are not neutral but are shaped by competing logics of inter-institutional systems.

• Innovation teams are forced to manoeuvre these logics and while being propelled by their own logic (“experimentation, audience orientation, and efficiency“)
• Through this lens institutional logic, individuals can develop different interpretations of a technology. For example, innovation teams tend to be enthusiastic early adopters because they are embedded in an institutional logic of experimentation, while a journalist working in a newsroom may come to a completely different conclusion because he is focused on the quality of his work and thus might not be as keen to wildly experiment.

Aware of existing journalistic norms and practices, though many were not trained in professional journalism, the intrapreneurs reflected on how newsbots failed. Too often they were not in sync with traditional news formats (which made it difficult for reporters follow up on stories and develop sustained conversations using newsbots) or with news delivery (which relegated newsbots to the status of ‘add-ons‘ rather than vital tools that could enhance efforts to target or broaden audiences in a more consistent and concerted fashion). Therefore, newsbots did not match traditional news styles or means of distribution, nor were they adequately timed to match those moments of the day when newsbot users might be more likely to engage in a back-and-forth dialog with the technology.

• To sum up: there is a broad cultural gap between innovation teams and newsrooms and the management of both. This gap can lead to miscalculations and misunderstandings from both sides which in turn can doom projects.
• Innovation teams need to be aware of this cultural gap and need to do their homework and be more willing to throw away an idea if it does not fit. It‘s once again the difference between a good idea and a potentially successful idea.

Competing worldviews: User vs. Human

• Another good illustration of this gap comes from the designer Ted Hunt in his broader critique of “user centered design”.

• In the case of newsrooms/publishers the way journalists, managers and entrepreneurs view their audience can also be broken down along similar lines as they use similar abstractions. What‘s the difference between a user and a reader? What’re the differences between users and readership? How are those groups broken down and why? What logic permeates the engagement with these segments?

• It‘s not about finding the right way of understanding your audience, but acknowledging this gap in understanding. The ways these abstractions shape the work, processes and decisions of different teams.

• I found this second illustration inside the “Urban Technology” newsletter by Bryan Boyer, contrasting the somewhat exaggerated worldview of an urbanist vs. “technologist”.

• How might a similar graphic look like for innovation teams vs. newsrooms?

The Language Barrier

• aside from the user vs. reader distinction, teams tend to invent or adopt their own language. Especially when it comes to innovation teams, as Alexandra Deschamps-Sonsino observes in her book “Creating a culture of innovation“

One of the reasons for this choice of language is world building. Every innovation department is trying to build a narrative about themselves as an extension or in opposition to the rest of its business. Language is an easy way to create that world when the office space doesn’t. It’s also a way of embracing military ideologies or artistic ones, both potent sources of imagery and visual inspiration for innovation work.

• I think innovation teams should be highly conscious of their own decisions of how to name of explain concepts and projects. Creative obfuscation might sound impressive, but might hinder the communication and collaboration with the wider organization.

How does your organization talk to itself? How does it tell stories? Does it deal only in certainties, or is it comfortable talk ing about possibilities (beyond rhetorical questions and glib marketing slogans)? Does it revere or fear the future? How does it measure current efforts against future aspirations? All of these are vital issues for getting a firm handle on your venture into futuring. You may be in the enviable position of setting the tone and direction for all of these questions, but chances are that there are already embedded ways of treating uncertainty, possibility and associated risk.

(…)

Likewise, it’s helpful to understand the language of knowledge — certain or otherwise — that an organization traffics in. Does it speak to itself in rational numbers, data and hard evidence and have a strong affinity for probabilities? Can it function with what an old client of ours used to call highly informed insight‘ — that is, the trusted knowledge and points of view developed by its own internal expert culture that are often not quantitative in nature but that carry analytical weight?¹

Project Narration

A couple of notes towards a communication strategy for innovation teams.

Why?

• Innovation often means a) working outside the comfort zone of a given company and b) trying to change aspects of the company in the process.
• Promising projects often fell apart because company and team weren‘t on the same level, meaning a difference in language, a lack of understanding of a field or idea or a missing history of the project which made the work of the team invisible and incomprehensible.
• To avoid those issues teams and projects need a communication strategy that goes beyond a pitch presentation.

How?

• Understanding the audience: Who are you talking to? What‘s their role in the project or their relation to the project? What information are they going to need for a decision? How can these informations be connected to form a plausible and engaging story? (Not talking showmanship here)
• Communication has to start early in the project either by compiling reports, giving presentations or writing blog posts. Early prototypes are also a way of explaining an issue or field hands-on. (This is why internal communications channels are so vitally important for innovation teams)
• Artifacts are also a useful tool. Think of artifacts as anchors for your project and story. They are a by-product of the project such as prototypes, reports, speculative design objects or literal artifacts from field-research. Things that help you illustrate decisions made or represent data points.

The art of storytelling

We’ve all heard both stories that have affected us intellectually and emo tionally and others that have fallen flat. So what makes for a great story?

In “The Four Truths of the Storyteller” (Harvard Business Review, 2007), Peter Guber argues that people are most moved and captivated by stories that reflect honest and openly communicated values and are true to the teller, the audience (who walk away with a story worth owning the moment (which makes the story spontaneously different every time it is narrated), and the mission, in that the storyteller is devoted to a cause greater than herself,

The story needs to whet the audience’s appetite for what’s to follow, and deliver on the promise through emotional fulfilment. For the story to be successful, it needs to make the audience take ownership-to retell it in their own terms, while retaining its mission. It may seem contra dictory, but intense preparation for, and a deep understanding of the material being shared supports spontaneity, allowing the researcher to ad-lib with confidence.

— Jan Chipchase, Field Study Handbook

Make it sticky

Good insights and ideas can get lost if they are not also easy to communicate. Simple language and frameworks help ensure design and development work is more naturally grounded in user insights. Creating a ‘sticky‘ language for these findings helps key insights become memorable and therefore actionable as part of everyday decision-making.

 —  Helsinki Design Lab, Legible Practices

Living Docs

I‘ve been a big fan of the London-based agency comuzi for some time. One approach I copied from the team is the idea of a “living deck” or “living doc”.

In short: a Google Doc, that‘s used as a project documentation + project narration tool. It can be used to, quote:

• link to documents (spreadsheets, digital boards, other decks…)
• share interesting references
• document chats, ideas, crits, workshops…
• that “we should be keeping a list of these ideas somewhere” moment

María Izquierdo Alfaro wrote a longer article all around living docs on medium.

Another example is the “dashboard” Bryan Boyer used to remotely organize his “civic futures” course at University of Michigan Taubman College of Architecture and Urban Planning during.

How to use Living Docs

These are a couple of rules I made for using Google docs as an effective project documentation / project narration tool.

• Document everything — If it’s not in the doc, it didn’t happen.
• Write for your team — Don‘t write for yourself, document for your team.
• Create sub-docs as necessary — I usually work with one main document (called “basecamp”) as long as possible but often branch out into smaller more focussed docs for certain aspects or sub-projects that are linked in the main one.
• Structure, structure, structure — Never lose track, use headings logically, keep the table of contents in the sidebar clean.
• Latest first — The latest meeting, the latest update, the latest decision is always at the top.
• ’@’ is your best friend — Use the shortcut to insert dates, names, or elements without taking your hands off the keyboard.
• Pageless > Page — Google has the option to create page-less documents. They are usually easier to read and skim, especially long ones.

The WIP world

Yuhki Yamashita, CPO at Figma recently shared a rather insightful piece on how the use of docs as a room for work, rather the product of it, change the speed of it. Or as he‘s calling it “welcome to the work in progress world”.

Files are no longer static documents that you attach to an email and send to collaborators. Browser-based tools make it so that work can be shared with anyone, anywhere via URL, allowing everyone to look at and work on the same file at the same time. As it turns out, when people are able to iterate on their work in real time, they share it earlier, too. If you‘ve ever added a “[WIP]” or “Work in Progress” annotation to the title of your file, you know the power of an in-progress draft. It‘s a signal that lowers the stakes, letting any potential viewers know that this is, indeed, in progress. Designers can share early directions with product managers, just as writers can share rough drafts with their editors.

Though it should be noted (as Cennydd Bowles does) that using this WIP mode of work as an interface with the outside world might not be the most ideal approach. It smells a bit too much like Facebook‘s “move fast and break stuff”.

There‘s certainly a place for scrappiness in design, and a WIP-iterative way of working. But, whatever empirical dogmatists might have you believe, there‘s also a role for polish and finesse, even before launch. Advanced design expertise involves matching the approach to the scenario. I‘m not sure Figma understands or welcomes that fluidity.

Artefacts of Work

One interesting notion in the last years was the question of how I can make the process of my work more engaging and transparent? An obvious direction is the idea of artefacts — the byproduct of the greater endeavormwhich can be used to present and narrate a project. The help document the process by making decisions legible.

And they‘re often too readily discarded. As Matt Webb rightly notes there‘s a hidden opportunity here, especially in the context of innovation work:

The idea is to follow early product innovation processes, but ship all the collateral around the product rather than the product itself.

Such artefacts can take on a lot of different forms. They can be reports, design drafts, wireframes, photographies, mock-ups, prototypes, or actual artefacts from field research, etc.

Design artifacts are not the deliverable. They just document the design decisions, and design decisions must be rooted in user research.

If you can't draw a direct line from the artifact to how the decisions it documents will be informed, you won't produce anything of value.

— Pavel \#StopAsianHate (@PavelASamsonov) April 7, 2021

As such artefacts tend to increase in fidelity and detail throughout a project. Early artefacts may be a simple post-it or rough sketch, while later projects might include visually complex explorations, concepts and testable prototypes.

What combines them is their ability of making decisions legible.

Anchoring Artefacts

One way of extending this idea is the act of crafting “Anchoring Artefacts”, as described in HDL‘s “Legible Practices“, (pg. 93).

Tangible artefacts—documents, objects and other material—subtly embody or express the values of an organisation. Especially when an organisation is growing rapidly or attempting to transform itself, high-res artefacts help embody organisational or operational change which is often more abstract and invisible.

One intriguing class of artefacts might be the “one pager“. A concise presentation technique for communicating the interactions within systems (i.e. in game design).

Making things stick

A more familiar example might also be NASA mission patches—easily replicated in the form of stickers or posters as used by the UK‘s Government Digital Service.

Stickers like that become tokens that represent something more – a shared experience, a shared set of memories that only people who worked on that project will remember and understand. A sticker, like a web page, can be a conscious act of institutional memory.

Facebook‘s “Analog Research Lab” operates on a similar level. Around 2010 two marketing manager set up a small print-shop on the company campus. A project, which inadvertently played an integral part in not only creating a common company culture, but also propagated it to offices world-wide.

“It‘s more observations across the company,” says Boms, who calls himself a workplace philosopher. “The hope is that the artwork is more empathetic, curious and diverse, and it looks at what‘s happening from a critical eye. It‘s the pulse of what‘s going on internally.”

Boms says the posters don‘t aim to dictate what employees should think. Rather, they offer a prompt for people to think about.

Another quirky example is the work of Craig Mod who seems to use every opportunity to turn projects into a book. Be that via SMS during long walks through Japan or by laying out every commit ever made on a software project. Here he is talking about both.

Via McCarthy, I. Hannah, D. Pitt, L & McCarthy, J. (2020). Confronting indifference toward truth: Dealing with workplace bullshit. Business Horizons, Volume 63, Issue 3. Link

via Austin Kleon

via sister.is

via workfutures

Reading Recommendations

Some resources I‘ve used extensively in my own work.

Books

Creative Collaborations—A book by the Helsinki Design Lab on how to facilitate effective collaborations. It‘s small and helpful. (free PDF or Print on Demand)

Articles

Strategy and stewardship—A short summary with some additional thoughts about HDL‘s notion „Stewardship“ in the context of strategic work. In short: it‘s all about tight feedback loops.

Narrative Strategy: Thoughts on an emerging indie consulting style—I like the idea of using communication as a strategic tool for work inside complex organizations. Especially when it comes to trying to influence the deeper layers of organizational meaning, such as imaginaries, visions and intents.

Experiments in Studio Telemetry—Some interesting experiments around keeping and streamlining criticism and feedback in a studio environment.