Design is visual and tactile. It plays with the form and function of objects and systems to improve them. It’s a discipline in which every undertaking is akin to getting together with a group of people and asking, “Look at what I made — what do you think? How can we make this better?”
Now, imagine this group of creators scattered all over the world. How can these collaborators find and maintain the spark of creativity that passes from one designer to another when they’re all hunched over a blueprint or marking up a whiteboard together? If anyone knows, it’s John Maeda.
John Maeda’s pioneering career stretches back to the ‘80s, but he’s not content to rest on his laurels. John has worked for the last three years as the Global Head of Computational Design & Inclusion at Automattic. He had spent much of his professional life in academia at MIT and as president at the Rhode Island School of Design before his transition to a new life in Silicon Valley as the first design partner at the VC firm Kleiner Perkins. He is the author of three books, The Laws of Simplicity, Creative Code, and Redesigning Leadership. A fourth book called How To Speak Machine: Laws of Design for a Computational Age is slated for a November, 2019 release.
John’s time with Automattic will come to a close soon — he’s accepted an exciting new role with consulting firm Publicis Sapient, where he hopes to work alongside “endups.” John defines an endup as a large legacy company that is struggling to maintain market dominance in the face of scrappy startups with disruptive business models. He wants to help non-Silicon Valley companies to understand the design philosophy he’s been teaching and learning during his tenure in tech.
When John first joined Automattic he elucidated his goals, which were fueled by this philosophy:
I wanted to do three things: 1/ highlight Automattic’s international community of designer-engineers (global), 2/ advance the kind of design that is being fully impacted by Moore’s Law (computational), and 3/ highlight how cutting-edge design requires the capacity to embrace human differences (inclusion).
John felt that Automattic, with its fierce commitment to the distributed model and its attendant geographical diversity, would be fertile ground for testing his theories about inclusion. He wanted to see how inclusion could help design teams come up with better products and services because they reflected a fuller spectrum of human imagination.
Computational Design
During his days at the MIT Media Lab, John pioneered a new field, computational design, which explores the nexus of creativity and computational technology in hardware, software, and within networks. Classical designers work in the domain of the tangible — furniture, poster art, fashion. Computational designers sometimes also work with physical devices like sensors and circuits, but the core of their work lies in the interaction of these devices and the intangible systems they create. The output of these interactions can take many shapes: from a cloud infrastructure to a video game to an open source blogging platform.
John became convinced that traditional design education was ill-equipped to provide students with a proper understanding of computational design. Even if they were to embrace this new field, they would still struggle: the rules of computational design change so quickly. John spent much of the ‘90s and the ‘00s working within academia, trying to help institutions navigate the sea change of the early web and preserve their position at the cutting edge of design. John says he joined Automattic in 2016 for similar reasons:
The distance between [classical] design and a design that, once shipped, has to iterate and improve at a rapid velocity — that’s a different kind of design. I think most of the design, maybe over 90%, is stuck in the old design, not in computational design. So that’s what I wanted to highlight when I joined [Automattic].
Humility and the Auteur Myth
Over the last three years, John Maeda integrated his computational design sensibilities into the design team’s workflow at Automattic. Code may grant its creator a degree of autonomy and control over their work, but John says he’s still had to adjust his mindset at Automattic, having spent most of his career working solo. He needed to rediscover the value of collaboration from the designers he led.
I had to learn from them the power of community because I spent most of my career making software by myself. Everything I made by myself; I designed every book by myself because that’s what I thought people did. [I thought] the great creators made things by themselves.
It might seem as though working in geographic isolation as part of a distributed team would make one more likely to gravitate toward self-reliance. In a blog post, John explains how the opposite is true. The meticulous documentation that the distributed model calls for leads, perhaps counterintuitively, to stronger collaborations than those in a typical office environment:
We post everything. Our processes are laid out for everyone to see. Our messy initial explorations, our bad ideas, our great ideas — everything. I’m in daily, constant contact with the other designers on our team. They know what I don’t know. And then they help me figure it out. And it’s not even just my team that sees my process – it’s literally public to the entire company. Being remote means we may be physically alone, but our actual work is more public, shared, and open than in any environment I’ve ever been in: the ability to comb through all of our designers’ projects; to get such complete insight to how people are approaching problems.
John strives to break the auteur myth by being open and self-deprecating about his failures. He once treated the goal of becoming a “Real Designer” as a final destination: someone who is so knowledgeable about design that they’re like Jedi knights — they just know how things ought to be. The Real Designer, he now argues, is nonsense; an easy-to-dismiss fallacy when one works on a distributed team where every idea, every mistake, and every contribution to every project, no matter how small, is meticulously documented and archived. There are no “Real Designers,” just hard-working individuals and teams who feed into and build on one another’s creativity.
Tools for Remote Design Teams
Cloud-based collaborative platforms can facilitate this intense level of documentation. Still, while plenty of robust tools are available for distributed development and marketing teams, the design world is still playing catch-up. John cites Figma as a popular tool: “[It’s] super reliable, it runs fast and is social to the extent that it’s not actually annoying like Slack can be sometimes.”
Figma is a browser-based design tool that lives in the cloud. There are a number of collaborative design programs in this space, like InVision, Mural, and Moqups. These platforms give designers the tools they need for tasks like illustration, prototyping, and code generation. Remote design teams have come to rely on services like these to avoid having to send files back and forth. Instead, users as well as clients can log in to a project, check its progress, and see other users’ contributions.
Another tool that John uses quite a lot is — no surprise here — WordPress. It might not seem like a priority for a design team, but John is extremely passionate about blogging. The design team’s blog, Automattic.design, documents and shares the team’s stories and experiments, its mistakes, and the lessons it’s learned.
Why should designers blog? They’re not writers, after all — at least not most of them. John explains his reasoning:
It was hard to get [the blog] off the ground because some designers felt like, “Well why am I going to blog? What is the point of blogging?” And my point is blogging is good for you. It’s mental health, it’s expression, it’s sharing your process with the world. And when you relate to the world, your standard of quality floats to that value of the world. It’s a market economy of ideas and by putting ourselves out there, you become relevant.
John practices what he preaches, blogging frequently and with openness and honesty. He’s also a prolific vlogger.
Vlogging and blogging are ways for John to synthesize and share his thoughts. In a world of instant Slack notifications, he prefers the way these slower media encourage users to be more thoughtful about what they’re putting out into the world. Cutting out extraneous data and showcasing the core of an idea, whether it’s an intimate personal essay or a video review of a new technology, is a way for John to exercise muscles that prove useful in his design practice as well. He encourages his teammates to comment on the content he’s producing, and to publish video and written content of their own.
John’s team members vlog about their projects’ status as a replacement for standup meetings. Traditional standups involve getting everyone on the team in a room or channel to report to the others about the status of their projects. Instead, designers working with John record videos and share them asynchronously, avoiding the logistical nightmare of getting everyone together for a meeting. Team members provide feedback on each other’s videos at their convenience. This practice offers the full fidelity of a video meeting with the convenience and flexibility of asynchronous chat, and encourages people to report their updates in a more thoughtful way, which raises the quality of the feedback in a virtuous circle.
Facilitating Feedback
High-quality feedback is critical for distributed teams but creative people sometimes find it challenging to give and receive it, even if they know it’s good for them. John, on the other hand, loves feedback, negative or positive. He is fond of quoting college basketball coach Pat Summitt, who is best known for winning more games than any other NCAA Division I basketball coach: “The absolute heart of loyalty is to value those people who tell you the truth, not just those people who tell you what you want to hear. In fact, you should value them most. Because they have paid you the compliment of leveling with you and assuming you can handle it.”
John applies agile development principles to his own personal growth. “Unless I have high-fidelity user research, how am I going to improve?” he asks, calling himself an organic computational system that can iterate on feedback just like a computer. He encourages people to think of him in this way so they’re not afraid to provide criticism. “How am I going to iterate and improve if I don’t get really high-fidelity feedback?”
At the same time, John recognizes that his ease with feedback does not come naturally to everybody. Others, for any number of reasons, struggle with receiving feedback. John argues that it’s worth adjusting one’s approach when giving feedback, based on how well the person has accepted it in the past, asking himself, “How do I adapt to what you need?”
In order to facilitate candid, reciprocal feedback, John emphasizes an empathetic, humble approach, one that remains open to criticism and embraces gratitude for the chance to learn and grow. This helps employees cast aside their apprehensions around feedback. This approach is especially productive on distributed teams, where people don’t have as much face time and stretches of communication are sometimes limited to minimalist Slack messages.
The Feedback Loop of Gratitude
John’s emphasis on gratitude is not limited to feedback — it’s something that he brings to his work in general. When he speaks about his long career in design and about his time on distributed teams at Automattic, an overtone of gratitude permeates John’s narrative.
“I know so many people distributed work has been able to make [into] better parents, better children to their parents as caregivers,” he says. “Them coming from that point of view is the beginning of [me] recognizing that this is an amazing job to have.”
John believes that those fortunate enough to have distributed jobs that provide freedom and flexibility should be grateful for their privilege, and that gratitude should drive their sense of mission. After all, not everyone is so fortunate. For perspective, John talks about his parents’ experience in the workplace.
My parents worked so hard all their lives. I think about my father. He’s 84 years old, he’s hunched over, he can’t stand up straight, because he was carrying so many heavy things all his life. My mother, because of the cold water involved in [preparing] tofu — her hands, she can’t feel anything. They worked extraordinarily hard. They are an example that was set that tells me I should do more.
John feels a deep respect for that sacrifice which enabled him to reach higher. But his parents weren’t the only ones who helped make a way for his success. He had a high school chemistry teacher, Mr. Wakefield, a retired Boeing engineer, who took an interest in him. Wakefield developed a science club so that young John would have extracurriculars listed on his college application. He persuaded John’s parents to allow him to forego his usual summer job in their shop so that he could attend a class at the local university.
The recognition that it is a privilege to do this work gives us the responsibility, says John, to aim high and work hard on projects that, in turn, preserve our wonder and respect for this privilege.
Making-milk Time
Gratitude, wonder, empathy, humility — these are all important but abstract terms. So is creativity, which is similarly difficult to measure. Creativity often involves prolonged periods of unstructured, exploratory ideation that are difficult to quantify or budget around. How can a manager ensure that creative teams stay productive, and help them translate all these abstractions into a successful product?
John invokes the late artist Gordon MacKenzie to illustrate this problem. MacKenzie once told a story about a gentleman in a pinstripe suit shaking his finger at a bunch of cows in a field. “You slackers get to work,” he says, “or I’ll have you butchered!”
MacKenzie continues the parable: “What this man does not understand is that, even as he threatens them, the cows are performing the miracle of turning grass into milk. Nor does he understand that his shouting will not cause the cows to produce more milk.”
MacKenzie drew a horizontal line to represent a creative occurrence. The first 80 percent of the line is labeled “invisible creative activity,” and the remaining sliver as “measurable evidence of creativity.”
John’s point in sharing this anecdote is that a lot of the effort behind creativity doesn’t look like work. Designers (and practitioners in related disciplines) often sit around throwing tennis balls at the wall or flinging pencils into the ceiling tile — behaviors that, to an uninformed manager, might look like loafing. But the cow can’t make the milk without spending hours upon hours eating grass and … standing around. This problem can be amplified on a distributed team because managers mainly observe team members’ output and online communication trail.
So what is a manager of distributed creative teams to do to facilitate “making-milk time?” John argues that it’s up to the team leads across the design department to encourage designers to reserve time for imaginative spitballing and meditation.
The best that I can do is a round robin, asking, “What’s up, what are you doing, what are you doing outside of work?” And then someone will say to me, “But that’s not work.” And I’ll say, “It’s your work as a creative person to express yourself.”
This policy only works when there’s a high level of trust and respect between managers and individual contributors, but the same is true of any distributed team — or any team at all. Ideally, hiring managers at distributed companies populate their teams with people who love what they do, possess intrinsic motivation, and consequently can be trusted to “make milk,” no matter where or when they’re working.
“When working with teams,” John says, “the number one important thing that I’ve found is respect. Because if people don’t feel mutual respect, then they can’t bring their best selves forward, but you have to give respect to earn respect.”
Feature image credit: Helena Price for Techies Project
