In the middle of a binge read. The whole thing is fascinating.
In the middle of a binge read. The whole thing is fascinating.
On day not unlike today, not too far in the future, I’ll run out of tomorrows.
But that day is not today, and I’ve still got hope of tomorrows.
Given all this, and a stash of potential tomorrows, what shall I do today?
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."
Paul Ford. Man.
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.
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.