The work itself, not the talk about it
A designer's list of lessons before his birthday included one about where the life of the work is. It is less about silence than about proportion.
If you’re interested in the living heart of what you do, focus on building things rather than talking about them.
In August 2010, shortly before his thirty-fifth birthday, the designer Ryan Freitas published a list of thirty-five things he had learned. This was one of them. A few months later the company he had co-founded, about.me, which lets people make a simple personal page, opened to the public and was bought by AOL within weeks.
The phrase “living heart” is the interesting part. Every craft collects a layer of talk around it: conferences, panels, blog posts about process, arguments online about tools and methods. The talk can be enjoyable and even useful, and it is far easier than the work. A designer can spend a whole year speaking about design without designing much, and still feel busy and respected. Freitas’s point is that the part of the craft that keeps people interested, the reason they took it up, is in the making, and the talk tends to crowd it out. A rough sign of the imbalance is a month that is easier to describe by the events attended than by the things finished.
This is especially true in the web industry, where speaking at events and writing about work is a recognized path to reputation. Reputation built that way can outrun the work behind it. People who build more and speak less often have better judgment when they do speak, because they have more recent experience to draw on.
The line is weakest where talking is the work. Interviewing users is talking. So is explaining a design to an engineer, persuading a client, writing a specification or teaching a junior colleague. A team that builds without those conversations tends to build the wrong thing quickly. Sharing an idea early is also how a founder learns whether it matters to anyone.
The distinction that makes the advice usable is between talk that feeds the work and talk that replaces it. A conversation with a user that changes what gets built next week belongs to the work. A talk about process given for the fifth time does not. The test is simple enough to apply each week: what was made, and did the talking help make it.