Move Fast, Break Things, Feel Bad

This is a confession. I have come to dread parts of my work day lately, and this is no fault of anyone at Sift. (I continue to think that everyone there are all kinds of amazing.) I think I need to get a new set of metrics for how to evaluate my work, and a new way of feeling about it. And I am not there yet.

Here’s the backstory. Sift Science is a start up, and like other start ups it is in a constant state of brokenness. We try things, and sometimes it even works. Indeed part of the enterprise is trying to figure out what works as quickly and as cheaply as possible.

This forces compromises. Compromises that designers (read: me) tend to be uncomfortable with, like shipping UI before it is ready, and showing unpolished work to get early customer feedback. In my recent meetings with Jason (the CEO) and Sripad (the PM), they have both consistently emphasized that we need to just get the work out there. When I am in those meetings, I agree with them. The purpose of getting the work out there is to learn which of our assumptions are right, and which of the assumptions are wrong.

The purpose is not to ship “good, polished work” – work that I like, or work that other designers like.

This week we had a product and business team demo session, where Sripad and I showed the business team the mocks and designs that I have been working on. The business team at Sift work with our customers day in and day out, and they know well what the customers’ asks are, and how the customers perceive our product.

Naturally, the business team had lots of questions, and many suggestions. This being the Sift team, they had lots of good questions and good suggestions.

I felt like shit. Many of the questions they raised were questions I knew about, but have not had time to address. Many other questions were ones I never (and probably could never have) anticipated. Both types of questions made me feel like I was not doing my job.

And then I felt angry. If only I had more time to work on these designs, these questions wouldn’t come up, because I would have addressed them already. These mocks are really rough, and are not at all representative of what’s going to be the final product anyway.

I felt silly after that. That’s what this whole meeting is about. Feedback is the source of good work, even if they are a tough pill to swallow at the time. So I move on with my day, trying to get rough designs out quickly to stay ahead of engineering.

The feelings don’t go away though. “Move Fast and Break Things” is a mantra in the start up world. The idea is when you break things, you learn things, things that are valuable to the team, the product and the company.

But when you break things, you feel bad, and feelings are real. Today I went to a meeting with the PM which I dreaded the whole time, even as I nodded in agreement to the aggressive deadline I am putting myself under. This weekend, I am going to do design work that I am not going to completely happy with, in order for us to ship the next iteration of the UI, and continue our journey in learning and growing the product. I am going to do work that’s not my best work, and the company will be better for it. The ironic things is, if I insist on doing my “best” work, the product will probably be worse off in the long run.

All of this I believe is right, but feels wrong.

So where does this leave me? Frankly, for now, I think I just have to suck it up. In the longer term, I need to associate my feelings not with whether I am doing good “design” work, but whether I am learning to build a better product, and whether I am making our customers successful.

For my own sanity though, I must confess, I am moving fast, breaking things, and feeling bad about it. And the next thing I need to break is my overly narrow conception of what it means to be a “good” designer.

And, frankly, parts of my ego too.

p.s. Jason, Sripad – if you’re reading this, don’t freak out. I promise I am sticking around.


Sometimes I’ll get a call or email from someone five years after the last contact and I’ll think, oh right, I hated that person. But they would never have known, of course. Let’s see if I still hate them. Very often I find that I don’t. Or that I hated them for a dumb reason. Or that they were having a bad day. Or much more likely, that I had been having a bad day.

People silently struggle from all kinds of terrible things. They suffer from depression, ambition, substance abuse, and pretension. They suffer from family tragedy, Ivy-League educations, and self-loathing. They suffer from failing marriages, physical pain, and publishing. The good thing about politeness is that you can treat these people exactly the same. And then wait to see what happens. You don’t have to have an opinion. You don’t need to make a judgment. I know that doesn’t sound like liberation, because we live and work in an opinion-based economy. But it is.


How to Be Polite — The Message — Medium

Paul Ford. Man.


Consensus, Authority and Mandate

When I was little, sometimes I’d get bored and look through my Dad’s bookshelf. There were a number of books of Chinese philosophy, which I read while only half-absorbing. The work of Han Feizi, however, stuck with me more than most.

Han Feizi was a philosopher of statecraft, in the Chinese legalist tradition. Unlike the Confucians, he was not interested in a idealized philosophy of “harmonious” governance. He expounded a theory of pragmatic statecraft:

In his book, Han Fei exihibits a kind of “summa legista” (Ralf Moritz, Die Philosophie im alten China), in which he assembles the main arguments of his legalist precursors: Written law and regulations (fa 法), the art of ruling by use of competent advisors (shu 術), and the undisputed authority of the ruler (shi 勢) are the three instruments of a strong state.


I was recently reminded of 法, and  when I was contemplating why certain initiatives proceeded at work, while others failed to gain traction.  In particularly, I thought about the word shi 勢, which in Chinese means more than just authority. It’s often used to refer to the momentum of a situation.

Han Feizi lived in the spring-and-autumn warring period. I live in what is probably the second dotcom boom. What does Han Feizi’s advice to his feudal lords have to do with an employee at a startup?

I will argue that to lead a team effectively on a project, one must have agreed upon practices (fa 法), employ the team according to their talents (shu 術) and possess the mandate for embarking on the project.

In particular, my frustrations recently have to do with trying to move projects forward without the required mandate. What do I mean by mandate here? In my mind, mandate has two components — authority, and consensus.

Authority without Consensus

Authority alone doesn’t get you very far either. Another recent project saw the exec team push for getting a feature out the door quickly. In my mind, too quickly.I was very reluctant to move forward with it, because I felt it needed more testing. The leadership team was very understanding, but believed that we should “ship, then iterate.” It was a philosophy that I agreed with.

And yet, I noticed myself dragging my feet on necessary changes, and raising my concerns again and again. Even though in my mind I was convinced, my heart wasn’t in it. The feature eventually got shipped, but it took a lot longer than merely the work involved would suggest. If you want to get the best out of your people, having authority simply isn’t enough.

Consensus without Authority

So, what about consensus? There was another recent project, one which I pushed for, where everyone who heard about the project idea thought it’s a good idea, even the CTO and the product manager. The problem was, it’s just big enough to be beyond one person’s tinkering time, and touch enough pieces of the product that it requires cross team collaboration.

So it will require schedule, resourcing, and putting it on the roadmap, which I could not do. The idea lingered, and members of the team were disappointed. “I wish we could do that!” “We could!” “But it’ll take a couple days.” So the idea stayed on the back burner. For months.

Authority + Consensus = Mandate

That is, until we had a team hackathon. Suddenly, I had the authority to decide what we wanted to work on, as long as I could convince others. A small (2.5 person) team of us built a prototype of the idea in two days, and the business team have been using it ever since.

What made it possible? It was the combination of top down delegation of authority, and the bottom up pooling of consensus. The difficulty there was never technical, it was organizational, and it made me appreciate the necessity of mandate. Consensus isn’t enough, nor is authority.

So what?

Mandate is important, because many of the thing we strive to do can only be done as a team. Learning to work effectively in a team environment therefore involves learning to gain mandate.

Which brings me back to Han Feizi. The character 勢 the he uses evokes the idea of terrain in warfare.  In order to be effective, the statesmen must read the terrain well and understand how to leverage it. In an organization, the terrain consists of relationships, norms and hierarchy, through which power and information flows. It’s not enough to just “do good work” - one must understand how the work is perceived, and how the work affects the people and the organization.

I guess what I am learning is “just the work” isn’t enough. It’s time to learn to read organizations.

"It is said an Eastern monarch once charged his wise men to invent him a sentence, to be ever in view, and which should be true and appropriate in all times and situations. They presented him the words: “And this, too, shall pass away.” How much it expresses! How chastening in the hour of pride! How consoling in the depths of affliction! “And this, too, shall pass away.”"

Abraham Lincoln, 1859 (via austinkleon)

(via bustr)

"It’s common in business for non-creative persons to believe they’ve engineered a means for replacing creativity, which is costly and intermittent and inscrutable to them."

— Mills Baker on Quora, answering, What went wrong at Zynga? (via allisonacs)

(Source: quora.com, via allisonacs)


I didn’t know I was learning to code

So some of my @svaixd friends (@tinabean @prachipun @tomharman @clickcolleen) friends started a writing club. This is my entry on theme number one, beginnings.

Beginnings that you know are beginnings are daunting. I don’t think I am alone in this experience, where starting any project of even a moderate size (i.e. will take a couple hours, with an uncertain outcome) takes mental bracing, as if I were to jump into a cold pool of water.

Which makes me wonder how any of us get anything done at all. Recently, some friends asked how I learned to program. And the truth is, I don’t know. I know when I learned to program, but I honestly don’t know how.

In the summer after the first year of college I was elected to run the IT department of a student club. Chiefly because I was willing when no one else was, and then chiefly because I didn’t know what I was getting myself into. I had built a couple static websites, which I learned to do during high school. I didn’t know this at the time, but knowing how to do mark up is very different from programming.

"So how does our website work?" I asked my senpai.

"It’s like a PHP thing."

"What’s PHP?"

"Ok just FTP into the server. I’ll show you."


I inherited a spaghetti mess of a PHP codebase, before WordPress was even really a thing. I needed to make changes to it, so I borrowed a PHP MySQL book from the library, which I only knew to look for because I googled PHP and Sitepoint’s tutorials came up.

I remember when I discovered for loops, I thought that was genius. SQL queries was magic. I can stop making separate files now, because templates! I had never even heard of the word templates before.

All the while, I didn’t know I was learning to program. I was busy trying to put photos up for events, or automate signups to a ski trip, or make it easy for club members to communicate. I wrote a shoddy basecamp/wordpress clone in 2006 for my student club before I recognized I was programming.

Embedded in this big “beginning” was a hundred little beginnings. Beginning to look at logs instead of printing things out to the server. Beginning to recognize when I’ve created an infinite loop. Beginning to understand the fear of bringing a site down. Never was I conscious of the beginning-ness of it all.

And so maybe that’s the secret. A great way to begin is to not recognize you’re embarking on a life long journey. It might just be to step out to go to the library to borrow a book to scratch this itch you had. I recognize this is not helpful if you’re trying to be deliberate, but I suppose maybe being deliberate is sometimes overrated? It’s good to scratch an itch. Sometimes scratching an itch leads to whole life direction, but if nothing else, an itch got scratched.

"It made me think of my professional journey. When I zoom out and look at it from the perspective of 20 or so years, it looks like a well-planned out series of moves and progressions, doing things that look pretty cool. When I zoom in more closely it looks more accurately like a series of serendipitous, random steps, lots of missteps and mistakes, and many many many regrets. In fact, not until 2006 or 2007, when I reconnected with John and started betaworks, can I ever really say that I was satisfied, maybe even happy, and definitely the only time I really felt good at something. Not until I was 40 fucking years old! And there were parts of building betaworks - getting office space, hiring people, setting up payroll, forming subsidiaries, raising money - that I am not sure I would describe that I “loved” doing. They were tedious, stressful, and hard."

Andre Agassi, Do What You Love, Bob Dylan

Maybe this will remind me to not fetishize “great work”.

"We could go back and forth all day on what exactly defines technological change – I certainly have before. But what labor wants is self-determination, not a slowing of technological change. Taxi drivers protesting Uber aren’t saying that they want apps out of their cabs. They want leverage to negotiate wages and working conditions so they aren’t barely scraping by. The pushback is on exploitative business models, not technology."

Alex Payne — Dear Marc Andreessen

Love it. Highlighting the distinction between resisting technological progress and resisting exploitation.



There are a plenty of places to help you develop your startup idea or product, but not a lot of places to help you navigate the initial creative process when you are just getting off the ground.

That’s what Orbital Boot Camp is all about.

It’s a 12-week intensive course to help people…

I hope you’re following along, because it’s going to be epic adventure time at Orbital this summer.


In an environment in which start-up resources are not limited, and no one can predict the next winner, and it is easy to measure customer behavior in great detail, the Internet is no longer a technology.

The Internet is a psychology experiment.

Building a product for the Internet is now the easy part. Getting people to understand the product and use it is the hard part. And the only way to make the hard part work is by testing one psychological hypothesis after another.

Every entrepreneur is now a psychologist by trade. The ONLY thing that matters to success in our anything-is-buildable Internet world is psychology. How does the customer perceive this product? What causes someone to share? What makes virality happen? What makes something sticky?


Scott Adams Blog: The Pivot 06/16/2014

The Internet is a psychology experiment. What a quote.