The other way to build a massive tech company - doing it slowly A Podcast by Howie Liu www.secretleaders.com I like to think about the early years of [Airtable] as not only a great time for us to be patient and to get a lot of details right in the product. I think some of those details had to be done in a slow, deliberate way with a small team. You can't necessarily parallelize the design and development of a really detail-oriented product. detailsproductsslowness
the speed of God An Article by Alan Jacobs blog.ayjay.org [Andy Crouch] quotes the Japanese theologian Kosuke Koyama saying that “the speed of God” is three miles an hour because that was the speed at which Jesus moved through his world. So maybe, and I think this is one of the chief burdens of Andy’s book, what makes the most sense for us is to try whenever possible to move at the speed of God – and in that way refuse the offer of superpowers. Of course, this dovetails with a lot of things people have been writing lately about slowness, but what I like about Andy’s book is that it specifies why we can find ourselves responding so warmly to the possibility of slowness. What happens when we seek superpowers, and especially super-speed, is the sacrifice of what I want to call our proper powers – the powers through the exercise of which we (heart-soul-mind-strength) flourish in love. The brain is wider than the sky religionloveeuphonyslowness
Two kinds of usability An Article by Ryan Singer world.hey.com I divide usability problems into two kinds: Perceptual: "They couldn't figure out what to do next", "they couldn't find the feature", "they didn't know they could click that button..." etc. Domain-specific: "We need a way to jump back here because in their workflow this happens..." In general, usability testing only catches type 1 perceptual problems. Because in those tests you take people out of the real world and assign them tasks. Usability testing doesn't catch domain-specific problems because they only come up in real life use. uxethnography