From Marshal B. Rosenberg’s Nonviolent Communications:

“The Most Arrogant Speaker We’ve Ever Had!”

This dialogue occurred during a workshop I was conducting. About half an hour into my presentation, I paused to invite reactions from the participants. One of them raised a hand and declared, “You’re the most arrogant speaker we’ve ever had!”

I have several options open to me when people address me this way. One option is to take the message personally; I know I’m doing this when I have a strong urge to either grovel, defend myself, or make excuses. Another option (for which I am well-rehearsed) is to attack the other person for what I perceive as their attack upon me. On this occasion, I chose a third option by focusing on what might be going on behind the man’s statement.

MBR: (guessing at the observations being made) Are you reacting to my having taken thirty straight minutes to present my views before giving you a chance to talk?

Phil: No, you make it sound so simple.

MBR: (trying to obtain further clarification) Are you reacting to my not having said anything about how the process can be difficult for some people to apply?

Phil: No, not some people—you!

MBR: So you’re reacting to my not having said that the process can be difficult for me at times?

Phil: That’s right.

MBR: Are you feeling annoyed because you would have liked some sign from me that indicated that I have some problems with the process myself?

Phil: (after a moment’s pause) That’s right.

MBR: (feeling more relaxed now that I am in touch with the person’s feeling and need, I direct my attention to what he might be requesting of me) Would you like me to admit right now that this process can be a struggle for me to apply?

Phil: Yes.

MBR: (having gotten clear on his observation, feeling, need, and request, I check inside myself to see if I am willing to do as he requests) Yes, this process is often difficult for me. As we continue with the workshop, you’ll probably hear me describe several incidents where I’ve struggled … or completely lost touch … with this process, this consciousness, that I am presenting here to you. But what keeps me in the struggle are the close connections to other people that happen when I do stay with the process.

From Brené Brown’s Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead:

Last year I gave a talk on vulnerability to 350 SWAT team officers, parole officers, and jailers. (Yes, it was as intimidating as it sounds.) A SWAT officer walked up to me after the talk and said, “The only reason we listened to you is because you’re just as bad at being open as we are. If you didn’t wrestle with being vulnerable, we wouldn’t trust you one bit.”

From Pietra Rivoli’s The Travels of a T-Shirt in the Global Economy: An Economist Examines the Markets, Power, and Politics of World Trade:

So, what do I say to the young woman on the steps at Georgetown University who was so concerned about the evils of the race to the bottom, so concerned about where and how her T-shirt was produced? I would tell her to appreciate what markets and trade have accomplished for all of the sisters in time who have been liberated by life in a sweatshop, and that she should be careful about dooming anyone to life on the farm. I would tell her that the poor suffer more from exclusion from politics than from the perils of the market, and that if she has activist energy left over it should be focused on including people in politics rather than shielding them from markets. And I would tell her about the shoulders she stands on, about her own sisters and brothers in time and the noble family tree of activists, and the difference they have made in a day’s life at work all over the world. I would tell her that, in just a few short years, I have seen the difference her own generation has made, and that someday people will stand on her shoulders, too. I would tell her that Nike, Adidas, and GAP need her to keep watching, and so do Wal-Mart and the Chinese government. I would tell her that I have met dozens of seamstresses in Chinese factories who need her, and that future generations of sweatshop workers and cotton farmers need her as well. I would tell her to look both ways, but to march on.

Specifically:

My T-shirt’s story, then, is not a tale of Adam Smith’s market forces, but is instead a tale of Karl Polanyi’s double movement, in which market forces on the one hand meet demands for protection on the other.

I also like this on boring meetings as a sign of progress:

With a long historical perspective, it seems clear that when the meetings get boring, we have taken a step forward. Boring meetings mean that the radical has become mainstream, and that the establishment has changed its mind about the very nature of right and wrong. The struggles for bans on child labor, or for fire exits or minimum wage or factory codes of conduct, are never boring. But when the fight is won, the meetings get boring. While the battle rages for and against, it is interesting. But when the battle is over and the fight is no longer about whether to have fire exits but where to put them, not whether to have a minimum wage, but how to administer it, not whether to disclose factory locations but by what means and how often—when the establishment has changed its mind and we are just working out the details in (yet another) early morning committee meeting—it gets boring.

From Michael Lewis’ The Undoing Project on how happiness and misery is experienced differently:

“What might have been is an essential component of misery,’” he [Daniel Kahneman] wrote to Amos [Tversky]. “There is an asymmetry here, because considerations of how much worse things could have been is not a salient factor in human joy and happiness.”

[..,]

Happy people did not dwell on some imagined unhappiness the way unhappy people imagined what they might have done differently so that they might be happy. People did not seek to avoid other emotions with the same energy they sought to avoid regret.

This bit on how people remember (and compare) bad experiences is also fascinating:

When he met Redelmeier, Danny was already running experiments on unhappiness in his Berkeley lab. He’d stick the bare arms of his subjects into buckets of ice water. Each subject was given two painful experiences. He’d then be asked which of the two experiences he’d most like to repeat. Funny things happened when you did this with people. Their memory of pain was different from their experience of it. They remembered moments of maximum pain, and they remembered, especially, how they felt the moment the pain ended. But they didn’t particularly remember the length of the painful experience. If you stuck people’s arms in ice buckets for three minutes but warmed the water just a bit for another minute or so before allowing them to flee the lab, they remembered the experience more fondly than if you stuck their arms in the bucket for three minutes and removed them at a moment of maximum misery. If you asked them to choose one experiment to repeat, they’d take the first session. That is, people preferred to endure more total pain so long as the experience ended on a more pleasant note.

These are my notes from attending a full-day in-person Priceonomics Bootcamp; they now have an online Priceonomics Content Marketing Bootcamp. Most of this is covered in their The Content Marketing Handbook or on their blog and operationalized through their Content Tracker. It’s fantastic.

The Priceonomics Story:

1. What they were doing at the time: had a business pricing stuff
2. Context at the time: OkCupid data blog was good
3. Tried to emulate what was going on: “We were better at writing about the business’s data than the doing the business.”
4. Found success and evolved: people liked it

Information Marketing

“Data content that spreads”

Key questions:

• What is interesting data that is a byproduct of your business?
• What do you know that’s valuable to other people

“You don’t necessarily need to do information marketing, that’s just what Priceonomics does”

Alternatives to information marketing:

• Story <- Wealthsimple does this
• Info <- Artsy does this

Information Marketing helps reporters AND helps you.

Two Information Marketing strategies:

1. Create content that is popular that leads to press hits that leads to inbound
2. Do not-massively popular content that converts highly

“Have a clear idea, have a clear distribution plan, and it will work. It’s simpler than you think, but simultaneously easy to screw up.”

Information Marketing overcomes a common challenge: When you publish stories/info about your industry, what do you do with it because it doesn’t fit a media narrative of something to write about… that’s why data posts are easier to share.

Writers Playbook:

• “The Nugget”: What will someone say about this? can they verbalize it? how would they explain it to a friend. Why will someone share this? What will they say about it?
• Maximize “shots on goal” by having something relevant to as many people as possible.
  • Top 100 List is better than a Top 10. More people can identify with something you have to say.
  • Giving a ranking gives people something to say, e.g. “my thing is 7th”.
• Write clearly, people only read topic sentences. You can’t say anything important in the middle of a paragraph.
• Title should get the point across, and not sound like the article will be boring. “You don’t have the credibility of the New Yorker to have an artsy or vague title”. Signal it’s quantitative and imply “there will be a ranking”. lendedu has good titles.
• Don’t spend time on trying to explain “why”, just show the data. 3-5 charts, 800-1,000 words
• • A/B Testing Titles: Buy facebook ads with different titles and test clicks. For example “Unfortunate physics of mail urination” vs “Why can’t we design a splash proof toilet?”
• People tend to link to data-driven studies because it’s hard to summarize.
• The holy rail is having a report you update once a year or quarter. Example: Thumbtack small business confidence.

The Process:

Spend 40 hours on pulling together the data. Priceonomics takes 3 week for a full turnaround.

1. Prep -> 1 hour. People already have the ideas, they just need to be scoped down and picked for ones that fit a template. Don’t start with a story, just get the data!
2. Get the data -> 1 week
3. Analyze the data -> 2 weeks
4. Write -> 1 week
5. Iterations -> 1 week
6. Finishing touches -> 1-2 days

Distribution

• Nothing happens until a critical mass of people see it.
• Anticipate where your content will be popular before you start writing. Supernodes: Hacker News, Reddit, Digg, Metafilter, Product Hunt, Next Draft, MediaRedef. Find niche supernodes for your vertical.
• THE BUMP. 1000 simultaneous people. leads to it being organically shared.
• Journalists are the only channel you control.
  • Make a list of 50 journalists who would be interested in your data
  • Craft your pitch to them in a short email draft (don’t send it). Write the journalist email draft before you write your article
  • Start writing your article
  • Send the journalist a short, individualized message
  • It takes just one
  • You’re the information provider It’s not news until an outlet covers you.
• How to do it:
  1. Make list of 50 journalists who’d be interested in your article.
  2. Craft your pitch to them in a short email
  3. Start writing your article
  4. Then send them a short individualized email.
  5. It takes just one. Keep a list of everyone who has ever written about you. Send them a quick thanks.

Subject: Buying data shows people purchase t-shirts when they wake up
Hi Sam,

I read your article about shirts.io last year

Just wanted to let you know Day of the Shirt just published some interesting data about when people shop for t-shirts:

[link to blog article]

Basically most people shop when they wake up. Thought you’d be interested.
Best,
Ben

Data Studio Philosophy:

• Our readers deserve never to be confused
• It’s about the information, not the writing style
• Focus on why someone would want to share this story
• People love data. They love maps. They love charts. They love tables. We give people what they want.

Article Templates:

These are also published here in more detail.

1. Geographic Variation: “who clicks on ads”
2. Trend related to the news: “trump bump”
3. Who does that? “the age people outgrow ikea”
4. Secret data about something people care about “cost of being a bridesmaid”
5. Data that you have that is valuable to business “does mentioning a famous client in an email convert better”
6. Rank stuff: “diverse universities”
7. Cost and price of stuff: “which cars have lowest maintenance cost”

Non-obvious Learnings about writing

• People care more about cities than states
• For rankings (geography, colleges) have a cutoff of top 100 cities (based on population) or top-ranked colleges
• It’s about the information, not the process. You only need 1 short paragraph about your methodology, near the beginning.
• The intro is paramount. You have to sell the article. You just have to get people excited. You don’t need to get into an elaborate explanation of who you are or why you’re writing it.
• Don’t try to be funny, try to be clear.
• Keep interpretation to a minimum. After writing a few of these style articles you’ll learn what is a PhD dissertation is and what is a 40-hour piece. Don’t make it a PhD dissertation.
• Never apologize for what you didn’t do. Explain what you did do. Say how novel it is “this is the first time…”
• The conclusion should re-emphasize your main point.
• We don’t care about what other data is out there

Editing

• Is this offensive?
• Can anything be taken out of context
• Typos matter less than misunderstandings/offending in massive distribution. Even offending 1% of people is huge.
• Make it possible for people who are responsible for the blog to succeed

Learnings about visualizing data

• Titles should be clear and enticing. Catchy title: “Ranking the countries that drink the most wine”. Boring subtitle: “Wine consumption in liters per capita in 2011”
• Tables are fine, don’t need to be complicated or interactive. It’s nice have some variation though.
• People love maps! And not because they convey information well.
• Round your numbers sensible. Use commas, have empathy for your readers’ eyes
• 3-5 charts is the maximum before it gets boring

Questions

Should I be worried about other content on my blog? No one cares about you. Don’t worry about your other content or feel obligated to retool, edit or delete it. No one cares.

I’ve found too many opportunities to quote this from “Ask a Manager” in the past few weeks:

…one of the ways that dysfunctional workplaces harm the people who work there is by warping their sense of what’s normal … and by getting them overly invested in trying to make something work that they aren’t well positioned to fix in any meaningful way.

For more than a year I’ve been attending monthly Lighthouse Labs meetups at San Francisco’s Lighthouse for the Blind. Each month Lighthouse Labs holds an open forum for accessibility technologists to present and receive feedback. These are my notes from an audience retrospective of a year of these presentations:

• Working with new learners:
  • What tech do you currently have?
  • What do you want to do that you currently can’t? “Based on life. “
  • “Its ok to say Blind. How exhausting is it to hear people talk around for 15 minutes trying not to say the B-word?”
• Advice for inventors and presenters:
  • No more remote assistance
  • No more buzzing wearables
  • No more cane solutions
  • Keep it simple.
  • Make your website accessible
  • If they think they have a product for the blind, ask them what research they’ve done. Should we be patient zero? And if so, they should be aware of what that means.
  • What is the end goal of what you’re presenting? How do you intend to effect a person’s life? Example: “be more independent”, but in what way? It might be too open or predictable; how bizarre it could go. Answer: “How do you intend to enrich someone’s life?”
  • Why do you think your life solution is better than others? Eg why is it better than a cane?
  • Don’t: Try to solve a problem that blind people don’t need solved.
  • Have a list of how blind people already do stuff.
  • Bring appropriate audio-media, and understand it well enough to connect it to the presentation room.
  • “Yeah, that idea was terrible. But they were young, full of ideas and open to feedback”
  • “It is exhausting to say every month, we have canes and they’re fine.”

From Appraising Performance Appraisal by Steven Sinofsky:

The following are ten of the most common attributes that must be considered and balanced when developing a performance review system: …

3. Measuring against goals. It is entirely possible to base a system of evaluation and compensation on pre-determined goals. Doing so will guarantee two things. First, however much time you think you save on the review process you will spend up front on an elaborate process of goal-setting. Second, in any effort of any complexity there is no way to have goals that are self-contained and so failure to meet goals becomes an exercise in documenting what went wrong. Once everyone realizes their compensation depends on others, the whole work process becomes clouded by constant discussion about accountability, expectation setting, and other efforts not directly related to actually working things out. And worse, management will always have the out of saying “you had the goal so you should have worked it out”. There’s nothing more challenging in the process of evaluation than actually setting goals and all of this is compounded enormously when the endeavor is a creative one where agility, pivots, and learning are part of the overall process.

Best practice: let individuals and their manager arrive at goals that foster a sense of mastery of skills and success of the project, while focusing evaluation on the relative (and qualitative) contribution to the broader mission.

I like how Rapid Development: Taming Wild Software Schedules by by Steve McConnell lays out exactly how “Best Practices” were selected or rejected:

Summary of Best-Practice Candidates

Each practice described in a best-practice chapter has been chosen for one of the following reasons:

• Reduction of development schedules
• Reduction of perceived development schedules by making progress more visible
• Reduction of schedule volatility, thus reducing the chance of a runaway project

Some of the best practices are described in Part I of this book, and those best practices are merely summarized in this part of the book.

You might ask, “Why did you ignore Object-Structured FooBar Charts, which happen to be my favorite practice?” That’s a fair question and one that I struggled with throughout the creation of this book. A candidate for best-practice status could have been excluded for any of several reasons.

Fundamental development practices. Many best-practice candidates fell into the category of fundamental development practices. One of the challenges in writing this book has been to keep it from turning into a general software-engineering handbook. In order to keep the book to a manageable size, I introduce those practices in Chapter 2, “Software Development Fundamentals” and provide references to other sources of information. A lot of information is available from other sources on the fundamental practices.

In a few cases, you might rightly consider a practice to be a fundamental one, but if it has a profound impact on development speed, I included it as a best-practice chapter anyway.

Best philosophy, but not best practice. Some best-practice candidates seemed to be more like theories or philosophies than practices. The distinction between theory, practice, and philosophy in software development is not clear, and so an approach that I call a “philosophy” you might call a “practice” and vice versa. Regardless of what it’s called, if I considered it to be “best,” I discussed it in the book somewhere. But if I considered it to be a philosophy, it’s in the first or second part of the book. (See Table III-1 for a list of where each best philosophy is discussed.)

Best practice, maybe, but not for development speed. Some best-practice candidates might very well be best practices for their effect on quality or usability, but they could not pass the tests of improving actual development schedules, perceived schedules, or schedule volatility. Those practices were not included in this book.

Insufficient evidence for a practice’s efficacy. A few promising practices were not supported by enough evidence to deem them to be best practices. If the development community has not yet had enough experience with a practice to publish a handful of experiments or experience reports about it, I didn’t include it. Some of the practices that fell into this category will no doubt someday prove that they have large speed benefits, and I’ll include those in a future edition of this book.

In a few instances in which published support by itself was not sufficient to justify treating a practice as a best practice, I had personal experience with the practice that convinced me that it was indeed a best practice. I included those in spite of the lack of published support from other sources.

Questionable evidence for a practice’s efficacy. A few best-practice candidates seemed promising, but the only published information I could find was from vendors or other parties who had vested interests in promoting the practices, so I excluded them.

Not a best practice. A few best-practice candidates are highly regarded (even zealously regarded) in some quarters, but that does not make them best practices. In some cases, experience reports indicated that a well-regarded practice typically failed to live up to expectations. In some, a practice is a good practice, but not a best practice. And in some, the practice works fabulously when it works, but it fails too often to be considered a best practice.

In one case (RAD), the candidate practice consisted of a combination of many of the other practices described in this book. That might very well be an effective combination in some circumstances. But because this book advocates selecting rapid-development practices that meet the needs of your specific project, that specific pre-fab combination of practices was not itself considered to be a best practice.

This paper on “The Concrete Sumo: Exigent Decision-Making in Engineering”

by Taft H. Broome, Jr. is a difficult read because it tells a story first, and then explains who the characters are; read it twice back-to-back.

In the Johnny-on-the-Spot, Tubby was the first to speak to me: “No court in the land,” he said, “would blame you for letting the sumo dump the concrete in the entrance way. Its not your fault that they left you alone on your first day!” Then, Roebling began to speak: “You are an engineer, and engineers sacrifice all for their responsibilities to the business of engineering!” Finally, Uncle Roy, the engineer after whom I had patterned my career, spoke to me: “This job belongs as much to you as to anyone else. So, you have a duty to either move this project along, or resign!”

…

My last day on the job was occasioned by my acceptance to graduate school, and by lunch treated me by the superintendent and the project manager. We exchanged pleasantries before I recalled for them the elevator pit task left to me on my first day. I expected the superintendent to say that the carpenter foreman was alerted to the plot and instructed to prevent any catastrophe. Instead, he recalled for me that on his first day he was likewise abandoned and thus laid out a church, not only in the wrong direction, but also on the wrong lot! Without any apology at all he said: “When it comes to rookie engineers, it is better to pay early, than to pay later.”

The afterward explains the simplified procedure:

A year ago, I agreed to instruct an ethics workshop for undergraduate engineering students in preparation for the Fundamentals of Engineering Examination (FEE). The FEE is the first step toward licensure. The workshop was scheduled for ninety minutes. I convened the workshop by passing out a trial examination in professional ethics. Instead of lecturing on ethics as I had planned, it occurred to me to ask the students to take the examination. Fifteen minutes later, they had finished. Then I asked them to think of an aged, highly mature person: a family member or some legendary character; someone who exhibited great wisdom and caring for others. Then I asked the students to re-do the examination, but this time putting their sage in the position of test taker. Finally, I gave them the solution to the examination and asked them to grade both responses, theirs and the responses of the sages. The results were surprising: the first responses were either failures or marginal passes; the second responses maximized the examination! I then adjourned what turned out to be a forty-minute workshop.

The following semester, one of the students informed me that he had taken the FEE and passed it, and had done very well on its ethics portion.

Perhaps the literary approach to problem solving in ethics and deference to the old yet have places in engineering, in practice as well as in the classroom, today.

Some reflections from Matt Webb on their accelerator’s office hours:

4. There is often a crisis. Fixing the issue is not my job.

A special type of Office Hours is when there’s a crisis. I would characterise a crisis as any time the founder brings urgency into the room–whether it’s good or bad. There are times when sales are going just too well! “A great problem to have” can trigger a panicked response just as a more existential crisis such as an unhappy team.

I have to remind myself that fixing the issue is not my primary job. Participating in panic validates panic as a response. But if a startup responded to every crisis with panic, nothing would get done. (I would characterise panic as short-termist thinking, accompanied by a stressed and unpleasant emotional state.)

What makes this challenging is that I often know what they’re going through. Sometimes I recognise a situation and my own emotional memories well up. There have been sessions where my heart races, or my palms sweat, or I look from team member to team member and wonder if they realise the dynamic they’ve found themselves in.

So before we talk about the issue, I try to find the appropriate emotional response: enthusiastically cheer first sales (but don’t sit back on laurels); get pissed off about bad news but move on with good humour; treat obstacles with seriousness but don’t over-generalise. It’s a marathon not a sprint, and so on.

Then use the situation to talk tactics and build some habits. I like to encourage:

1. Writing things down. Startups are not about product, they are about operationalising sales of that product. Operationalising means there is a machine. The minimum viable machine is a google doc with a checklist. The sales process can be a checklist. HR can be a checklist. Bookkeeping can be a checklist. When things don’t work, revise the checklist. Eventually, turn it into software and people following specific job objectives. This is how (a) the startup can scale where revenue scales faster than cost of sale; and (b) the founder can one day take a holiday.
2. A habit of momentum. I forget who said to me “first we figure out how to row the boat, then we choose the direction” but movement is a team habit. If, in every meeting, i respond to a business update with “so, what are you doing about that” then that expectation of action will eventually get internalised

I find these viewpoints sink in better when they’re using in responding to a crisis.

I also like to encourage self-honesty. Sometimes my job is to say out loud things which are unsaid. Founders are very good at being convincing (both themselves and others) otherwise they wouldn’t be founders. Sometimes that data that doesn’t fit the narrative is left out… to others and to themselves. So I can help break that down.

There will be crises and crises and crises. But we only have these Office Hours for 12 weeks. If we concentrate on fixing just today’s issue, we miss the opportunity to build habits that can handle tomorrow’s.