_Working Backwards_, recent book on how Amazon runs.


  • central is thinking about product features, not business. The business funds the product, the customer value – it’s the McGuffin that you careful guide to being cash flow. The question here is to find other org.s that have adopted abs adapted the practices successfully, or not.
  • the advice at the end is pretty straightforward – the practices are kind of simple, so applying them just means deciding to do them – just like deciding to diet and exercise. It’s the deciding and sticking to it that’s hard.
  • an analysis of this book requires an approach: don’t halo effect/shoot down the book and triumphs, focus on describing why others find it hard to act this way. This book isn’t wrong in it’s own story: the challenge is “scaling” the lessons learned to other orgs.
  • They Still do intense annual planning, do they just do it “better”?
  • Comp of max 160 and lots of equity is good? Probably.
  • “wasted time” a common phrase, in interview chapter.
  • people interested in high performance, not quality of life…?
  • dependencies – something you need but can’t control/build/etc.
  • we spent too much time coordinating and not enough building.
  • dependency discussion (when they had a monolith) is a good business view in this tech stuff – do most LoB execs (outside Amazon) have this much IT knowledge?’
  • Two pizza teams changes to single threaded leader – lots it emphasis on one person owning one thing, all parts of that thing. End-to-end.
  • not a what decision, a who and how – figuring out how to respond to iTunes on Windows.
  • Needs a long term focus.
  • there isn’t talk of the “boring” retail business – warehouses/logistics, purchasing from suppliers, etc. how is that all run?

The ethics of selling software, the find the good first test

View this post on Instagram


A post shared by Michael Coté (@bushwald) on

Should you be selling software to ICE? How about companies that make missiles, canned food that’s bought and eaten by drone pilots? How about only divisions of defense companies that make the defensive weapons, like anti-aircraft radar? Even authoritative regimes need asset management software that tracks what type of lightbulbs are used in the tourist department’s waiting room.

This is an ethical question programmers ask themselves sometimes, especially programmers employees by large enterprise software vendors killing time at an open source conference, wondering how they got so much mud on their pants cuffs.

I don’t know the answer, really. I have a philosophy degree from 2000, which means I’m from the school or philosophy that says “can you ever know anything? Let’s go get some pho.”

Some software is like canned food: a commodity item with faceless consumers. You’re not going to stop making canned food (or deodorant) because people you disagree with use it. You won’t kill httpd because some evil actor installs it and uses it to help oppress or kill people. Why? I mean, because it’s impossible to know who uses it?

Things get more complicated with a SaaS, like GMail. In theory you could investigate who’s using it. This could be like finding copyrighted material or porn on YouTube, a lot of work, but a business priority, so you figure out how to do it. You could deny email to bad actors.

But then what about, like, kubernetes? Should we be excited or depressed that it can run on fighter jets? Do we distinguish between defense vs. attack? Do we need to read some big ethics of war reading list to figure out if a first strike is actually defensive or offensive?

Are we going to use some observability to detect when the fighter jet is defending versus attacking, or just doing some air show for retires and kids, and shut down kubernetes according to our ethics (air shows use a lot of fuel after all, and those kids on grandpa’s shoulders are going to suffer the consequences of that fun afternoon in later years – oh, and also the scenario where you kill people).

Like I said, I don’t know the answer. (Yay gen-x, or whatever.)

I would just suggest a different approach to analyzing the question, different than I see most people discussing it. Most people ask the question “how do we identify when our customer is evil and, thus, we should deny them our awesome software?”

Instead, I would ask it slightly differently, “prove that the software will be used for good by the customer.” That is, instead of finding the evil, prove that the customer will do good.

I’m not suggesting ignoring evil done – you look for that too after finding the good. But, you’ll have a different approach and less continuous discussion if you start with “before you can use my software, you have to show me the good you’ll do, prove that you’re going to use it in ways I agree with.”

Theoretically, you’ll arrive at the same place as if you started with finding the evil. Whether you start by focusing on how delicious the punch is first, or start with there’s a turd in the bowl first, you should reach the same conclusion.

Make your conference talk about one small thing

The content at most conferences is midling. Most talks should be focused on one small thing, not an overview of everything (with the rare exception of an opening, level-setting talk, perhaps). Tech people fall prey to laundry listing a bunch of things because we get excited to learn new stuff, we love tools and new things and concepts – and usually we want to share that excitement, or at least show off and have the joy of hearing yourself talk (an under rated joy). But, listing everything you can think of on a given topic is usually a bad approach for a talk. A series of lectures is where to be comphrensive, or a book.

Sometimes, a laundry list of tactics is good, a table of contents for further work. A live demo is another thing too: you usually want to see the full-cycle of how an idea gets coded into an application, deployed, debugged, etc.

A story can be good if it’s a case study, but even then you probably want to conclude with one thing: “what we found was that we should have involved procurement at the beginning.”

Memorable talks usually have one idea, though.

A talk should be mostly the conclusion for a those laundry lists, those lecture series: here’s the one thing we found after all that work we described in chapters one to fifteen, or, the one idea we had, the one problem we solved that we didn’t even know we had, the idea you are (too) comfortable with that you need to change to stop suffering/unlock your potential, the one action I want you to take.

As with all people who give advice, I don’t follow it.

“[M]ost of the time he didn’t even write. He dictated.”

I know that I speak for many journalists—and many others—when I say that it is perfectly possible to write after lunch, even if, or particularly if, you have had a bottle of wine. It is simply not possible to do this after dinner; not after booze. I don’t know anybody else who is capable of knocking out first-class copy after a long day and a drunken dinner. There must have been something unique in his metabolic pathways; and what makes it even more astonishing is that most of the time he didn’t even write. He dictated. He would gather his thoughts and then, wreathed in tobacco and alcohol—and perhaps wearing his monogrammed slippers and the peculiar mauve velvet siren suit made for him by Turnbull and Asser—he would walk the wooden floorboards and growl out his massively excogitated sentences. And that was barely the beginning of the word-processing system. Typists would struggle to keep up, but on he jawed, even into the small hours of the night, licking and champing his unlit cigar. Sometimes he would take them with him into his tiny and austere bedroom, and then while they blushed and squeaked he would disrobe and submerge himself in his sunken Shanks bath and continue to prose on, while they sat on the floor and pitter-pattered away on the specially muffled keyboards that he preferred. The sheaves of typewritten paper he would then correct and amend by hand—and we have innumerable examples of his cursive blue-inked marginalia—and then the results would be typeset as they would appear on the page; and even that was not the end. Now I pace across the room to an upright sloping bureau that is set against the wall, like a newspaper-reading slab in a club. It was here that he engaged in the final exercise of word-processing, a ritual that we would now perform effortlessly with our Microsoft programmes. He would fiddle with the text. He would switch clauses around for emphasis, he would swap one epithet for another and in general he would take the utmost delight in the process of polishing his efforts; and then he would send the whole lot off to be typeset again. It was a fantastically expensive method of working, and yet it enabled Churchill to produce not just more words than Dickens, or more words than Shakespeare—but more words than Dickens and Shakespeare combined.

Dictating work seems absurdly impractical and “expensive.” But, perhaps that’s how you scale up. As with most improvements and transformations, there’s no magic, there’s just doing new, often weird, uncomfortable, and costly things.

From The Churchill Factor.

Successful pundit tactics

  • Make shooting fish in a barrel seem interesting and insightful. Facebook is evil, Amazon is rapacious.
  • Layer financial analysis into your big claims – talking about valuation, share price, cash flows is impressive.
  • Stick to your stock phrases and concept models. Eventually, they’ll stick. Or, if people don’t laugh at them and repeat them, you can come up with new ones. Own a category and the associated words.
  • Make definitive statements, e.g., Microsoft will burry Slack with teams, like they did Netscape.
  • Find a contrary position that promotes a social good. Or just a contrarian position.
  • Find a position that other pundits don’t have. The “blue ocean” thing. Scott Galloway likes the idea that tech people could easily decide to do social good, but don’t because there’s no profit and there’s no punishment.
  • Point out that people can just actually do things, that it’d be easy to solve problems if you tried. This is a Matthew Yglesias rhetorical trick. The unspoken implication is that they choose not to and are hypocrites or, at best, flaccid.
  • Convert a year’s worth of blog posts, newsletter missives, etc. into a book.
  • Make predictions, wild ones. People love predictions and it truly doesn’t matter if they come true or not.
  • Be independent, not unbiased. To make all these wild-claims you need financial security (or to not care about it) so you can lash-out, er, comment on every opportunity.
  • Always unmask motivations instead of attacking a person’s character – explain why people (or movements) are motivated to do something, not that they’re bad people. Once you explain why they’re motivated to do something:
  • Point out how the rival position leads to unintended consequences, often contradicting the original goals. Too much NIMBY leads to a housing shortage, pushing less wealthy people out of the neighborhood, increasing gentrification, driving wealthy people into your neighborhood and developers to only make sure bets instead of novel ones – now you’re the bourgeoisie!
  • Pointing out that “the medium is the message” (people’s desires and how they express/pursue them in the world shapes what they do and create, regardless of the Truth of the matter) gets them agog every time.
  • Most importantly: never answer the question you were asked, answer the question you wished you were asked and that you have an answer for.
  • However: 15% to 20% of the time let yourself make shit up and just go into a screed of disjoint nonsense that’s poetic and invigorating. We value and respect the insane, inchoate genius more than we’d like to admit. People need a break form being serious all the time to stay sane.

See most all of them in action here.

Write every day even if it’s not on topic

I hear people say they write every day, they make a habit of it. I always assumed this meant writing on topic, on whatever your projects are.

Really, it just means write something. Even complaining about yourself or writing a description of a bird. The point is to be practicing, to stay in training, to keep your sword-mind sharp, as Tyrion once explained when it comes to reading (the other daily practice).

Often, nothing for your deadlines will come. For some people it comes in little slices that will add up over time and be edited into perfection, for others (like me) it’s all at once in a deluge of words that need to be typed down before they flow away down the gutter.

Writing every day gives you the chance to start, and to get closer to finishing. You can rely on the muse to inspire your writing, but the muse needs to know when and where to find you.

And, even if it’s just journaling, you’ll help your psychology, and create a log of what happened that day – filling the tanks for when the muse does come. Think of artists doodling and doing “studies” all the time. So many good books are just worked over diary entries and collections of anecdotes.

(The above is pulled – like those little slices – from writing advice I’ve read elsewhere [esp. the muse metaphor]. Related writing tip: don’t worry about hyperlinks if you don’t have the time: click publish and move on.)