More on this book
Community
Kindle Notes & Highlights
by
Scott Berkun
Read between
April 4 - April 12, 2020
To simplify a design requires thinking holistically—how the whole thing fits together for the user—rather than how good any idea seems on its own.
The bottleneck is never code or creativity; it's lack of clarity.
It's never a surprise in great projects to find grueling work somewhere along the way—work that never upholds the same aesthetic as the final results. Tales of the hard parts often fail to make it into the brochures or the corporate tours.
Our decision to go for Highlander (the plan for a single commenting system) forced tough choices, most of which we couldn't yet see.
Generally I liked this about Automattic. The absence of dedicated quality assurance people made every employee accountable for quality, which is rare if there are many QA people around.
The prevailing attitude at Automattic was that any big project is simply a series of smaller ones, and I liked this. It avoids the stupid things that happen on projects by never allowing you to fall in love with your grand plans.
You should never be religious about methods of any kind. The only sane way to work is to let the project define the plan. Only a fool chooses tools before studying the job to be done.
After years of leading projects, the best thing I've learned is that I have to periodically shift between thinking small (bazaar) and thinking long term (cathedral).
All the rational people, despite their brilliance, are too reasonable to start crazy things.
quite a thing to be in meetings in person with Matt. There's
Projects accumulate a pile of annoying tasks people postpone,
1. We do things we like first. 2. We do things we don't like last. 3. The things we don't like tend to be harder. 4. Late changes have cascading effects.
This means that at the end of any project, you're left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them).
I'm certain of the following: Self-motivated people thrive when granted independence. Managers who want better performance must provide what their staff needs.
Remote work is a kind of trust, and trust works two ways.
Recently Yahoo CEO Marissa Mayer banned remote work from her company, claiming it made people less productive.1 She might have been right: in her company, people may have abused the trust that remote work grants employees. Some employees abuse free office supplies from the copy room. Others lie about taking sick days. Every benefit granted can be used to perform better work, or it can be abused. The benefit itself rarely has much to do with it.
But despite what they say, most people fear new ideas. They instinctively defend the old, no matter how frustrated they are with it.
The oldest, largest companies today all began much like Automattic, with ambitious youth, big ideas, and high thresholds for change.
It's the ambition and flexibility that enabled them to do well enough to grow old in the first place. If you want longevity, you can't just bet on tradition; you have to continually invest in the future.
Tom Preston Warner, chief technology officer of GitHub, a popular collaboration tool, believes that any organization that works primarily in the digital world can work remotely.4 Like Automattic, GitHub has always been a fully distributed company, naturally reaching many of the same conclusions as Automattic about autonomy, empowerment, and trust.
Outsiders assume remote work means working from home, but that's an important inaccuracy. The true directive is that employees can locate themselves wherever they want.
Life Without E-Mail
When I say that Automattic doesn't use e-mail, people lift an eyebrow as if I'd said the company doesn't believe in oxygen or bans the use of the letter E. Every employee has an e-mail account; they're just rarely used.
All tools are good for some tasks and bad for others.
mail has rarely discussed disadvantages: E-mail empowers the sender. They can put in your inbox whatever they like and as many times as they
like (many receivers use filters and rules as countermeasures).
E-mail is a closed channel. There's no way to see an e-mail if you are not on the “to” list, forcing work groups to err ...
This highlight has been truncated due to consecutive passage length restrictions.
E-mail decays over time. If someone writes a great e-mail, an employee has to do ...
This highlight has been truncated due to consecutive passage length restrictions.
Over time, that organizational knowled...
This highlight has been truncated due to consecutive passage length restrictions.
P2s by design invert these assumptions: The reader, not the sender, chooses what to read. The reader chooses how often and in what form he or she wants to read. Since P2s are a form of blog, they're easy to skim, easy to reference with a URL, available to all forever, searchable, and easily pushed into different reading tools.
One secret at Automattic is that e-mail is technically part of how P2s work: it is used for notifications.
“The Limits of E-mail”
1. Some conversations need to be real time. Brainstorming and teaching require high interactivity, but blogs are designed for latency.
2. Voice has more data. We are a text-centric culture here, but voices have more data.
We get tons of information (humor, attitude, nuance) you can't get from text.
When in doubt, g...
This highlight has been truncated due to consecutive passage length restrictions.
3. Some conversations need fewer people. P2s are open to all. Some threads narrow to 2 people going back and forth, and they should get a room (email/Skype/hotel).
4. Many conversations need to be visual. As a rule, I never want to talk about a UI feature without a screenshot: A rough sketch explains more than 5 paragraphs of text (e.g. an idea in text may not work in pixels).
5. Thread hijacking. This is when you carefully write a post, and then a comment comes along asking a tangential question that everyone finds more interesting. If your thread gets hijacked, start it again—don't assume it means what you wanted to get isn't worth getting.
6. ADD kills big ideas. Big ideas require more thinking before commenting. Given post A (clever idea on some little thing) vs. post B (radical sweeping idea on some big thing), post A will tend to get more comments. It's easier to respond and say “cool!” or “+1.” Post B requires more investment to comment, so it gets less of them. This is misleading—it suggests A is a better idea than B, when it really just means how much smaller an idea A is.
7. How much did they read? If someone jumps in on a thread, there's no way to ...
This highlight has been truncated due to consecutive passage length restrictions.
8. Is silence acceptance? If you post and no one comments, does that mean they read it and they agree?
Online it's hard to know when you've intimidated someone because silence means different things. In real life when you hurt someone's feelings, you can see it in his or her eyes and feel something in your heart.
Working remotely mellowed everything out, dropping the intensity of both the highs and the lows. Depending on your previous experience, this made things better or worse.
Mayer's policy on remote work is discussed here: http://gigaom.com/2013/02/25/why-marissa-mayers-ban-on-remote-working-at-yahoo-could-backfire-badly/.
The thread comments on this article are worth reading to show how polarizing a no WFH mandate can be.
“Coralling the Yahoos,” March 2, 2013, Economist, references a study conducted by Ipsos, a polling firm: http://www.economist.com/news/business/21572804-technology-allows-millions-people-work-home-big-tech-firm-trying-stop. 3 I have complied this list of fully distributed companies: http://scottberkun.com/2013/how-many-companies-are-100-distributed/. 4 From an interview with Tom Preston Warner at GitHub headquarters, October 2012. 5 Scott Berkun, “Would You Work from Home?” October 17, 2012. http://scottberkun.com/2012/poll-results-would-you-work-from-home/.
Too often teams are imprisoned by methodologies when they should be empowered by them (a sentiment captured in the Manifesto for Agile Software Development, a set of simple principles for making software1). Methodologies are often another bad friction that managers impose, putting more faith in a bunch of rules than in the people they've hired. I'd take a great team with bad methods over a lousy team with great methods any day.
1 “Manifesto for Agile Software Development,” 2002, http://agilemanifesto.org/.
plan the project, I needed a special list. The easiest way to work to a schedule is a spreadsheet with three things: Each work item, listed in priority The developer assigned The developer's work estimate You can never take a schedule seriously unless it has all three of these. It's only when people see their names on the board next to a promise they've made that a schedule is real.
